Are databases and OOP natural enemies?

[Barnaby W. Füi]

Ok, so you wanna make the perfect layout for your database-driven project. You make your classes for all the various things you want classes for, and you design it so it's super elegant and easy and whatnot. But the problem is that every object you instantiate needs to grab data from the database, so you have tons of little queries running around, where the optimal solution (from a database standpoint) would be as few queries as possible. The problem with that solution is that you need to structure everything around database queries, which is less than wonderful design-wise. So what's the solution? IS there one? Or is it just a matter of balancing speed with elegance, depending on the situation?

 

[arcain]

Use an OO database??

Or.. (this was posted on slashdot awhile ago) use something like object prevalence.

 

[Barnaby W. Füi]

By "object database" do you just mean serializing and storing the objects? That still wouldn't help, the info would need to be updated whenever it was viewed.

The object prevalence thing seems similar but I don't have time to read through it right this second.

Basically, the database is absolutely needed, it can't be replaced with something else. I want to know if there are better ways to get oop and databases to coexist in an efficient form.

 

[Barnaby W. Füi]

Nice. I just decided to revisit this thread, and as I was typing up some pseudo-code to explain what I meant, a lightbulb went off in my head, and it was all of a sudden so clear. I was seeing the imperative, non-OO way of doing it (arrays, etc), and then the totally OO way of doing it (i.e. totally ignoring the fact that there's a DB under there). What I failed to imagine was a hyrbrid of the two. You can suspend your OO nirvana for a second or two, and load some data from a function that returns all of your data from the database in as few queries as possible, and then sift through that, creating your objects. You can then get by with only a tiny bit of non-OO-ness, keeping all of the benefits of OOP, and have good speed. It's all so clear now!

 

[notfred]

Originally posted by: BingBongWongFooey
Nice. I just decided to revisit this thread, and as I was typing up some pseudo-code to explain what I meant, a lightbulb went off in my head, and it was all of a sudden so clear. I was seeing the imperative, non-OO way of doing it (arrays, etc), and then the totally OO way of doing it (i.e. totally ignoring the fact that there's a DB under there). What I failed to imagine was a hyrbrid of the two. You can suspend your OO nirvana for a second or two, and load some data from a function that returns all of your data from the database in as few queries as possible, and then sift through that, creating your objects. You can then get by with only a tiny bit of non-OO-ness, keeping all of the benefits of OOP, and have good speed. It's all so clear now!

Heh, that's what I thought of as soon as I read the first post

 

[Barnaby W. Füi]

Originally posted by: notfred

Originally posted by: BingBongWongFooey
Nice. I just decided to revisit this thread, and as I was typing up some pseudo-code to explain what I meant, a lightbulb went off in my head, and it was all of a sudden so clear. I was seeing the imperative, non-OO way of doing it (arrays, etc), and then the totally OO way of doing it (i.e. totally ignoring the fact that there's a DB under there). What I failed to imagine was a hyrbrid of the two. You can suspend your OO nirvana for a second or two, and load some data from a function that returns all of your data from the database in as few queries as possible, and then sift through that, creating your objects. You can then get by with only a tiny bit of non-OO-ness, keeping all of the benefits of OOP, and have good speed. It's all so clear now!

Heh, that's what I thought of as soon as I read the first post

Great minds think alike.

So do ours

 

[jonmullen]

Thats how I go about it on my current project. I have some DLL's that handle all the data retrival that I need and gives me objects to work with.

 

[Jadow]

I am oom

 

[Descartes]

You need to read Martin Fowler's PoEAA book. It discusses many of the various architectural patterns with respect to object-relational mapping. There are Java and C# examples, but the concept applies to any language. This is a pretty common architectural issue with respect to a system of any size.

Microsoft's "Yukon" SQL Server release embeds the .NET CLR in the database engine, so much of the issues with respect to object-relational mapping is negated, at least in part. Again, I know you don't like .NET, but the concepts apply to all.

 

[Barnaby W. Füi]

That PoEAA book looks really cool, but $50 makes it seem a little less cool :-/

 

[Barnaby W. Füi]

Looks like building things from the "bottom up" also is a good idea. I.e. instead of just blindly creating some objects which create their own objects, and having who knows how many different instances of the same objects, build the bottom most objects first, then pass references to their containing objects, then just keep going till you get to the top of the hierarchy.

 

[Descartes]

That's one way of doing it, yes. In the past I've also built an domain model layer as an abstraction on top of a simple persistence layer generated from my database schema. For example, I'd generate a class for a single table containing all the typical CRUD (create, read, update, delete) operations in the data access classes for Add, Remove, Update, Delete, and then of course your retrieval operations (e.g. Select, SelectAll, SelectById, ....). You could just as easily wrap that functionality and provide operations that return domain-level objects instead of just the raw table structures. Fowler refers to using just the table structures as the "table module" pattern, whereas the added OO layer would facilitate more of a "domain model." A few pcode examples:

"table module"
Recordset customer = CustomerData.Select(id)
string firstName = customer["firstName"]
Recordset orders = customer.GetOrders()
vs.

"domain model"
Customer c = CustomerData.Select(id)
string firstName = c.FirstName
Order[] orders = c.Orders

The table model design pattern pervades everything Microsoft, and it has for quite some time. It's more common to see a data access layer returning resultsets in the form of a recordset object instead of a collection of domain-level objects.