[ruby-talk:20654] Re: Ruby, DBI, design

Albert Wagner <[e-mail]> wrote:
: On Friday 31 August 2001 16:49, you wrote:
:> Albert L. Wagner <[e-mail]> 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?

This was not a rhetorical question.  I am only interested in how you had
implemented JOINs for the programmers.  Most OO middleware enviroments
(WebObjects, WebLogic, Dynamo, etc) that try to encapsulate SQL queries
(in a vain effort to abstract away the DB) fall down on their inability to
handle JOINs.  It's fairly obvious why -- they are written in a static
language with inflexible definitions, SQL tables are explicitly
non-encapsulated, and there is a one-to-one mapping between tables and
'Table objects'.  Most engineer I know faced with this problem eventually
gave up and do the JOINs inside the client application.

Given that Ruby can dynamically define and extend types, and that the
product of any SQL operation is another relation (ie, a table), there's no
reason we can't write a Ruby interface to a SQL database that returns new
objects for complex queries.  I am asking how you are doing it now,
because there is disjunction in business programming; between database
people, who have attacked the reliability problem by formally defining
validity and creating constraints to validate data; and object people, who
have attacked the same problem by trying to isolate indiscrimiate access
by possibly incorrect code.  Same problem, different solutions, and
unifying them has been a PITA so far.