Database preferences

[btiffin]

Hello again,

Another curiosity question. I'd like to ask the board what they think of database technology. Do you have a preference?

SQL? OO? Handrolled? Do you care how well the database engine merges with the programming language being used?

My answers;
I was part of a team that rolled a very efffective ticketing and line record solution for a large phone company.
This was a Forth application and we developed an engine that used the same conceptual threading that the polyFORTH engine uses for code and word definitions. This meant queries were executed instead of being comparison loops. Super fast, but a little technical for normal people, so we had to wrap most of it in a command language. The project had a life expectancy of 8ish years, but it has lasted in production for 20+ years and still counting.

Now with REBOL, a new database engine has emerged. TRETBASE http://www.tretbase.com I'm a huge fan of this little engine, 30K source and lots and lots of power, as it conceptually follows the REBOL code model. Queries are REBOL expressions and on each record match, the result set is also a form of REBOL expression. Sweet.

It allows for what I call the immersive programming experience. You start thinking REBOL and you keep thinking REBOL. No mental swap to SQL commands or Object methods that (for me) disrupt the craft and creative flow. (Now if I can ever got off my duff and code up a REBOL console source editor I'll be able to get up in the morning, enter REBOL mindspace and never leave to get productive work done. The last steps to the very rare and elusive, totally immersive programming experience).

TRETBASE follows a master table, multiple database model keeping disk management very umm, manageable. Another sweet spot.

In REBOL space, the major players are handrolled (REBOL is designed with message passing features so saving and loading any REBOL data structures, large or small are as close as the SAVE/ALL and LOAD functions), RebDB (based on SQL syntax and super easy to use), NicomDB a new entry out of Denmark, and now TRETBASE; all on the REBOL source code side. rebols have also coded up interfaces to SQLite and MySQL which seems the trend in web space so these link well with REBOL's very powerful and easy to use CGI mode and X-Internet features. Commercial REBOL allows for ODBC as well.

So I'm curious if the compsci membership have any favourite engines, or if such a topic even makes into the curriculum in this, the 3rd millennium.

And I'll reiterate; I much prefer a database engine that lets me stay in the zone of the programming language I'm using, especially if it can be effectively used from that language's interactive console.

Cheers and as always, Thanks

[jernst]

I usually just stick with mysql because its been free and fairly easy to use. Last semester I took an advanced database class where we did some comparisons with different embedded / tiny footprint dbs and some of those were cool. The guy who taught the course worked for IBM and was big on alot of their products but I actually found some of them to be quite useful. The embedded dbs didnt support the full feature set that alot of the full sized db systems have but for their size they were pretty cool. I can't remember all of the names of the ones we heard about but my report compared the embedded Berkley db to Apache Derby.

[btiffin]

Thanks jernst. Good info.

Cheers

[wtd]

If I absolutely need to, my preference would be Postgres, with ActiveRecord covering up the icky SQL bits.

[Tony]

With ActiveRecord covering up the SQL bits, it doesn't really matter what's running in back-end. At least not from development standpoint.

Except that ActiveRecord is not yet advanced enough to be able to always optimize better than I can (and loading 3000 instances of the User model to do a fancy sort in Ruby is a shitty performance idea). So I end up writing parts of the icky SQL anyway... in MySQL flavour.

[btiffin]

So just so I'm not crossing signals in my brain; It seems that tight integration with the programming language at hand is not as important as performance or availability? Thinking "this part is database mode" while programming is ok?

Now I'll ask a followup. Is that by choice or by necessity and lack of dB technology "inside" programming languages?

If say, Ruby had a language feature (not an import module mind; something that wraps a SQLite or some other external engine, but a core feature) that supported a simple dB technology - perhaps slower than engines such as MySQL or Postgres - would you use it? I only use Ruby as an example; Ruby is rarely my first choice of language, hope you get what I am aiming at here. Would adding dB tech to a language be a hinderance (or unused feature) or a boon in your esteemed opinions?

Thanks for the replies.

[jernst]

I don't think its really all that necessary to have the db built right into the programming language. As long as there is a driver that lets one use the db easily enough thats usually good enough for me. But if it could be something that could be compiled into the language or added as an extra package then that would be pretty cool. Personally I prefer an easy to use db than one thats fast but I suppose my opinion would change if I were ever to work on an application where speed is necessary. For instance, the guy who taught the course from IBM mentioned a scenario where they were getting data from a satellite and it was coming in faster than the DB could write the information because of inefficient SQL statements. I guess it all just comes down to what I'm using it for. I could see situations when either is good.

[Tony]

Besides drivers I would also like a level of abstraction away from the database. I really would like to not have to worry about Oracle lacking autoincrementing fields, for example.

The abstraction brings the database more into the realm of the programming language itself. ActiveRecord is absolute magic for integrating the database into the framework. The problem though, is that SQL itself is more expressive and thus more powerful when it comes to DB operations. Abstraction is really nice, but things get messy as soon as you attempt anything non-trivial.

[btiffin]

Awesome feedback as usual. Thanks again. As with all things statistical, I'll take this limited sample for what it is, but I put a lot of faith in the answers I receive here.

Cheers