Susan Harkins
ssharkins at gmail.com
Mon Dec 29 10:24:32 CST 2014
I remember Ken Getz discussing normalization in the early days and I don't want to quote, but he pretty much said if normalization gets in the way -- becomes a hindrance -- it's Okay to break the rules. :) But seriously -- why does it matter how many lookup tables you have? They populate one field and that's easy to maintain, even if you have dozens of them. Susan H. On Sat, Dec 27, 2014 at 1:13 PM, Arthur Fuller <fuller.artful at gmail.com> wrote: > I have in development an app that is intended for use by agencies that use > a lot of volunteers. My initial design was fully normalized (by which I > mean I went to 5NF not just petty 3NF), but this posed significant problems > on the design of the FE, which is web-based. This means that attached to > the Volunteers table are several child tables, each of which connects to a > lookup table, and each of which child could have several rows. For example, > consider Languages-Spoken, easy enough in itself, point to a lookup table > listing languages, present a combo-box and that's that. But now we add > Skills (Driver, Cook, Visits, etc.), and now just with these two lists, > it's already complex: I need a Russian-speaking volunteer who can also > serve as a Driver or Cook, say. > > That leads to complex queries that eventually involve nested Having > predicates, and that is tough to implement in a UI that recognizes that > most of its users are, not to cast aspersions, but let's face it, a lot of > users in this category are going to have problems with the intricacies of > ANDs and ORs. > So I was thinking that there's another design strategy in which all the > lookup tables are folded into a single table, with an identifier that > describes the domain (i.e. languages spoken, skills offered, fields of > interest, etc.), the point being that a successive number of predicates > could be assembled from a single table, thus avoiding the complexities of > multi-table queries. > > I know that this design violates virtually everything Dr. Codd has written, > but he was after all a mere demi-god, and as problems have progressed and > products such as NoSQL have emerged, I've begun to doubt propositions I > formerly held absolute. Disk space is cheap, speed is abundant, and (well > not in my particular case) databases are expanding to billions of rows. > > Any thoughts, my friends? > > -- > Arthur > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > >