如何确保产品规格适用于类别实体？ [英] how to make sure that product specs is for the category entity?

问题描述

我有下表：

1. 产品（编号，名称，价格，类别ID）


2. 类别（标识，名称，描述）

现在，因为每个类别的产品可能具有与我要使用的其他类别产品不同的属性，这是自1993年以来用于关系数据库建模的标准

我的。

1960年的记录归档系统•实现

现在使用给定文件进行实施。

• 将类别保持为逻辑键（ CHAR 键，充满含义，而不是一个记录ID ）。


• 我们在Product中部署Exclusive Subtype集群，并将Category作为区分项。


• 但是，由于使用了记录ID ，它们是物理的，不是逻辑键，但实现为 PRIMARY KEY ，这将使任何人感到困惑，可以复制Product文件中的行
  
  
  
  
  • 每个逻辑产品行需要
  
  
  • 是唯一的
  
  
  • 这意味着根据EF Codd博士的关系模型，它使用的是由数据组成的密钥
  
  
  • 产品名称是唯一的PK
  
  

关系数据库•实施

如果我们将系统提升为关系，并防止重复行（相对于记录），则禁止这样做：

• 人类用户不会将数字用作标识符。他们没有看到或使用 ProductId 。


• 名称是唯一的唯一行（产品）标识符，但是太长了，无法被提名为主键。尽管如此，它必须是唯一的。


• 用户将使用短代码作为产品标识符。


• 这使得 ProductId 毫无用处和多余（一个其他列和一个其他索引）。


• 通常，这是也是最少的列和索引。

SQL

以上全部是普通SQL，关系模型的数据子语言。可以使用普通SQL CONSTRAINTs 等在完全保护和完整性的情况下实施。子类型文档提供了完整的实现细节。

• 但是，请注意，MySQL和PusGreSQL是非SQL （它们不符合SQL要求，并且缺少SQL的许多普通功能），因此它们使用 SQL 是欺诈性的。


• 此外，它们没有服务器体系结构，这意味着性能令人恐惧，并发性很差。

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?

解决方案

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.

这篇关于如何确保产品规格适用于类别实体？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！