如何让你的代码存储不确定数量的列？
我想我的问题可能不清楚，但我会尝试通过例子来解释。
假设我们有大约 100 种不同的汽车型号，显然所有汽车都会共享通用零件或规格，但并非所有零件都在所有这 100 个汽车品牌之间共享，
在这种情况下存储这些规格的最佳实践是什么？
我的想法是在每一列中存储最常见的规范，并且可以将未确定的（其余）规范保存或序列化为对象或数组。
学说通过这些数据类型（数组对象）简化了此操作 您认为这是个好主意吗？或者您可以与我分享您的经验吗？
这是我在两个简单表格中的想法，
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 |
|-------|--------|----------------------|
我认为我的想法很糟糕，因为它破坏了搜索能力
I think my question might be unclear , but i would try to explain it by example .
say that we had about 100 different car model , clearly all of the car would share common parts or specification but not all parts are shared between all of these 100 car brands
what is the best practice of storing these specification in this case ??
my idea was to store the most common specification in each column and the undetermined ( the rest )specification could be saved or serialized array as object or array .
doctrine simplify this operation by these datatypes (array-object)
do you think this is good idea or could you please share with me your experience
here is my idea in 2 simple tables
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 |
|-------|--------|----------------------|
i think my idea bad because it breaks the search ability
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您必须坚持使用 MySQL，那么正如 Paul 和 Netcoder 所说，EAV 将是您的最佳选择。
除非仔细管理，否则 EAV 确实存在可扩展性问题，但是您的用例听起来最好通过 Couch 或 Mongo 等 NoSQL（非关系数据库）解决方案来解决。
诸如此类的面向文档的数据库是围绕这样的逻辑构建的：实体没有固定数量的字段，例如产品及其所有图像的数据将驻留在一个“文档”中。
If you have to stick to a MySQL then as Paul and Netcoder says, EAV would be the solution to opt for.
Unless managed carefully EAV does have scalability issues however and your use case sounds like it would be better solved by a NoSQL (non-relational database) solution such as Couch or Mongo.
Document-orientated databases such as these are built surrounding the logic that an entity has no fixed number of fields, for example a product and the data about all of its images would reside within one 'document'.
可能希望您需要一个 Entity-Attribute-Value (EAV) 架构。这些可以让您拥有包含不同信息量的记录，但查询起来可能很棘手。
Possibly want you need an Entity-Attribute-Value (EAV) schema. These can let you have records with varying amounts of information, but can be tricky to query.
常用的解决方案是拥有一个接受键值对（通常称为 EAV）的表：
A commonly used solution is to have a table that accepts key-value pairs (commonly called EAV):
强制列的数量和类型肯定不可能吗？即使您允许一些模糊的内容？如果您可以确定列，则不需要复杂的解决方案。可能是最不痛苦的选择。只是一个想法。
Is forcing the number and types of columns certainly impossible? Even if you allow for a few vague ones? If you could determine the columns, no complex solution would be needed. Might be the least painful option. Just a thought.
对每个唯一的属性组合使用一个表，但也将公共属性放入具有这些公共属性的所有车型之间共享的表中。这个想法是确保描述汽车的每个可能的元组只能出现在模式中的一个位置。这个原则有一个名字：正交设计原则。
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.