Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: SQL (was choice of representation which was paths & lookups & change

From: atruter:labyrinth:au at: 26-Oct-2003 10:02

Hi Brett,
>> /c/rSQL/Contacts/Name.s24 >> >> 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 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 ;) Regards, Ashley