On Sunday, 10 June 2001, Peter Scott <[EMAIL PROTECTED]> wrote:
> He's right. I do a lot of DBI stuff with Oracle, and every so often
> I have a hankering for some kind of structured tied variable that
> would look like my database. Then I wake up and realize that modeling
> of a single table doesn't do squat for me, and modeling of the whole
> database requires knowledge of the foreign key relationships, and even
> with those, no variable structure suggests itself. And then I remember
> this is why I wrote object classes modeling the things I want to get
> out of/put into the database.
>
> Even if your database is so simple that you do just want to model
> single tables, it would be easy to build atop DBI.
I beg to disagree. DBI is complicated and verbose. It takes many lines
of code to do simple things with DBI. Sometimes you don't need that.
I'm going to be a bit annoying here -- I'm going to refer to another
language, and I'm going to recommend that it's of interest to this group.
Briefly: There's a language (K, see www.kx.com), which has been used
to implement a rather elegant (fast, small) sql server. I think its
implementation of multi-dimensional arrays is worth knowing about.
A couple highlights:
[1] sql tables are physically stored as individual columns (a speed
advantage for the problem domain it's aimed at).
[2] the language supports triggers and dependencies. This is much more
general than array slices: this allows simple implementation of sql
views, user interface mechanisms, etc.
On the downside: If you don't already know apl and scheme, you'll have
a steep learning curve with the language. Some people might even call
its syntax "ugly". Also, while the language (and the sql interpreter)
are available for free download, it is a commercial product and no
source is available (if you consider k code to be ugly, this lack of
source code might be something to be grateful for).
FYI,
--
Raul
