Re: Is it really that bad?

bob, perhaps you meant to say SQL is non-procedural.

as to kurt's original question, there is an easier solution for what needs to be done.
use a database sequence (CREATE SEQUENCE seq_name;) and an insert trigger to generate unique identifiers for each row. so if a table was defined as

    table x (ID, col-a, col-b, col-c)

then you want

    create sequence seq_x; --genreates unique ID

    create trigger trg_i_x -- insert trigger adds the ID to the row     on insert
    begin

        select seq_x.nextval into :new.ID;     end;

this allows the database to manage the unique identifier and is much more reliable than having the application do it (trust me!).

as for the class-table mapping, consider the following. just as a table describes a collection of rows, the class mapped to the table should represent a list (collection of rows) rather than a single occurrence (one row), as most database interfaces use "cursors" which return a set of rows.

further more, you can create a generic list class which is instantiated using only the table name as the instantiation parameter. the class constructor can then query the data dictionary using the class (table) name to retrieve the column definitions and build a string indexed arrary for storing the value of each column in the array (the indexes for the array are the table's column names from the dictionary).

i have written this very code in PHP if you are interested. once the generic list was written with all of the list functions and the get/set functions and such, creating all of the classes was just a matter of instantiating generic_list with each of the tables name....(and, for extra credit, write a program that generates the instantiation statements automatically -- oooh...oooh...this could lead to...automatic code generation! oooh! oooh!)

enjoy!

"Bob Badour" <bbadour_at_golden.net> wrote in message news:V%Es6.1431$MC6.627656773_at_radon.golden.net...
> >>It is well-known that SQL databases are poor at such things precisely
> >>because SQL is non-relational. "The Answer" as you call it was found
> >>thirty-two years ago, but the vast majority of practitioners are too
> >>stubbornly ignorant to recognize it.
> >
> >I have no clue -- another database language addressed temporal and
> >spatial problems thirty-two years ago?
>
>
> Codd's relational model calls for full support for user defined data types
> (domains). What else would one need to address these issues?
>
>
Received on Sat Apr 21 2001 - 05:16:07 CEST