On 02/02/11 18:57, Wols Lists wrote: > The problem is, where do you put the layers. That's my beef with > relational, the layer is in COMPLETELY the wrong place. This means a > large chunk of information, which *belongs* in the database layer, *has* > to be put into the business layer. > > Even the wording of relational theory makes this clear - data is stored > as attributes. Attributes of what? Without an object to belong to, an > attribute is meaningless, but you can't store an object in an RDBMS.
To expand on this - let's say you want to store a list. Where do you store the sequence information? Bearing in mind that, as far as the real world is concerned, this is metadata ... so it DOESN'T belong mixed up in the same table as the data :-) And how do you tell a relational database that data is mutually co-dependent? That if one piece of data ceases to exist in the real world, all these other pieces will also cease to exist at the same time? Unless they're all single-valued, and fit in the same row, you can't! Unfortunately, relational theory is based on the premise that data comes already conveniently chopped up into rows and columns. Any information (data?) that links those rows and columns can't fit in the database, even if it belongs there. And it's the PB business analyst who is left trying to square the circle ... Cheers, Wol _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
