字符串或枚举
哪种情况更好？
假设本质上是一个键/值对表，有超过 300 个可能的值，其中相关列是键：
枚举或 > Char/Varchar
我只是想知道是否有人处理过具有这么多可能值的 Enum 列以及可能存在的陷阱。
编辑：
键是预定义的。
项目表：
id、名称、...
属性表：
id、item_id、key、value
Which situation is better?
Assuming upwards of 300 possible values on what would essentially be a table of key/value pairs where the column in question is the key:
Enum or Char/Varchar
I'm just wondering if anyone has dealt with an Enum column with that many possible values and what the pitfalls might be.
EDIT:
Keys ARE predefined.
Item Table:
id, name, ...
Attributes Table:
id, item_id, key, value
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您正在谈论 300 个可能的值，我将使用单独的 id/值查找表。
特别是考虑到您的问题中的这一陈述：
那么为什么不实际上将其设为一个键/值对表呢？
If you are talking 300 possible values, I would be using a separate id/value lookup table.
Especially given this statement from your question:
So why not just actually make it a table of key/value pairs?
也许我误解了这个问题，但通常如果我有一个包含 300 多种类型的列，它告诉我需要对其进行规范化并使用外键将其放入另一个表中。
Perhaps I misunderstood the question, but normally if I have a column with 300+ types that tells me I need to normalize it and put it in another table, using a foreign key.
如果只有正交值，我建议选择枚举 - 例如命名颜色就是一个可以证明创建大型枚举的示例。 问题是，如果您的 300 多个值是正交的 - 您能否将其分解为更小的正交集？ 例如，立方体的八个角可以通过具有八个值的枚举来描述。
但您也可以将其分解为仅六个值，并使用位标志枚举将它们组合起来。
如果值空间不固定 - 也就是说很可能会添加新值 - 字符串或新的专用类型是可行的方法。
I suggest to choose an enum if there are only orthogonal values - for example named colors are an example that could justify creating a large enum. The question is if your 300+ values are orthogonal - can you decompose it into smaller orthogonal sets? For example the eight corners of a cube could be described by an enum with eight values.
But you could also decompose it into only six values and combine them using a bitflag enum.
If the value space is not fixed - that is it is quite possible that new values will be added - a string or a new deticated type is the way to go.