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

[REBOL] Re: choice of representation - was paths & lookups & change

From: brett:codeconscious at: 25-Oct-2003 11:13

Hi Ashley, Interesting samples and comments.
> I also try to store as much meta-data in the file-system as I can, for > example, I may have a file like the following: > > /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?
> > Another interesting line of discussion would be on > > useful REBOL idioms when programming a REBOL app to talk SQL. > > Understatement! Having spent the last year [on and off] designing a REBOL > RDBMS, I can assure you that there is more to it than will fit in a quick > email reply (I am writing my "thesis" [ie. documentation] on my REBOL > RDBMS design as we speak). ;) An interesting question that this raises: Is > it better to have a SQL parser or a SQL dialect?
If my comment was understatement, your question is the tip of an iceberg! :-) 1) Assuming the SQL parser vs SQL dialect question is relating to your RDBMS, A SQL parser for your RDBMS would: *Be great for fast take up by people who already know SQL - could be an very important factor. *Mean your RDBMS is swappable with other RDBMSs. *The cost is the loss of specific REBOL integration with the database, because a "semantic barrier" has been errected (namely SQL) for good and bad. A SQL Dialect for your RDBMS would: *Allow REBOL database client scripts to embed, generate, load, mainpulate queries as REBOL values instead of doing those operations with hard to manipulate strings. *Perhaps allow some specific REBOL integration not available in the SQL parser options - eg. predicates expressed as REBOL expressions perhaps. 2) If your question of SQL parser vs SQL dialect is separated from your RDBMS - reprhasing it like "Would it be more useful to have a SQL parser or a SQL dialect in REBOL?" then different ideas emerge: It might be useful to have both, making the SQL parser subordinate (a helper) to the SQL dialect. *A REBOL client program can use the SQL dialect to generate/load/manipulate SQL that will be sent to an external DB. Side note, the current REBOL command database interface has parameter markers to fill in bits of the SQL with REBOL values, but I was thinking of something more sophisticated. *The dialect could emit different SQL depending on different DB backends to take account of extensions and differences. *A higher order dialect might provide some value-add like transaction control or tracing. 3) Reconcile (1) and (2)? Create the SQL parser and SQL dialects as standalone, and a way to do translate backward and forwards between them. Allowing them to be used where they are needed. After all with your RDBMS, if you accept SQL you'll need to create a query plan at some point, one of the steps to do that could be a translation into a SQL dialect (a relational algebra?). It costs me nothing to throw out these ideas, actually building the stuff could be challenging :-) Regards, Brett