Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If I understand correctly, an unfinalised order is not yet assigned a baker / pricing (meaning when an order is placed, no baker has yet been selected to bake the product).</p> <p>In which case, the order is probably placed against the Products Table and then "Finalized" against the BakersProducts table.</p> <p>A solution could be to give ProductsOrders 2 separate "ProductID's", one being for the original ordered ProductId (i.e. Non Nullable) - say ProductId, and the second being part of the Foreign key to the assigned BakersProducts (say ProductId2). Meaning that in ProductsOrders, the composite foreign keys BakerId, ProductId2 and PricingDate are all nullable, as they will only be set once the order is Finalized.</p> <p>In order to remove this redundancy, what you might also consider is using surrogate keys instead of the composite keys. This way BakersProducts would have a surrogate PK (e.g. BakersProductId) which would then be referenced as a nullable FK in ProductsOrders. This would also avoid the confusion with the Direct FK in ProductsOrders to Product.ProductId (which from above, was the original Product line as part of the Order).</p> <p>HTH?</p> <p>Edit:</p> <pre><code>CREATE TABLE dbo.BakersProducts ( BakerProductId int identity(1,1) not null, -- New Surrogate PK here BakerId int not null, ProductId int not null, PricingDate datetime not null, Price money not null, StockLevel bigint not null, CONSTRAINT PK_BakerProducts PRIMARY KEY(BakerProductId), CONSTRAINT FK_BakerProductsProducts FOREIGN KEY(ProductId) REFERENCES dbo.Products(ProductId), CONSTRAINT FK_BakerProductsBaker FOREIGN KEY(BakerId) REFERENCES dbo.Bakers(BakerId), CONSTRAINT U_BakerProductsPrice UNIQUE(BakerId, ProductId, PricingDate) -- Unique Constraint mimicks the original PK for uniqueness ... could also use a unique index ) CREATE TABLE dbo.ProductOrders ( OrderId INT NOT NULL, ProductId INT NOT NULL, -- This is the original Ordered Product set when order is created BakerProductId INT NULL, -- This is nullable and gets set when Order is finalised with a baker OrderQuantity BIGINT NOT NULL, CONSTRAINT FK_ProductsOrdersBakersProducts FOREIGN KEY(BakersProductId) REFERENCES dbo.BakersProducts(BakerProductId) .. Other Keys here ) </code></pre>
    singulars
    1. This table or related slice is empty.
    1. PODatabase design - composite key relationship issue
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USStuartLC
    1. USStuartLC
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PODatabase design - composite key relationship issue
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO@nonnb: yes, you are correct with your initial understanding. Your suggestion of `Products.productID`->`ProductOrders.productID` sounds better, as I was trying to kill 2 birds stone so to speak by trying to reference only one table which already had `productID`. nonnb, if I create a surrogate key on `BakersProducts` and reference that instead, is that not still considered redundant design? Also, is there a difference between a Primary Key and a Surrogate Key? thank you!
      singulars
      1. PO
      1. USmagz
    2. COsorry, with my question about it still being considered redundant design, I'm considering what you are saying about the redundancy, but seeing `BakersProductId' as a key in a table that already contains `productID'. So from my perspective, it appears as though `ProductOrders` still has 2 `productID`s in a way. Or am I understanding redundancy wrong, and you mean that each row should not contain duplicate values? If I go with your suggestion, I will have to manage the relationship carefully on my application-end.
      singulars
      1. PO
      1. USmagz
    3. COso ideally, in `BakersProducts`, `productID` & `bakerID` should be non-nullable foreign-keys against their respective tables, but should **not** be part of a composite key, and also have a surrogate key in `BakersProducts`
      singulars
      1. PO
      1. USmagz
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload