[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
