how to make sure that product specs is for the category entity?

问题

I have the following table:

1. products (id, name, price, category_id)
2. categories (id, name, description)

now because each category's products may have different attributes than other category's product I want to use EVA but here is my problem:

I want to make sure that any product attribute's value is being added belong to the category of that product and not allowing the addition of arrtibutes that does not belong to it.

would you please tell me how to do this?

回答1:

I want to make sure that any product attribute's value is being added belong to the category of that product and not allowing the addition of attributes that does not belong to it. would you please tell me how to do this?

Sure. It is a fairly common requirement, and quite straight-forward, at both the modelling and SQL levels. However, due to the promotion of primitive 1960's Record Filing Systems as "relational" by the "theoreticians", and the suppression of Relational methods by the same crowd, it is unknown.

Whereas the RFS is physical (Record IDs linking records, not rows), the Relational Model is Logical, using logical keys, which link rows not records. And Relational Keys provide meaning. So first the concept needs to be understood, and then the implementation is easy.

1960's Record Filing System

Your files:

• All my data models are rendered in IDEF1X, the Standard for modelling Relational databases since 1993
• My IDEF1X Introduction is essential reading for beginners.
• The IDEF1X Anatomy is a refresher for those who have lapsed

Relational Database • Concept • Subtype

This is the concept that you need to understand.

• As per your requirement, each Category requires different attributes in Product, and each is mutually exclusive from the others.
• It is an ordinary Subtype cluster, Exclusive in this case.
• Some might call it "metadata", as in, it is beyond the data, and it has a defining effect on Product.
• More info on Subtypes.

1960's Record Filing System • Implementation

Now for the implementation, using the given files.

• Maintain Category as a logical Key (CHAR Key, replete with meaning, not a Record Id).
• We deploy the Exclusive Subtype cluster in Product, with the Category as the Discriminator.
• However, due to the use of Record IDs, which are physical, and which are not logical keys, but implemented as PRIMARY KEY, which will confuse the hell out of anyone, the rows in the Product file can be duplicated
  • each logical Product row needs to be unique
  • which means, according to Dr E F Codd's Relational Model, using a Key that is "made up from the data"
  • Product Name is the only possibility for a PK

Relational Database • Implementation

If we elevate the system to Relational, and prevent the duplication of rows (as opposed to records), which is prohibited:

• Human users will not use numbers for Identifiers. The ProductId is not seen or used by them.
• The Name is the only unique row (Product) Identifier, however it is too long to be nominated Primary Key. Nevertheless it must be Unique.
• Users will use a short code as a Product Identifier.
• Which makes the ProductId quite useless and redundant (one additional column and one additional index).
• As usual, this is also the fewest columns and indices.

SQL

All the above is ordinary SQL, the data sublanguage for the Relational Model. It can be implemented with full protection and integrity using ordinary SQL CONSTRAINTs, etc. The Subtype document provides full implementation details.

• However, note that MySQL and PusGreSQL are not SQL (they do not comply with the SQL requirement, and are absent many of the ordinary functions of SQL), and thus their use of the term SQL is fraudulent.
• Further, they have no Server Architecture, which means performance is horrendous, and concurrency is pathetic.

来源：https://stackoverflow.com/questions/57573089/how-to-make-sure-that-product-specs-is-for-the-category-entity