Re: How to model searchable properties of an entity
Date: 19 Aug 2004 04:38:39 -0700
"Laconic2" <laconic2_at_comcast.net> wrote in message news:<ybGdnVI2P9IS_77cRVn-jA_at_comcast.com>...
> "Tony" <andrewst_at_onetel.net.uk> wrote in message
> > I couldn't agree more. And if the issue IS coming from an OO
> > perspective, than how is having hundreds of classes and subclasses
> > good while hundreds of tables is bad?
> Good post Tony. I can't tell you the number of times you've said what I was
> about to say, only better. I cuts down on the number of responses I post.
Thanks - but in fact I often think the same (well, vice versa!)
> In this case, I think we got an answer from an Object perspective: it has
> to do with the way inheritance works.
Yes, we have. Mind you, the OP is talking about allowing users to define new product types with new attributes over time, and I don't imagine an OO designer wants the users defining new classes "on the fly" any more than we want the users defining new tables.
> It gets worse. Once a beaureaucracy gets large enough, you get people who
> operate on the data without a clue as to what it really means. The
> following dialogue is not invented:
> "We shouldn't have sent this guy a letter. He's a B73."
> "What the hell is a B73?"
> "I have no idea. But we never send them any letters."
I love that!
> The real problem, for me, is that what I learned, years ago, is to first
> model the data, and then build the system.
> What most people like Dilip want to do, rightly or wrongly, is build the
> system, and then model the data.
Me too, and I'm lucky enough to be working in an environment where that is still practiced reasonably well. But I have a friend who works as a DBA for a large oil company that uses Smalltalk and Oracle, and she gets her requirements from the Smalltalk team: "we've designed this new set of screens for <whatever>, and we need you to create some tables to save the data into". Most tables (created before she joined) have no constraints of any kind, and the majority of her time seems to be spent writing scripts to find and fix corrupt data. But I digress...
Yup. And I must admit, maybe I have just been lucky (again) never to have come up against such a requirement. I do remember once in my early days in relational databases seeing a database design for a local government inventory system. It had separate tables called things like street_lamp, post_box, telegraph_pole, etc. etc. I remember saying to a colleague "that's crazy, defining a separate table for each item type". Now I seem to have been advocating that approach here! Actually, I think my inclination now would probably still be more pragmatic: for the most part, all those inventory items can be considered similar: their most important attributes would be stuff like location (grid ref), cost, date installed, date last inspected, make, model, etc. common to all. That data should probably reside in a single table. With a "notes" attribute, there really might not be a need to hold further item-specific information for 80% of the item types. Of course, I am probably over-simplifying drastically here. Received on Thu Aug 19 2004 - 13:38:39 CEST