The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

DBMS design

I'm going to create a small, experimental database management system that will support its own custom query language.

Over the last few decades, countless commercial and open source SQL DMBSs have been released, and many have found use in production environments, so I imagine there must be established best practices for DBMS design by now. The problem is, I don't know what they are. Short of scouring the source code of PostgreSQL, MySQL and Firebird, are there any good ways to educate myself about DBMS design? Are there books you could recommend, tutorials or white papers you could point to?

Thanks.
Leo
Friday, October 27, 2006
 
 
Don't waste your time. There are more than enough database maagement systems out there already. The idea of having your own query language instead of industry-standard SQL is a complete no-no. Why bother with a new product when there are plenty already? Why bother with a new product which has a totally new syntax to learn, and which probably doesn't have API's for all the popular languages?
Tony Marston Send private email
Friday, October 27, 2006
 
 
Hey Tony - they key word was "Experimental".

SQL is great - a universal language for all relational databases (thanks to Ted Codd) but it's a long way from perfect. There is certainly demand for something much close to a "natural" language - although I suspect that this would always have to be "domain specific".

So I recomend downloading the source for SQLite
 http://www.sqlight.org
as a start point provided your "C" is up to it. The approach here is simple and straightforward and I would have thought a grand code base to try out some new ideas.
Mike Griffiths Send private email
Friday, October 27, 2006
 
 
Just don't expect anybody to use it. SQL, for whatever theoretical faults it may have, it 100% accepted and implemented, and implemented well. Can't see the point of it.
Steve Hirsch Send private email
Friday, October 27, 2006
 
 
Actually, why not focus on building a database that works in situations where SQL doesn't do too well. Tree-based data is a good example - you can do it in SQL but it isn't much fun.

I'd suggest finding a niche and do that *really* well - don't try and compete as yet-another-relational-database.

Good luck!
Arethuza Send private email
Friday, October 27, 2006
 
 
How about a properly relational database? I don't think that natural language is the way to go, myself. Reltaional algebra would be cool.
David Aldridge Send private email
Friday, October 27, 2006
 
 
"SQL is great - a universal language for all relational databases (thanks to Ted Codd) but it's a long way from perfect. There is certainly demand for something much close to a "natural" language"

Yes, but I don't understand why someone would want to create a new database from the ground up.  Why not build an interface that translates natural language queries into SQL?  Components like this one already get pretty close, though someone knowledgeable has to create the table links behind the scenes:  http://devtools.korzh.com/eq/
Herbert Sitz Send private email
Friday, October 27, 2006
 
 
Here's a screen shot that shows the ordinary language input to EasyQuery and the SQL it generates to return the results:
http://devtools.korzh.com/eq/images/sshot_eq1.gif
Herbert Sitz Send private email
Friday, October 27, 2006
 
 
Trivia: Dr. Codd considered SQL an abomination of a language as it lacked the full expressive power of relational calculus but IBM insisted it had to be 'friendlier'...
Mike S. Send private email
Friday, October 27, 2006
 
 
There is no truly relational database engine on the market period.

If you want to do a new RDBMS, read The Third Manifesto.

ISBN: 0201709287

I use Sql everyday and all the current database engines suck.

http://en.wikipedia.org/wiki/Relational_model
D in PHX Send private email
Friday, October 27, 2006
 
 
Don't listen to the naysayers. The idea that the big, bloated, commercial RDBMS are the last word in rdbms design and implementation is nonsense. 

As noted above, for theory, read Darwen and Date's Third Manisfestpo. Read everything else by C.J. Date including his collected writings and his most recent "Database in Depth".

For conventional implementiona see "Database System Implementation" By Hector Garcia-Molina et al. See also "Concurrency Control and Recovery in Database Systems." By P.A Berntein, et al. Finally, see "Readings in Datbase Systems", edited by Hellerstein and Stonebreaker.

Also, check out alternative implementations like column stores (Google c-store, a Stonebreaker project.)

And while you are at at, you should look into temporal database design as well. See Microsoft's "ImmortalDB" project for links to technical papers.

Good luck.
Paul Mansour Send private email
Friday, October 27, 2006
 
 
I just love the folks who reply to an OP by saying either (1) "Why do you want to do it that way?" or (2) "That's stupid." or (3) both. Just do all of us a favor and refrain from posting.

To actually answer the OP's question along with Paul, a good, solid book that'll get you up to speed on standard relational database design is "Database Design," by Ryan Staphens and Ronald Plew.

http://www.amazon.com/Database-Design-Sams-Teach-Yourself/dp/0672317583/sr=1-8/qid=1161970382/ref=sr_1_8/104-5519139-8378332?ie=UTF8&s=books

I read it from cover to cover some years ago and found it to be very helpful.
Albi-wan
Friday, October 27, 2006
 
 
Sorry. Ryan Stephens, not Staphens.
Albi-wan
Friday, October 27, 2006
 
 
"I just love the folks who reply to an OP by saying either (1) "Why do you want to do it that way?" or (2) "That's stupid." or (3) both. Just do all of us a favor and refrain from posting."

Sorry, but that's a bunch of bull.  How are we to know whether the OP has investigated all the options?  Are we supposed to assume that the OP already knows more than we do, and if so, why are we to assume that the OP is posting here for help?  I realize full well that not all of my posts are helpful, but there's basically no way to know beforehand which are going to be helpful and which aren't.  So cool your jets, and please don't suggest to me that I refrain from posting.

"To actually answer the OP's question along with Paul, a good, solid book that'll get you up to speed on standard relational database design is "Database Design," by Ryan Staphens and Ronald Plew."

I agree that OP should be working with a relational database.  But SQL is pretty well optimized to query relational db's.  No, SQL is not perfect, but please explain how reading a database on relational database design going to help design a natural language query system?  SQL has already pretty well distilled out all the set-based operations in a relational db in an understandable way.  So why not just use an existing SQL db, and build a layer that translates natural language into SQL? 

If OP does want to start from scratch to build a relational db with a natural language query system (which I think is a hugely inefficient use of resources and probably doomed to failure, but I suppose it could be fun), then I would recommend starting from one of the open source databases and modifying for your needs.  Most of them are written in C or C++ (e.g., Firebird and PostgreSQL) but there are some in other languages (e.g., Flashfiler is written in ObjectPascal/Delphi).
Herbert Sitz Send private email
Friday, October 27, 2006
 
 
I'll reiterate that I don't like the natural language approach. There're reasons why we don't write code in natural language, and it's because it's too verbose, too vague, and code complexity can easily exceed the ability of natural language to express it in any succinct manner. You can get away with it for simple queries but that's not where the power of the language resides.

i'll tell you something else that might be interesting. Oracle has a wait interface that allows system or session "wait events" to be written to a trace file or queried in aggregate from system views. It's an extraordinarily powerful tuning mechanism that tells you not only (for example) how long the session spent waiting for single block disk reads (for example) or log file syncs but how much performance can be improved by eliminating or reducing those waits.

http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#BGGIBDJI
http://www.oracle.com/technology/pub/articles/schumacher_10gwait.html

It would be interesting to get involved in an existing open source project to get that kind of functionality built into it, no?
David Aldridge Send private email
Friday, October 27, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz