Question

在mySQL中存储选项的最佳方法是什么？作为与每个字符串关联的描述性字符串或整数。

假设我的UI中有这个问题：

你最喜欢的冰淇淋口味是什么？

香草
巧克力
草莓

最好将数据库中的数据存储为INT（1）字段中的1,2,3或CHAR字段中的字符串香草，巧克力或草莓？我知道INT字段会更快，但除非有成千上万行，否则可能不会很快。

如果它们存储为字符串，那么我就不需要做任何额外的PHP代码，而如果它们存储为数字，我必须定义1 = vanilla等的值... < / p>

对此有何普遍共识？

Answer 1

关系数据库的常用方法是创建一个名为icecream_flavor或更新的表。然后您可以在以后添加新的口味，并且您的程序可以在它询问时提供所有当前的口味选择。您可以按表ID存储选项（即整数）。

Answer 2

如果paddy answer不是一个选项，那么你应该将值存储为ENUM。

虽然ENUM非常相当于TINYINT（1）。如果您允许用户选择的值已经预先修复，则ENUM只是答案，否则您必须编辑该表。但是如果你使用ENUM MySQL在插入时选择了引擎，并从ENUM中进行选择。这是显而易见的选择，例如（男性/女性）。

否则你问题的答案是TINYINYT（1），这比CHAR和INT（1）都要快。

Answer 3

如果您有一组常量值，并且您不打算将这些值与数据库中的其他数据相关联（与每种类型的冰淇淋相关的信息），您可以使用MySQL的特殊字段类型{{3} }

Answer 4

我建议您将主索引保留为int。这样做的最简单的原因是您目前不知道的内容，并允许您的数据模型发展。

假设你的例子，如果你使用实际的单词，并且在六个月内你决定也放入一个尺寸 - 单勺，双勺等，你突然遇到一个问题，因为你认为你的主键很突然每种口味都有多个条目。另一方面，如果您使用数字格式，您可以轻松拥有任意数量的香草变体，一切都很开心。

在这种情况下，我还建议将实际的主键保留为键，仅此而已。添加另一个具有风味的列，或创建一个查找表来存储每个项目的实际属性。如果你保留一个数字格式，但ID为1，那么你基本上遇到了和以前一样的问题，保留ID作为ID，你的详细信息是分开的。

要保存有关商品的数据，您可以使用以下内容：

Master Table
ID     Name
1      Ice Cream

Properties Table
ID     Type
1      Flavour
2      Size

Property Table
ID     PropID    Detail
1      1         Vanilla
2      1         Strawberry
3      2         Single Scoop
4      2         Double Scoop

MasterToProperty
MasterID     Property    PropID
1            1           1
1            2           4

这基本上为您提供了无限数量的选项，并添加了您想要的任何东西（例如choc芯片的条目）只需添加几行数据而不是表格更改。

Answer 5

如果每个用户都可以通过某个唯一密钥（例如电子邮件地址）识别，那么您可能会发现您不需要数字ID。

当你控制选项时保持味道的味道（所以你没有得到香草，香草香草等）向我建议你存储真正的价值（香草）。

这可以避免连接，并在浏览时使数据库数据有意义。

您可以将索引添加到数据库的flavor列中，这样您就可以非常便宜地“显示所有喜欢Vanilla的用户”。

（如果你可能有无限的存储选项，那么也许你应该调查使用nosql数据库）

Answer 6

像这样设置数据库：

Questions
id, question_text

ex. (1, "What is your favorite ice cream?")

Options
id, question_id, option_text

ex. (1, 1, "Vanilla")

Responses
id, user_id, question_id, option_id

ex. (1, 421, 1, 1)

您还应该在每个表格中添加一些created和modified字段，以便跟踪更改。

将选项存储为描述性字符串或数字？

6 个答案: