Dr. Dobb's Journal - December 2007 - (Page 20)

d12Conver_p3ma 10/11/07 9:59 AM Page 20 Conversations by Deirdre Blake Databases: Yesterday, Today, and Tomorrow Jim Starkey Jim Starkey is a Senior Software Architect for MySQL. DDJ: When it comes to database development, what are the advantages of open source? JS: There are three big advantages right up front. One is that there are umpteen thousand very smart folks reviewing and testing the code. Another is the knowledge that those umpteen thousand aren’t going to take “good enough for government work” as an excuse. Every line of code I write, I imagine the questions I’ll get on it at the next MySQL User Conference session on Falcon [a transactional database engine for MySQL]. Finally, software types are, by nature, glory hounds. Open source brings out the best in us. DDJ: How do you balance performance, security, and ease-of-use in database design? JS: The question should be, “How do you balance performance, security, ease-of-use, and Standard conformance…”—because without Standard conformance, it would be a great deal easier! Take, for example, data types. The SQL Standard shows its roots in punched cards with nothing but fixed-length types—fixed-size integers, fixed-size strings, and varying strings with fixed limits. Most engines actually store the data in fixed-length chunks, so the user has to choose between flexibility (types big enough to handle the worst case) and performance. Falcon stores data by actual value rather than declared type. This removes any performance penalty for over-specifying a field. The value “5” takes the same space whether declared as a tiny integer, small integer, large integer, or really-big-I-mean-itthis-time integer. But what a bother mapping back and forth between fixed-length declaration and variablelength storage! If the Standard would let us, the user could just say, “It’s a number—Just deal with it.” Modern languages and frameworks have strings without size. Why not databases? So that’s how I prefer to deal with ease-of-use versus performance: Make it easy for the user to let the software do the smart thing. Security is a particularly nasty problem. The SQL security model was developed before many of today’s database guys were born. It’s designed for timesharing systems where humans on hard copy terminals shared databases. Now, virtually all database access goes though application servers. The server logon doesn’t represent the actual client, which it won’t know for a query or two. Also, access control or visibility needs to be at the row, not table, level. Isn’t it time that the database community recognizes this? DDJ: The relational model has held up well. How come? JS: A number of reasons. One is that the unit of work is big enough to be worth optimizing. Another is relational operations work on sets of data objects, making it a reasonably good model for remote access. Finally, it’s a clean model that doesn’t encourage design cuteness. I became enamored with the relational model after reading one of Codd’s early papers. I was working on the ARPAnet Datacomputer project (the Net was pushing 45 computers at the time, which was pretty exciting). That said, there is a great deal of room for improvement on the relational model. Much data just doesn’t fit into rectangular tables. Shirts, for example, have different attributes than do pants, but both are clothing. Sometimes you want to see shirts, sometimes pants, and sometimes all clothing. Handling this within a relational database requires standing on 20 Dr. Dobb’s Journal l www.ddj.com l December 2007 one’s head. The semantic data model, circa 1978, is a tiny but elegant extension to the relational model to deal with type hierarchies. It’s a little embarrassing that we haven’t figured this out yet. DDJ: Other than size, do embedded environments put extra demands on databases? Reliability, for instance? JS: I think we can agree that context switches or network round trips are bad things for application performance. On the other hand, modern database engines are getting quite greedy about memory and processors, so having lots of embedded database instances floating around a system doesn’t make all that much sense. Rather than embedding the database engine in the application, wouldn’t it make sense to embed the application in the database server? A bunch of happy applications each doing super-fast in-thread queries in nice sandboxes disgorging their results in a single blast of data is a pretty good way to structure things. I think we’ve come around a number of circles. We started with blobs because they were unlimited in size, but soon all fields will be unlimited, so blobs can fade away. The relational model was good because it was simple, but now needs semantic extensions to keep it alive going forward. SQL was once good because it worked well on a network, but SQL on the wire is now the limiting factor in system performance. To save it, we need to get off the wire and into a sandbox within the database server. To do that, we need to learn to think differently about how applications are designed and deployed. There’s the old story about a greatgrandfather’s axe that had its head replaced twice and its handle three times. That’s where I think relational databases are going. We’ll change the data model, the data types, the application topology, and the network interface, but they’ll still be relational databases. DDJ http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - December 2007

Dr. Dobb's Journal - December 2007 Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook Computer Books: Reading Between the Lines Conversations Query Anything with SQLite XQuery Web Maps with the Google Map API OpenALM and Its Manifesto Transactional Programming Effective Concurrency The Agile Edge Swaine’s Flames

Dr. Dobb's Journal - December 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.