VoltDB: Is a database without foreign keys useful enough for you?

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

In the previous post we have announced the availability of our UML to VoltDB translation service . However, if you try it, you may get the feeling that the generated SQL script looks incomplete.

For instance, the generated script for this very simple UML class diagram

is the following:


  CREATE TABLE Author_rt(
    id INTEGER NOT NULL ,
    name VARCHAR(40) NOT NULL ,
    CONSTRAINT pk_Author PRIMARY KEY (id)
  );

  CREATE TABLE Book_rt(
    id INTEGER NOT NULL ,
    title VARCHAR(40) NOT NULL ,
    numPages VARCHAR(40) NOT NULL ,
    free INTEGER NOT NULL ,
    writer INTEGER NOT NULL ,
    CONSTRAINT pk_Book PRIMARY KEY (id)
  );

There are several things missing in this example (compared to what the UMLtoDB service generates for other DBMSs):

  • DROP sentences to remove previous versions of the tables
  • CHECK constraints that help us to implement boolean attributes (since the Boolean datatype is not supported)
  • and, more importantly, FOREIGN KEYs that ensure that the value of a writer column corresponds to an existing author id in the Author table

Given that data consistency is one of the advantatges that VoltDB creators see over NoSQL approaches (from the VoltDB web page “NoSQL … requires the application developer to manage the complexities of data consistency, VoltDB handles data integrity and consistency for you”), this seems surprising. As happened with MySQL, they will probably add support for Foreign Keys at some point (hopefully sooner than later though, right now, this is not explicitly listed in the product roadmap ) but until then this is really annoying.

I have no intention to go back in time, when referential integrity still had to be checked at the code-level (btw, I’m young enough NOT TO have developed applications FOR pre-relational databases but old enough TO have had TO deal WITH the migration OF such apps). OF course, this does NOT affect the relevance OF VoltDB IN many domains AND FOR many types OF applications but I think I’ll pass for now.

And you? How important are FKs in the kind of application you develop? If you have efficiency problems, would you be willing to sacrifice FKs (and check constraints,…) or moving to VoltDB would be only used as last resource? Leave your comments below!!

If you enjoyed this post you can subscribe to this Software Modeling blog and/or follow me on twitter or through the portal’s mailing list . AND if you really liked it help me pass it ON TO others by bookmarking AND sharing the post USING the links below:

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone
Comments
  1. Anonymous
  2. jordi
  3. Anonymous

Reply

Your email address will not be published. Required fields are marked *