Sign in to follow this  
  • entries
    45
  • comments
    115
  • views
    54579

Two paradigms for two use cases

Sign in to follow this  
Kylotan

206 views

I've been arguing about object-relational mappers recently. For those unfamiliar with the concept (and unwilling to check Wikipedia ;) ), it's basically a library or class framework that allows you to use an object in an object-oriented program language and have it automatically backed by a relational database as a persistent data store, as an alternative to explicit serialisation, simplifying your code.

My gripes were twofold:

- one, that adding in an intermediate layer like this needs to be documented absolutely fully, otherwise you're going to hit a corner case you're unable to solve. Making the mapping library open source mitigates this somewhat as you can dig around inside to see what the problem is, but then you start to lose the transparency of the system, which is the main benefit of having it in the first place. Is it worth having wrappers that you keep needing to unwrap? Debatable.

- two, that often what you need from the database doesn't map directly to your objects very well, which is unfortunately what the mapper usually gives you. This is (rather pretentiously) referred to as the object-relational impedance mismatch. Usually it refers to the trouble trying to represent your OO hierarchy in database form, or vice versa. But I think there's another interesting distinction, and that is in how the data is used.

On an abstract level (think 'whole procedure' rather than 'line of code'), when an application is modifying data, it's typically modifying one object at a time. Sometimes it writes out a few sub-objects, but predominantly I'd say that you write to one object. Examples: when your library management system notes a book has been borrowed, it creates a row in a Loan database. Or when you update your game characters, you typically adjust position and AI state of each character in turn with minimal or no writing done to other characters. Generally speaking, you write one thing. When you insert a MIDI note into your music package, you're typically altering a single track.

However, staying on that same level, when you read data you're often reading several objects at once. When the library management system checks for late loans it typically cross-references them with the Users, to generate reminders. When you perform collision detection, you often want a data structure that can instantly give you the subset of characters that lie within a certain distance, to be tested against. When you're playing back your MIDI song, it's pulling events from several tracks and parameters from the instruments and effects simultaneously to generate the output that you hear.

SQL itself recognises this - compare the complexity of typical SELECT statements, both in practice and in what the statement allows for, with the relative brevity of the typical UPDATE or DELETE statement. Whether you consider that deliberate or an artefact of the implementation is another matter, of course.

But this leads me to thinking: is object-orientation fundamentally a data writing paradigm and relational data (and by extension, structural data such as C's structs) a data reading paradigm? Is object-oriented querying inherently cripped by design? And is a relational database generally much poorer for editing data than for storing it?
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now