views:

440

answers:

4

I'm thinking of designing & implementing my own SQL-equivalent (DDL+DML) that is...

  1. a pure relational algebraic language, and
  2. has an elegant Lisp-/Scheme-like syntax

Assuming an RDBMS such as MySQL, where exactly would I need to start my language design work? On top of the storage engine layer such as InnoDB?

I don't know what all RDBMS functionality generally sits atop a Storage Engine? My current intuitive understanding is that the bulk of the work needed to create an RDBMS (such as MySQL) would already have been done within the storage engine (specifically, in InnoDB), and all you would need to do is create a wrapper language around it. But I also know that if that were really true, why would MySQL be existing in the first place!

+4  A: 

I suspect that the best way to go around this would be to create a translator between your language and SQL, mainly because you won't be able to get more functionality from a rdbms than what's provided via its SQL dialect.

MySQL existence has nothing to do with the difficulty of the work done by storage engines, storage engines in MySQL really do most of the grunt work, leaving MySQL to parse and optimize SQL and the retrieve the data from the engine, respecting the corresponding semantics of the engine.

Most rdbms do not expose storage engines to users/administrators so in that respect MySQL is somewhat unique, which makes more reasonable to create a translator, that way you'll be able (by changing a few syntax rules) to use more than one rdbms via your app.

Additionally, you probably won't be able to generate a pure relational language over existing database technology, check The Third Manifesto for more information.

All that said, I would really first look at all existing SQL wrappers, maybe some will suit your taste.

Vinko Vrsalovic
Yes, that was helpful. Thanks, Vinko!
+1  A: 

Many rdbms products traditionally have been built on isam packages - mysql is an obvious example. They all operate at the level of specifying tables and indexes, iterating rows, etc.; with basic facilities to handle reads, writes, locks, etc.

Furthermore, most of the isam products have needed to add SQL layers on top for competitive reasons. You could start googling through those for examples where the SQL layer might be available.

le dorfier
+5  A: 

It shouldn't take you long if you actually write it in lisp. I wrote a simple database engine in Lisp in about an afternoon. Here's an example of what it looks like:

(select movies (<= 1990 year 2000) (member director '(terry-gilliam tim-burton)))

Here, 'select' is a macro. It scans the predicates that follow it for symbols that are field names and binds them to the fields in the database. Then it writes a function that binds those fields to the values of a record passed to the function, and filters the table using that function. The macro expands to something like this:

(flet ((filter (item)
        (let ((year (movie-year item))
              (director (movie-director item)))
         (and (<= 1990 year 2000)
              (member director '(terry-gilliam tim-burton))))))
 (loop for item in movies
       if (filter item) collect item))

The cool thing about doing it this way (actually in Lisp, rather than just using a Lisp-like syntax) is that you get compilation for free. On my system, the code above isn't interpreted by the database engine, it's actually a compiled part of the program (can't do that in C, now can you?). As a result it's fast, even though the database code itself (the code for 'select' and table definitions) is only a few lines long. The database is entirely memory resident, but it doesn't matter... you could just change the macro to accommodate external databases and even write it do use indices. It was good enough for the project I was working on, so I didn't add indices or anything fancy.

My favorite part about it is that while it keeps all the conciseness of SQL, the code is no different than the code around it because it's all Lisp. You can introduce variables into your search term without having to worry about quoting them.

Dietrich Epp
Wow... Lisp is cool. +1
Zifre
+1  A: 

In Practical Common Lisp, this chapter aims a simple RDBS style interface to a Music database. Might help.

Amit