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 when
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.

Good 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.

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.

Related posts:

  1. Database Nation
  2. The Molecular Biology Database Explosion
  3. Swivel: Playing with Data for Fun and Profit
  4. The Web is the Database
  5. Drive-By Data & Web 2.0

Comments

  1. Keith Veleba says:

    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.

  2. 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.