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. -r -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
