Re: 1GB Tables as Classes, or Tables as Types, and all that refuted

Costin Cozianu <c_cozianu_at_hotmail.com> wrote:

> So the pragmatic knowledge that everybody and their grandma programming
> systems these days do have a Users table and do have a User class, and
> nothing bad happens because of this designed is directly confirmed by
> simple logical reasoning.

What if you think about your User class as a synonym for the tuple type in the Third Manifesto? This way you can pass around one variable (a tuple) and you can store one value (a tuple) in the database. Maybe this is why nothing bad happens in this simple case.

However, when you add a getOrders() method to your User class things do get complicated. (I guess the Order class would need a backward reference to the 'containing' User object too.) This means that you will have an 'orders' member variable in your User class that stores a set of references to Order objects. Now, if you want to store your User object to the database you will face the good ol' O/R mapping cookie monster that Date and Darwen wanted to get rid of so badly :)

In my opinion, the 'impedance mismatch' between relational DBMSs and OO languages comes into picture only when we want to map object graphs to relational tables. Object graphs represent relationships between entities through one-way references while tuples use common attribute values for the same purpose, thus making the relationships two-way and explicit. The larger and more intricate our object graphs are the more we feel the effects of the mismatch.

This might be the explanation why your example of a simple User class that maps to a User relation works perfectly in practice. (There is no object graph so the mismatch is negligible.) Although you still have to do some (more or less) manual mapping to construct User objects from result set rows and to store User objects to the relational DBMS.

Regards,

Josh Hewitt
Ph.D. Student
Florida Institute of Technology Received on Mon Nov 15 2004 - 15:36:52 CET