8

通常，当我需要存储管理信息、版本等系统属性时，我会使用平面文件（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 的输入，并允许我将各种类型存储为字符串。这是一个好的做法还是我一直在做错误的事情？

如果没有，我应该以什么方式存储此类信息？

4

3 回答 3

2

我认为这很好，但是您可能需要考虑在读取数据时将数据缓存在内存中，这样您就不必继续返回数据库。如果您缓存您的数据，然后将其存储在任何地方将使您的更新最容易。将数据存放在数据库中的优势在于，可能更容易维护或创建接口来管理这些属性，尤其是在您开始为应用程序使用分布式环境时。

于 2010-02-23T19:35:48.640 回答
1

我使用了类似的结构来存储属性数据，我认为只要表保持相对较小就可以了。与传统的列结构表相比，这样的实体属性值 ( EAV ) 表可能会消耗更多空间并表现出更慢的查询性能，但这对于一组合理大小的应用程序属性来说应该不是问题。

于 2010-02-23T19:22:03.713 回答
0

这对于少量非常不经常访问的数据来说很好。

实际上，对于查看架构的用户来说，看不到单个应用程序属性可能会更好。

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

它不适合大量数据或频繁访问的数据，因为与传统模式相比，每次检索时数据库要在这里做的工作要多得多，占用的空间也更多。

于 2010-02-23T19:27:31.543 回答