一张表的 MySQL 模式
当我需要一个表格来设置我的应用程序的设置时。我总是使用包含许多字段的表：
create table options (
id ...
url ...
keys ..
path ...
)
当然我需要一个ID（因为我有一个设置）
我可以使用其他方法吗，例如：
create table options (
id ...
field ..
)
当 field 是例如：
`key => value`
所以我不需要设置很多领域..BS
： 这些字段有不同的类型： int text datetime .. 等
When I need a table to set settings for my app. I always use table with many fields:
create table options (
id ...
url ...
keys ..
path ...
)
Of course I need one ID (because I have one settings)
Could I use other approach like:
create table options (
id ...
field ..
)
When field is for example:
`key => value`
So I don't need to set many fields ..
BS:
The fields have different types: int text datetime .. etc
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
当然，你可以这样做。只需确保在从数据库中取出值时以及类似地插入或更新它们时转换为正确的类型即可。
PHP 示例：
对于上面的示例，您的架构将需要一个
field(varchar) 和一个value(varchar）。Sure, you can do that. Just make sure you cast to the correct type when taking the values out of the database, and, similarly, when inserting or updating them.
PHP example:
For the above example, your schema will need a
field(varchar) and avalue(varchar).这是一个更好的方法，否则如果您想添加另一个设置，您将需要更改您的模型（数据库：添加列），而不是仅仅向现有表添加一行。
使用：
以及可能的其他一些字段，如类型、必需的...
作为类型使用 Varchar，如果将设置（数据库行）映射到（Java，...）对象，则提供 getValue() 等方法, getValueAsDate(), getValueAsBoolean(), ...
This is a better approach, otherwise if you want to add another setting you would need to change your model (database: add column) instead of just adding a row to an existing table.
Use:
And possibly some other fields like type, required, ...
As type use Varchar and if you map a Setting (a DB-row) to a (Java, ...) Object provide methods like getValue(), getValueAsDate(), getValueAsBoolean(), ...
您可以使用这样的东西：
然后您需要一个将值转换为所需类型的函数。
You can use something like this:
then you need a function that will convert value to required type.
您可以发出不设置每个字段的 UPDATE 语句。
这使得所有其他值保持原样......
you are able to issue an UPDATE statement that does not set every field.
this leaves all other values the way they were...