A few notes from the History of Database Systems BoF

I will not write much on what went on at this BoF, but a few words are appropriate I guess.

• We were some 10 to 15 people in the room at the end.
• I started the thing by talking about the ancient history of databases, and went on to talk a bit on the reasons of the Relational databases appeared on the scene.
• We talked more on these reasons. The old Network and Hierarchical were largely tape oriented, even when data was on disk.
• My theory on search being a very major factor for adopting the relational database technology in the 1970s and on seemed to be accepted.
• As I went on to discuss search in an RDBMS being contextual, and the need for non-contextual search caused quite a few debates.
• That non-contextual search will be a factor in moving to NoSQL, as is a theory of mine, was not accepted by anyone else but myself :-)
• Contextual and non-contextual serach means, and if this even is search and what these terms mean was discussed in gruesome detail.
• This brought on a NoSQL debate that lasted till the end of the BoF.
• That NoSQL is about performance was largely accepted.
• That key-value storage is a key behind performance was not (and I sure don't see it that way).
• The value of a Key-Value store in itself was discussed in detail. Are we just storing any kind unstructured data as a Value, or is it XML (which is most the case currently) or an Instance of an object.
• We alsodebated the storing on a set, as in an RDBMS, vs. an Instance, as a key-value store may be seen, was also debated. And if an RDBMS really is set-oriented and if a K-V store stores an instance was a hot topic.
• I think we eneded up with a notion that we will probably see a mix of RDBMS and K-V stores in the future, that they are complementary in the short to mid-term.
• In the long terms, I claimed that a K-V store will not persist as a generic solution, as it actually has less functionality than an RDBMS, whereas other claimed that a K-V store applied properly with instances and instance pointers ´within values is the way to go.
• Whatever happens, it will be interesting.

Thank you everyone for participating in the debate, it was enlightening to me, and I hope you at least had some fun and learnt something also. And I hope I didn't take up too much space myself in this debate.

/Karlsson

BoF only special - See an incredibly ugly Oracle T-Shirt!

Yes, no kidding, I'll be wearing an old Oracle T-Shirt from my days at Big-O in the 1980's. I was, and your Oracle dudes who has been around for a while might remember these, an Oracle Unix Wizard. Actually I was a Wizard II (I went to the second training), but the T-Shirt I will be wearing is from Oracle Unix Wizards I.

Where will this take place you ask, as you just HAVE to come? Well, no further than my BoF tonite on the History on Databases. And I can tell you, this is not a T-Shirt that I would normally wear in public, but there is a lot of stuff I would do to attract a crowd to a BoF (just to see everyone running away in disgust). So at 7:00 PM tonite, tuesday, in Ballroom C (unless the location changes). Bring your good mood, ideas on the past and on the future, and above all, your barf-bags, to see what an ""Oracle Unix Wizard" looked like in the 1980's, although with a bit less gut..

/Karlsson

Searching in databases - Maybe what will drive the next wave

In the old days, before SQL and Relational and all that, not when Vikings toured the world, drinking, being violent and causing mayhem, but still in the old days, the databases in use, the first reasonably generic database systems, were Hierarchical or Network based. These had a strict schema and data was extracted by navigation (i.e. Find company X, find orders for company X, find items etc.), and there was no way of searching data (which wasn't much of a problem, as data was largely stored on tape anyway, which isn't really searchable in the now common sense).

When SQL came around, the relations style schema allowed a much more free way of navigating data, and it also allowed searching. The SQL search as we know it is still contextual (i.e. you have to specify what to search, a SELECT from a customer table based on address, will not retrieve employees with a matching address). All the same, when SQL came around, the ability to search and the relatively free structure of data relationships would take database use to a new level.

But searching today is often compared to Google, and this kind of search is really non-contextual. This is an area where the NoSQL movement has an edge on SQL, mostly because of the largely schema-free nature of NoSQL implementations. If search was a main driving force towards SQL, will the same happen with NoSQL? Maybe, I'm not sure. What I AM sure of though, is that we need to develop SQL and the relational model to support more schema-free operations, mainly search, but I think there are other areas where this is relevant. And will this be the final nail in the coffin of true SQL systems? I'm sure it's not, we can enhance the functionality in the SQL-based RDBMS without wreaking havoc with relational algebra, somehow. But any SQL-based RDBMS that will stay around needs to have some support for data that is non-structured.

So why will a SQL based RDBMS with support for unstructured data and searching be better than a plain NoSQL implementation? In my mind, this will be the case as NOT ALL DATA is unstructured. Customer information, credit card payment data, product catalogs and stuff is distinctly structured, and a SQL based RDBMS enhanced to support non-structured data will potentially allow you to work with any kind of data, structured or non-structured.

So, having one piece of software handle different types of data, is that really a good idea? In my mind, it is, as the deal here is that even if this data is a mix of structured and unstructured, the different sets of data is still related, and it is relevant to combine operations of both of them, as one set of data.

/Karlsson

While at the MySQL UC, pop by the Computer History Museum

If you are coming to the MySQL User Conference, you might want to pop by the Computer History Muesum. The CHM is in Mountain View, jus off the 101. If you have a car, just take the 101 and get off at Shoreline, it's just on the east side of the 101. If you don't have a car, you can get there anyway, from the UC take the light railway to Mountain View and then you can walk (some 20 minutes or so, not the nicest of walks, across the 101, but it's possible, I've done it) or take a bus from Mountain View.

At the CMH, among other cool things, is Babbage's Difference Engine in working order, a mechanical computer. That Babbagewas a smart dude is obvious from the fact that he never finished building the machine, although he designed it, and when now built using his original designs, it actually worked! I mean, the whole concept of designing the thing first, it truly weird, along the lines of code documentation that is actually correct and commented code that is actually helpful, two arcane ideas that I find very hard to grasp. The machine is demonstrated at the museum, and I think there is work in place to make it run Linux. (yes, that is a Joke, it's just barely powerful enough to run DOS).

The PDP-1 restoration project at the CHM is also interesting as is many other things there, so a visit to CHM is recommended.

/Karlsson

The History of Databases at the MySQL UC

At the UC, I will be moderating a BoF session on the History of Database Systems on Tuesday evening at 19:00 PM. I plan and hope that this will be an open discussion, the topics I would want to discuss are:

• The history (I will prepare a few things myself in this area).
• The current state of things (SQL, the state of the "old" technologies (Network, File bases, Hierarchical) etc.
• "Failed" technologies (ORDBMS, Object databases etc).
  
• What's coming down the road (Specialized database systems, NoSQL, BI orieted systems, Column based stores with SQL or not)

I would be glad f you would attend, I'd really like this discussion and subject, and after it, I'd enjoy a beer in the bar, but that was obvious I guess.

/Karlsson