在数据库中拥有一个属性表是一个坏主意吗？

通常，当我需要存储系统属性（如管理信息，版本等）时，我使用平面文件（database.properties，init.properties等）。这在我每天看到并使用的其他程序中似乎很常见。在数据库中拥有一个属性表是一个坏主意吗？

有时一个平面文件由于多种原因不理想。将Web应用程序部署到众多客户端通常会受到限制。在这些情况下，我使用数据库表来保存信息。例如，假设我有一些我想要保存的管理数据，也许还有一些关于我的环境的细节。我可能会做这样的事情：

property_entry_table

[id, scope, refId, propertyName, propertyValue, propertyType] 
1, 0, 1, "DB_VER", "2.3.0", "FLOAT" 
2, 0, 1, "LICENCE", "88475", "INT" 
3, 0, 1, "TOP_PROJECT", "1", "INT" 
4, 0, 1, "SHOW_WELCOME", "F", "BOOL" 
5, 0, 1, "SMTP_AUTH", "SSH", "STRING" 
6, 1, 1, "ADMIN_ALERTS", "T", "BOOL"

我意识到这打破了SQL的打字让我各种类型存储为字符串。这是一种好的做法，还是我一直在以这种错误的方式进行讨论？

如果没有，我应该用什么方式存储这种类型的信息？

来源

2010-02-23 Stephano

只要它是一些系统属性的存储等，它没有问题。只是不要想法存储**所有**这样的数据！请参阅这里讨论，为什么：也许是推动的原因：http://www.simple-talk.com/sql/database-administration/five-simple--database-design-errors-you-should-avoid/ – 2010-02-23 19:26:26

这个问题，为什么我在这里投票：http://stackoverflow.com/questions/2300356/using-a-single-row-configuration-table-in-sql-server-database-bad-idea/2300450#2300450 – Stephano 2010-02-23 20:03:17

我已经使用了类似的结构来存储属性数据，我认为这很好，只要表格保持相对较小即可。像这样的实体属性值（EAV）表可能会消耗更多的空间并显示比传统的列结构表慢的查询性能，但这对于合理大小的应用程序属性集应该不是问题。

来源

2010-02-23 19:22:03 newdayrising

不错的链接。看起来像我有一些傍晚的阅读要做。 – Stephano 2010-02-23 20:05:39

这对少量非常不常访问的数据很好。

对于查看模式的用户看不到单个应用程序属性可能实际上会更好。

这可以减少模式更新的问题。（应用程序属性经常被添加/删除。）

它不适合的是大量数据或频繁访问的数据，因为每次检索都有更多的数据库工作要做，而且占用的空间更多，而不是传统的模式。

来源

2010-02-23 19:27:31 martinr

我认为这很好，但是您可能会考虑在读取内容时在内存中缓存数据，以便您不必一直返回数据库。如果你缓存你的数据，然后将它存储在任何地方，使你的更新最容易。将数据保存在数据库中的好处是，维护或创建界面来管理这些属性可能会更容易，特别是一旦您开始为您的应用程序使用分布式环境。

来源

2010-02-23 19:35:48 Middletone

有趣的想法来缓存信息。过去我曾经通过缓存一些我需要的前端数据来完成这项工作。 – Stephano 2010-02-23 20:06:21

在数据库中拥有一个属性表是一个坏主意吗？

回答

相关问题