通常，当我需要存储管理信息，版本等系统属性时，我使用平面文件（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的输入，并允许我将各种类型存储为字符串。这是一种很好的做法，还是我错误地采取了这种做法？
如果没有，我应该以什么方式存储此类信息？
答案 0 :(得分：2)
我认为这很好，但您可能需要考虑在阅读时将数据缓存在内存中，这样您就不必再继续使用数据库了。如果您缓存数据，则将其存储在最容易进行更新的位置。在数据库中存储数据的优点是，维护或创建接口以管理这些属性可能更容易，尤其是在您开始为应用程序使用分布式环境时。
答案 1 :(得分：1)
我使用了类似的结构来存储属性数据，我认为只要表格保持相对较小就可以了。像这样的实体属性值（EAV）表可能比传统的列结构表消耗更多空间并显示更慢的查询性能，但对于相当大的应用程序属性集应该不是问题
答案 2 :(得分：0)
这适用于少量非常少访问的数据。
对于查看架构的用户而言，实际上可能不会看到单个应用程序属性。
这减少了架构更新的问题。 （经常添加/删除应用程序属性。）
不适合的是大量数据或经常访问的数据，因为每次检索数据库要做的工作要多得多，并且占用的空间比传统模式要多。