|
Posted by Kenneth Downs on 05/15/06 14:03
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.
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.
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.
--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
[Back to original message]
|