« Updated: Goggling at Google's YouTube Buyout Data | Main | Murdoch: CNBC Not Business Friendly »
Latest Stories
- Excel Wankers and Recession Averages
- Sorry, New York is Closed. Check Back Later.
- Catching Falling 2009 Earnings Estimate Knife
- Survivorship Bias in Global Markets
- Talking Positions on a Lazy-ish Retirement Portfolio
February 8, 2007
Rethinking Database Data
The folks at Dabble DB have up a provocative post wondering at why databases have traditionally been so unimaginative about data:I’ve always found it strange that databases are so unimaginative whenGood question, and one that I've long wondered about. Data should be what you say it is, whether it's meetings, an email corpus, or how I spent my summer holidays, or where I lost my car keys. Trouble is, traditional databases -- whether online or offline -- have been too rigid to work with real people on real data, thus forcing the DB analyst priesthood to emerge, with all the corollary irritations.
it comes to data types: text, numbers, dates, times, and not much more
— basically the same low-level options that have been around for
decades. At the same time, people working with data think in much
richer terms: an event happens from 2 to 4 next thursday, a company is
based in Vancouver, BC, and so on.
Anyway, there is lots more at the Dabble site, including the launch of location-centric data fields, as well as nifty charting stuff. Check it out at the blog, or watch a screencast here.
obDisclosure: I'm an investor and therefore horribly conflicted and may be making stuff up, hyping the company, etc. etc.
Sphere It
| 
Digg it
| 
Bookmark it
| 
Stumble it
| 
Facebook it
Databases don't do that for a bunch of reasons. One reason is because they'd all have to agree on what you mean by "next Thursday" and today they can't even agree on what a BIT datatype is supposed to be.
But the main reason is that in the time-work cosmology of application architectures, semantic concepts like "next Thursday" aren't traditionally placed in the data layer of the stack, they're placed in the application layer.
This may be a problem worth solving, although this is one of those things that you never knew was a problem until there's a solution. It'll be interesting to see how Dabble attacks this.
Paul,
Databases will either have to evolve to recognize different types of data automatically, figuring out the best way to store and organize it, or we'll continue down this path for some time to come.
What you are really describing is a semantic engine for said databases, for lack of a better term. Geospatial add ons to Oracle and PostgreSQL are prime examples. They let you interact with the data as it relates to location.
Sounds like the Dabble DB folks are on the right track. I think it will come, but these types of problems are the fun ones, take time to do right and have big payoffs after the hard work is done.