[
Lists Home |
Date Index |
Thread Index
]
On 11/30/05, Michael Kay <mike@saxonica.com> wrote:
> > > Celko often writes about this approach to prove that it can
> > be done, but it
> > > just goes to convince me that it shouldn't be done.
> > >
> >
> > Ok, I'll bite: care to explain? Is it just the simple forms of
> > adjacency list you don't like or all nested set approaches?
>
> Relational databases work well when rows in tables correspond to objects in
> the real world. If you need to design your own data structures to represent
> graphs, lists, trees and the like, then it's interesting to know that it's
> feasible to map such structures onto bags/sets of tuples, but this doesn't
> make it my preferred implementation technique. I don't see what I gain by
> having to model all my data using this very limited set of structures. Celko
> is showing how you can do multiplication using a system that only supports
> addition, and thereby convinces me that I'm better off using a system that
> can do multiplication.
Wow. Now you've got me somewhat confused. Does the same line of
thought extend to using joining tables to reduce many to many
relationships to 3rd normal form? Celko after all is just adding
tables and columns to normalize out relationships, something you do
for any properly designed RDB schema of any complexity. Surely you're
not saying that you are opposed to using RDB's for any real world
problems requiring extensive normalization? Or maybe you're saying
that if you've got to do extensive normalization you prefer other
forms of databases?
Personally, having had to slice and dice normalization problems along
many different dimensions one of the things I like about RDB's is that
you can reduce any problem to the same set of primitives and know
exactly what the rules are for manipulating those primitives in
relationship to each other.
It's not that the system doesn't support multiplication, it's that the
system allows me to specify how the multiplication should be done if
need be. More precisely; if need be, it allows me to find an
isomorphisim to map any new group to a known group. Given that any
closed boolean algebra forms a group sooner or later you're going to
end up doing this if you do any large amount of data manipulation.
Knowing that you are doing this up front, and knowing what the rules
are, helps to avoid a lot of bad designs and programming errors.
Now, I'd agree that it might be nice to have one single self tuning
universal database model that didn't require you to think about how to
perform normalization or other optimizations, but given that
generalized universal graph traversal is known to be a NP complete
problem I'm not holding my breath...
I know you don't restrict yourself to only Java language primitives
and will create new composite data structures, and code multiple
classes and methods quite freely in Java (I've studied some of your
code :-) so why is SQL so different?
--
Peter Hunsberger
|
