|
|
Posted by Bent Stigsen on 05/15/06 04:16
Kenneth Downs wrote:
> Bent Stigsen wrote:
>
>>
>> The answer is D, implementing two tables.
>> One table with the characteristics, and one table containing two foreign
>> keys making the association between characteristics and the "items" (what
>> that might be).
>
> Anybody working with databases must have a reasonable method for altering
> table structures as a regular event and a reasonable way to synchronize
> structures and the code that works with them. Not having this will cost,
> and all solutions that seek to re-invent physical implementation produce
> burdens worse than the disease.
>
> The solution you present may be correct in his case, but it verges on the
> dreaded 'abstraction' of the E-A-V system, and if that is so it would be a
> cure worse than the disease. Whether it is a valid cross-reference or an
> instance of E-A-V would require knowing more about the system.
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.
/Bent
Navigation:
[Reply to this message]
|