?

Log in

No account? Create an account

The One True Relational Database Model

« previous entry | next entry »
Aug. 12th, 2004 | 07:47 pm
mood: amusedamused
music: Tom "T-Bone" Stankus - Existential Blues

Microsoft has a relational database on the front burner for a future version of Windows. Personally, I think they're barking up the wrong tree. If they spent more time building websites they'd know that hierarchical models with very tight scripting connections offer more performance and a higher level application model. Relational databases are good for factories and stores. Object databases map the model of the Web. Just change the slashes to dots and off you go. - scripting.com

Heirarchical databases and Object databases are arguably subsets of Relational databases. If you think your programming effort needs a 'higher level application model', you should go ahead and use one -- built on top of a relational database. If you have some data that you need to manage professionally, you need the structure and reinforcement that only the relational model can provide. If that means you need to pay me to build you one, then so be it.

If there's a better model than the Relational one out there, I want it caught and shot now to hear about it. Maybe what I mean isn't better model, it's better formalism. Sure, use a flat text file to manage your data. That's better for some projects, some purposes. But it will catch up with you (or better yet, someone else) as the project ages. (For your own sake, recognize when that starts to happen, and re-engineer the project.)

If you go through the excercise of designing a relational database for your data, the nicest thing is, your data will stay that way! almost self-organizing, and it's easy to discover new uses (new ways to use your old data)!

Heirarchical databases collapse under their own inflexibility.

Object databases look pretty but tempt you into omitting some relations that you later have to back-fill using "business rules".

Link | Leave a comment |

Comments {26}

truth without proof

Re: the pure thingness of the things

from: chronicfreetime
date: Aug. 13th, 2004 11:10 am (UTC)
Link

You've not addressed the OO to relational mapping

Databases are for storing data, not behavior. If you can't easily pull some arbitrary tuple of primitive types into your program, I say the fault lies with your choice of language. And associating an in-memory object with each row of each table undermines the utility of a relational database. You can't run a sensible ad hoc query on something you use as backing store for your heap.

I think OO is mostly snake oil, and an unhelpful way of thinking about most programming tasks. But that's another argument. If all you want to do is serialize objects to disk, go ahead, but don't complain that a relational database is a poor tool for that. A relational database is meant to be application independent, because data is immortal.

This has larger applicability, if a user's myriad of contact information, and name, and is always stored on the same disk page as the name, and always being accessed in that method,it makes more sense to keep it there instead of having to go to multiple tables to reconstruct it.

Again, tables are a logical organization, not necessarily a physical one. Throwing away application independence and relational integrity is not the only way to improve performance.

Reply | Parent | Thread

Triple Entendre

"arbitrary tuple" rolls quite sweetly on the tongue

from: triple_entendre
date: Aug. 13th, 2004 11:30 am (UTC)
Link

Neatly put, and right on target. Also, far more informative than my ranting so far. Thank you for that clarity.

I should go take a nap. :)

Reply | Parent | Thread

TroyToy

Re: the pure thingness of the things

from: troyworks
date: Aug. 13th, 2004 12:38 pm (UTC)
Link

Databases are for storing data, not behavior.
A relational database is meant to be application independent, because data is immortal.

an OODB does exactly that, it doesn't store the method information of an object, so that is free to change. Many of the larger OODB's have interfaces with Java, C, .Net. so the data lives on...

Conceptually if you stripped away methods, objects=tables, pointers and composition = table joins. The need to associate an object with anything at all is foreign to me.

We clearly are programming on the opposite ends of the spectrum. OOP is critical to developing clean applications (especially clientside rich user interfaces), and compoenents across multiple providers.

I think a key to our cognitive dissonances ad-hoc query aspect. Ad-hoc queries imply that one has no idea what a user is going to do to with a system here I will grant you RDMBS and SQL is easier to use.

OO modeling typically is the opposite, it defines narrow paths of interaction that fit known use cases which is how applications are typically built. I build more of the former than the latter, while still am free to use Relational when I need to. It's generally 3x more complicated with I have to go that path.

Reply | Parent | Thread

Triple Entendre

Re: the pure thingness of the things

from: triple_entendre
date: Aug. 13th, 2004 01:12 pm (UTC)
Link

I think a key to our cognitive dissonances ad-hoc query aspect. Ad-hoc queries imply that one has no idea what a user is going to do to with a system here I will grant you RDMBS and SQL is easier to use.

I put it to you that "you" (the programmer/designer/architect/etc) are a user of the data and of the system. At the very least, this can/should be true while you are creating it. Experimentation on normalized data in a good IDE with a query design tool will let you discover knowledge about your problem domain, knowledge that emerges as a logical yet inscrutable consequence of gazing upon the data (and poking at it dynamically and rapidly) in as pure a form as you can make it. Things you'd never have thought of if it weren't so easy to offhandedly browse through. deep, obscure correlations. Patterns. Perspective.

Reply | Parent | Thread

Triple Entendre

Re: the pure thingness of the things

from: triple_entendre
date: Aug. 13th, 2004 01:35 pm (UTC)
Link

narrow paths of interaction that fit known use cases

I have trouble imagining that, unless you are rewriting an existing application as-is in-place. Or maybe a "Windows Hardware Installation Wizard".

Use cases are a rather awkward tool for discovering requirements. I suppose they are useful for documenting that you should get paid.

Doesn't OOP in general suggest the exact opposite of "narrow paths of interaction"? Build small, useful components (objects and combinations of objects) that work together as tools to facilitate the user's interaction with data (objects)?

It probably won't surprise you that the majority of my work has been in building "decision support systems" and "data analysis tools". That's my true calling; order from disorder, needles from haystacks. Neatly arranged haystacks, mind you.

Reply | Parent | Thread

TroyToy

Re: the pure thingness of the things

from: troyworks
date: Aug. 13th, 2004 01:56 pm (UTC)
Link

Narrow by meaning relative to a database table: interfaces and defined methods controlling access to private data to prohibit corrupting it. Unlike an SQL statement which can do pretty much anything anyway it wants (good for your case trying to find patterns out of the noise).

The methods on a given object reflect the anticipated useage of it. E.g. a person.getDogName or person.getHairDressor isn't likely to be used on a sales site for books so it's not included in the model. person.getName() is any object who knows to call getName can.

Funny we truly are onthe opposite ends of the development spectrum. I build sites for people around use cases, e.g. an slide presentation and editing system for schools, pretty cut and dry use cases are "view slide" "editing slides". And the last year in a report generating tool for movie analysis (which does use a an RDBMS for the backend, which is mostly abstracted away from the presentation logic (e.g. helping users build valid questions (which get translated into SQL), and lots of nifty features to traverse the data in different ways.

However I have done data analysis of various network like things without a relational database, neural networks, search engine results, and livejournal social networks.

e.g.
http://www.intrio.com/products/graphion/index.htm

Reply | Parent | Thread