From: Albert Wagner <alwagner@...>
Date: 2001-09-01T08:52:21+09:00
Subject: [ruby-talk:20649] Re: Ruby, DBI, design

On Friday 31 August 2001 16:49, you wrote:
> Albert L. Wagner <alwagner@uark.edu> wrote:
> : Classes: Table, Column
> : A field is an instance of Column.
> : A row is an array of fields.
> : A column is a collection of attributes: field name, field type,
> : length, etc.
> : A table is a set of attributes: table name, SQL statements, etc
> : A table is also a collection of columns and rows.
>
> And how have you implemented JOINs?

For who?   An SQL savy programmer?  Or an end user who doesn't understand the 
concept?  Two very different problems.  Of course, at the implementation 
level, I haven't found any model that is as complete as plain SQL.  So that's 
how I do it.  The real differences are at the GUI level.  For programmers, MS 
Access uses list boxes and arrows in an MDI, and assumes that you know the 
differences between types of joins.  For the typical end user there are two 
subproblems:   First, they don't /can't understand 3rd Normal Form so they 
just design messes.  I don't yet have a solution for this, and (2) Querying 
someone else's well designed database;  this can be solved.  Pick up a 
fishing net by any single knot(node) and it naturally falls out into a simple 
hierarchy (disallowing any child from being it's own ancestor).  Any tree 
widget can display these hierarchies.  

Or, was this simply a rhetorical question?