|
|
Posted by Bent Stigsen on 05/16/06 23:28
Kenneth Downs wrote:
> Bent Stigsen wrote:
>
>>
>> Hmmm, I don't really see it as such. Arguably a step in that direction,
>> but still good old relational tables to me, and very much a reasonable
>> method to anticipate changes in schema/data.
>>
>>
>>> But I would repeat that any 'abstraction' made in an attempt to avoid
>>> table
>>> structure changes is going to fail. It fails because you give up what
>>> the server can do for you and end up spending your time reinventing an
>>> RDMBS server.
>>
>> Perhaps I don't quite understand you here, but I don't think I am
>> reinventing anything. Using an intermediate table to represent a
>> many-to-many relationship is hopefully quite a common practice, and by no
>> means an abuse of any relational database, but rather something they are
>> extremely good at.
>>
>>
>
> As I said, in this case it may be valid.
Perhaps we think the same, but just to be clear. No doubt all suggested
solutions will get the job done. In that respect, I consider them of equal
validity. But I do consider the solution with the intermediate link table a
better option, especially since it saves a hell of a lot of work, should
the requirements change.
> It would be a move toward using E-A-V if and only if it were done
> specifically to avoid structure changes. That would flag a mindset that
> would tend towards making the data more and more difficult to work with,
> trading the effort of regular development and use for the effort of
> modifying the table structures.
My only objection is "more and more difficult". It is not like abstraction
is something that demand more and more by itself, but yes, not unlikely to
be a trade, but which I wouldn't automatically think of as difficult, not
in this case anyway.
Sure, it can be seen as increased complexity and abstraction, allthough I
don't consider it a big deal, but rather just part of the natural design
process. I'll get back to that.
> I can only argue here from experience. A flag is a property of the entity
> being recorded in the table. That means by default it is a column in a
> table, along with other flags. This is the simplest possible arrangement
> and anything else carries a higher ongoing cost. The default position is
> to have it a column in the table. In most cases, if the customer wants
> another flag, that's another column. If a developer is trying to avoid
> structure changes because of cost, then that developer needs to seriously
> look at their development tools (or coding habits), anything which drives
> you away from the natural use of tables is not your friend.
I would contend that it is not impossible, actually well within classical
relational design, to make a database less likely to require altering in
the future, without resorting to complex constructs with higher developing
costs as result. It is not just a hopeful idea. Since Jerry's word
apparently is not good enough, I'll try argument.
I think the original question is a fine example. OP's initial approach is,
as you also imply, a set of properties of the entity, and you conclude
therefor should be represented in the table of the entity. We could stop
here, not making any closer analysis of the data or playing what-if, and
from this point of view you are quite right. (except claiming that
"anything else carries a higher ongoing cost.")
But the OP does go a little further as he just generally calls them
characteristics. Even without making any assumption about the future, it
wouldn't be strange to elevate a characteristic as an entity by itself,
from thereon ordinary normalization *dictates* a separate entity-table and
an intermediate link table because of the many-to-many relation. That is
not cheating or making unnecessary abstractions, it is just plain database
design.
You can get the same result if you consider the somewhat flaky properties
("with restaurant", "drive-through facility", etc. ). It is not exactly
unthinkable that another characteristic comes along after a couple of
months, which nobody had thought of. I would count on it.
If or when that extra requirement comes along, the solution with one field
to each property would require changes through the whole system, from
schema to interface, whereas the other solution would at worst require
minor adjustment in the userinterface for displaying an extra option.
Clearly not "a higher ongoing cost".
/Bent
Navigation:
[Reply to this message]
|