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

SQL (was choice of representation which was paths & lookups & change

 [1/2] from: atruter:labyrinth:au at: 26-Oct-2003 10:02


Hi Brett,
>> /c/rSQL/Contacts/Name.s24 >>
<<quoted lines omitted: 3>>
> 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

 [2/2] from: brett::codeconscious::com at: 27-Oct-2003 0:39


Hi Ashley,
> > 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).
I was thinking in terms of handling different SQL text rather DLL calls. In the dim dark recesses of my mind I recall Powerbuilder building different SQL text depending on the database (most was the same of course). Can't recall the specifics unfortunately.
> It has been. Thanks for the stimulating discussion ;)
Thank you too. Regards, Brett.

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted