Jujitsu Lizard wrote: > On Fri, Nov 14, 2008 at 1:39 PM, Martijn Tonies <[EMAIL PROTECTED]>wrote: > > >>> >The notion of a "variant record" exists in many programming languages. >>> >Typically you have a selector to indicate which variant it is. There is >>> >nothing at all wrong with using the same sort of construct in a >>> >> database >> >>> >table. >>> >http://en.wikipedia.org/wiki/Variant_record >>> >>> In O-O databases. I think the concept is not defined in relational >>> database theory. Are you aware of the rel db rule regarding domains? >>> >>> >The only constraint you _really_ need to meet in a database is that >>> you let >>> >the database product do the things it needs to do so that the queries >>> >> you >> >>> >make are O(log N) when possible. The rest is pure fluff. Beyond that, >>> >there is no "should". >>> >>> Relational theory says otherwise. >>> >> I'm with Peter on this one, in relational theory and data modelling, >> there's >> a lot of very well documented "should" :-) >> >> > You guys have been reading too many books. Books are bad. > > The key question is when something is so much different from another thing > that it is a qualitative difference rather than a quantitative difference. > > I go to the vet's office from time to time, and they keep their records in a > computer. Is a rabbit different enough from a dog that you need different > types of records in the database? Probably not. They are both pets. There > may be some information about dogs that doesn't apply to rabbits or > vice-versa, but people make do. You leave the "rabies vaccination" fields > blank for a rabbit, presumably. > > The "variant record" notion applies--whether it is called that or not--in > nearly every practical database in the world. > > A customer that is a person vs. a customer that is a company ... not that > different. > It is once you consider creating automated invoices for that customer (e.g. for an online webhosting service or monthly support service fees). You can't deliver this unless a clear distinction is made between a private customer and a corporate customer (and possibly other types of institutions, with other tax rates).
> I do understand the points that are being made ... but once you get beyond > the database product being able to make queries efficiently ... it is all > fluff. > > I don't debate that for the problem as stated there are "better" or "more > correct" designs involving more tables. I also don't debate that these > designs are probably more resilient to change and have other advantages. I > agree. > > But you can take your licks in a more complex database design or more > complex code to modify and insert rows and deal with query results. Being > lazy, I'd take my licks in the second way. > > I have the feeling you're a programmer who has learned how to keep his feet on the ground while implementing. Respect ! Best regards, Stijn -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
