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

Question

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

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

Answer 1

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