CODEWITHSUNDEEP
sqldatabaseentitiesrelational
Silver
Silver

Reputation: 29

Determining if an entity is weak or not

I'm creating a relational database of a store and its stock of products.

In the brief, it says "products can be returned under agreed terms e.g. expiry date or manufacturers error", based on this I created a weak entity "Terms" with product_ID as the foreign key and errors & expiry as two attributes.

My logic was that the terms only exist if the product exists, therefore it is a weak attribute as every product has terms, but you wouldn't have terms not associated with a product.

Looking at it though, the "Terms" table would basically be Product ID (1) ---> Errors (No) ---> Expiry (01/01/23), and now I'm starting to think those two attributes should be attributes of the product table and not a separate entity, mainly because "Terms" doesn't have a partial/discriminator key that could be used as a composite primary.

Does anyone have any thoughts about which way is correct?

Upvotes: -1

Views: 103

Answers (1)

Zach J.
Zach J.

Reputation: 366

I think this answer really comes down to the trade-offs in terms of performance.

To make sure I understand your question correctly - you basically have two tables:

  1. The main product table
  2. A "lookup" table that just has Product_ID (FK), Errors, and Expiry as the columns

If this is the case, you have two options:

  1. Just add Errors and Expiry as columns to the primary product table
  2. Keep the two tables separated as you have them, and just JOIN that data when needed.

Option 1 has the benefit of keeping all the data in one table, assuming that "Expiry" and "Errors" are unique to the product_ID; if they're not, you may end up duplicating data, and it's better to keep these fields in your separate table to have a 1:Many relationship. The other drawback would be that if your main Product table is beefy, you've slowed down the query even further by adding these columns.

Option 2 can circumvent the two shortcomings of Option 1 - by keeping this data separate, your Product table is much lighter, and if you have a 1:many relationship, you don't duplicate data (saving you more memory overall!). The drawback with Option 2 is that your EDR gets a bit more complicated - you have one more table to keep track of.

Based on these, I recommend keeping your separate "lookup" table - the benefits of separating this data out will help you in the long run - but ultimately you'll need to weight the pros and cons since I don't know the extent of your project.

Upvotes: 1

Related Questions