[REBOL] Re: SQL (was choice of representation which was paths & lookups & change
From: atruter:labyrinth:au at: 26-Oct-2003 10:02
>> which tells me that the "Contacts" table has a "string" column of 24
>> characters width named "Name".
> That's an innovative convention! Wasn't clear to me though what that
> particular file actually stored - all rows of a single column of data in
> a fixed width form?
All rows of a single column of data (each row a seperate line), the width
(in this example) being display width (mono-spaced character positions).
> If my comment was understatement, your question is the tip of an iceberg!
Leading question I suppose ;)
Agree in full.
> *Perhaps allow some specific REBOL integration not available in the SQL
> parser options - eg. predicates expressed as REBOL expressions perhaps.
This is *the* biggie. If one goes down the SQL parser route then you have
to try and map REBOL expressions to their SQL equivilants, eg:
like?: func [val string][
either find/match/case/with val string "_%" [true][false]
; NOT LIKE
unlike?: func [val string][
either find/match/case/with val string "_%" [false][true]
or accept REBOLisms that take away some of the advantages of a "pure" SQL
implementation in the first place (familiarity and portability).
A well-designed REBOL SQL dialect enables you to leverage the underlying
power of REBOL (much like VID does) without the translation / mapping
overhead (ie. expressions are evaluated directly).
> It might be useful to have both, making the SQL parser subordinate (a
> helper) to the SQL dialect.
Not a bad idea in theory, although my impression after working with a
large variety of RDBMS's over the years is that very few people use
low-level API hooks when generic SQL equivilants are available. I guess
familiarity and portability are the big ticket items to most folks (IMHO).
> It costs me nothing to throw out these ideas, actually building the stuff
> could be challenging :-)
It has been. Thanks for the stimulating discussion ;)