On 01/29/2010 02:57 PM, Chris W wrote:
> Hardcore stupid if you ask me. I suppose it is "possible" to have a
> valid reason (can't imagine what it might be) for using more than 61
How about complex data requirements? Depending on the resolution of
your data set, I could see a "simple" person-type object that contained
name, address, SSN, mother, and birth_info starting to approach the limit.
Cities change, address changes, names change, and even mothers can
change. The simple-looking street part of an address can have (at least)
number, direction, name, suffix, any of which can change.
> joins. But I would be willing to bet that 99.99% of the time if you get
> even close to that many joins you have a very poorly designed database.
> I would also bet that 80% of the people who are actually writing queries
> with that many joins don't have a solid grasp of the fundamental
> principles of relational database design.
I suspect otherwise. In my experience, most of the time when someone
does not understand relational databases, there is a tendency towards
fewer tables; and, in the few cases where I have seen too many tables,
the joins were more likely to be done in the application code than in
the database... Fun Times there....
The real art is trying to balance the need of simplicity and ease of
understanding with the need for flexibility, and that has nothing to do
with relational theory. Complex datasets are, by their nature, complex,
and can only be simplified so much. You try to hide the complexity, you
shift it, you move-it, you send it to its room, you pretend it is not
there. And yet it still pops up at the most inopportune times and has to
be dealt with.