network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 9 months |
| seen | May 8 at 15:14 | |
| stats | profile views | 10 |
|
May 3 |
comment |
Many:Many with Shared Relation Thanks for clarifying Joel. At some point it's semantic, but I'm actually leaving the candidate key intact, and adding an additional unique index to constrain the relation against. Technically applying this business rule probably constitutes approaching rather than deviating from a normal form. At any rate, it seems to be what I need, which is the important bit. :) |
|
May 3 |
comment |
Many:Many with Shared Relation I don't want to debate normalization, just to perhaps further my understanding of it. When you say "denormalize... , but keeping it in the PK" do you mean that dropping the composer_id from the PK would constitute denormalization? I thought that in normal form a PK only holds prime attributes? |
|
May 2 |
comment |
Many:Many with Shared Relation Oh, p.s. I do have the (seemingly circular) join back to Composer in my schema. It avoids the need to group/select unique relations from the junction table to get at a core relationship. |
|
May 2 |
accepted | Many:Many with Shared Relation |
|
May 2 |
comment |
Many:Many with Shared Relation In your schema, I don't believe the composer is actually part of the primary key on the tables where it's been added, but rather merely part of the referential constraint. For example, additional tables related to Anthology and Composition do not actually have a composer_id column (for relation to Anthology or Composition, at least). Additionally, there is no need to specify the composer_id twice in the AnthologyItem table (avoiding the check constraint). That is what I was trying to convey in the table definition in my question. Does that have issues that you see? |
|
May 2 |
comment |
Many:Many with Shared Relation If I follow you correctly, I keep thinking the same thing and then realizing it doesn't work. If I don't include the composer relationship where it is, I can navigate from Composer1 -> Composition1 -> Junction1 -> Anthology1 -> Junction2 -> Composition2 -> Composer2. Now I have inconsistent object ownership, undefined at the far end. (My Anthology isn't about a single Composer anymore, in this metaphor.) |
|
May 2 |
comment |
Many:Many with Shared Relation @ypercube: Thank you, that makes sense. Is it standard practice then to restrict direct inserts? The CreateAnthology() procedure will require a related Composition, which does leave a slightly distasteful asymmetry, since the first Composition to join an Anthology is not really 'special' per-se. That has me wondering how I will represent the interaction in code; it could perhaps accept an array of Compositions. |
|
May 2 |
revised |
Many:Many with Shared Relation deleted 38 characters in body |
|
May 2 |
asked | Many:Many with Shared Relation |
|
Mar 26 |
comment |
How to represent class table inheritance (current DBMS-specific way please)? I'm about to implement this as a persisted column. I hope that approach is compatible with EF. Also, I still wonder if SQL will recognize that it has an index available when merely passed an ID by EF on the derived class table, for example. I can think of a lot of lame examples where I'm suspicious the performance will break. |
|
Mar 25 |
comment |
How to represent class table inheritance (current DBMS-specific way please)? Yes, Aaron, thanks for asking. Cats have both different and far more properties than dogs in my application. Side note, 'cats' and 'dogs' represent three categories of website members in my current scenario. |
|
Mar 24 |
asked | How to represent class table inheritance (current DBMS-specific way please)? |
|
Aug 25 |
revised |
Schema for 1 <-> 0..1(+), many related but only one primary numbered the options |
|
Aug 25 |
comment |
Schema for 1 <-> 0..1(+), many related but only one primary it's probably also worth noting that, as ypercube mentioned in the related question he linked above, this does rely on features in my specific DBMS |
|
Aug 25 |
comment |
Schema for 1 <-> 0..1(+), many related but only one primary ypercube: you are correct, it is the same question at the root. great reference. For education, would you please explain why you say a circular reference (first option on both my and your post) is bad here. The bilateral relation on the unique personId (although via two relations, still concurrent) here ensures there is no recursion. Unless, of course, you could consider a 1-1 relationship recursive. Are you saying it's just a matter of how poorly supported this is across DBMS or ORMs? |
|
Aug 25 |
comment |
Schema for 1 <-> 0..1(+), many related but only one primary awesome, thanks. just the sort of solution I was looking for. |
|
Aug 25 |
accepted | Schema for 1 <-> 0..1(+), many related but only one primary |
|
Aug 25 |
revised |
Schema for 1 <-> 0..1(+), many related but only one primary added 11 characters in body |
|
Aug 25 |
revised |
Schema for 1 <-> 0..1(+), many related but only one primary added 112 characters in body |
|
Aug 25 |
revised |
Schema for 1 <-> 0..1(+), many related but only one primary added 332 characters in body |
