1

私の質問は不明確かもしれませんが、例を挙げて説明しようと思います。

約 100 種類の車のモデルがあるとします。明らかにすべての車が共通の部品または仕様を共有していますが、すべての部品がこれら 100 の車のブランドすべてで共有されているわけではありません。

この場合、これらの仕様を保存するベストプラクティスは何ですか??

私の考えは、最も一般的な仕様を各列に保存し、未決定の（残りの）仕様をオブジェクトまたは配列として保存またはシリアル化することでした。

教義はこれらのデータ型（配列オブジェクト）によってこの操作を簡素化します、これは良い考えだと思いますか、それともあなたの経験を私と共有してもらえますか

これが2つの単純な表での私の考えです

Table 1
|-------|--------|-------|-------|-------|
| Id    | brand  |engine |desiel | blah..|
|-------|--------|-------|-------|-------|
| 1     | old car|   1.6 | yes   | blah..|
|-------|--------|-------|-------|-------|


Table 2 
|-------|--------|----------------------|
| Id    | car_id |  un common info      |
|-------|--------|----------------------|
| 1     |    1   |array of informations |
|-------|--------|----------------------|

検索機能が壊れているので、私の考えは悪いと思います

4

5 に答える 5

2

MySQL に固執する必要がある場合は、Paul と Netcoder が言うように、EAV が選択するソリューションになります。

ただし、慎重に管理しない限り、EAV にはスケーラビリティの問題があり、ユースケースは、Couch や Mongo などの NoSQL (非リレーショナル データベース) ソリューションによって解決されるように思えます。

これらのようなドキュメント指向のデータベースは、エンティティには固定数のフィールドがないというロジックに基づいて構築されています。たとえば、製品とそのすべての画像に関するデータは 1 つの「ドキュメント」内に存在します。

于 2010-10-31T21:29:26.753 に答える
1

Entity-Attribute-Value (EAV) スキーマが必要な場合があります。これらにより、さまざまな量の情報を含むレコードを作成できますが、クエリが難しい場合があります。

于 2010-10-31T21:22:26.517 に答える
0

列の数と種類を強制することは確かに不可能ですか？漠然としたものをいくつか許可しても？列を決定できれば、複雑なソリューションは必要ありません。最も痛みの少ないオプションかもしれません。ちょっとした考え。

于 2010-10-31T22:10:04.457 に答える
0

一般的に使用される解決策は、キーと値のペア (一般に EAV と呼ばれる) を受け入れるテーブルを用意することです。

|-------|--------|-------|
| carId | name   | value |
|-------|--------|-------|
| 1     | engine | 4cyl  |
|-------|--------|-------|
于 2010-10-31T21:26:07.833 に答える
0

Use one table for each unique combination of attributes but also put the common attributes into tables that are shared between the all the car types having those attributes in common. The idea is to ensure that every possible tuple describing a car can only appear in one place in the schema. There is a name for this principle: The Principle of Orthogonal Design.

于 2010-10-31T23:17:22.960 に答える