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

通常，当我需要存储系统属性（如管理信息、版本等）时，我会使用平面文件（database.properties、init.properties等）。这在我每天看到和使用的其他程序中似乎很常见

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

属性项表

[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的类型，允许我将各种类型存储为字符串。这是一个好的做法还是我走错了方向

---

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

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

对于少量很少访问的数据来说，这很好

实际上，用户在查看模式时最好不要看到单个应用程序属性

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

---

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

我认为这很好，但是当你读数据时，你可能想考虑缓存在内存中，这样你就不必再回到数据库中去了。如果您缓存数据，则将其存储在任何地方，这将使您的更新变得最简单。将数据存储在数据库中的好处是，维护或创建接口来管理这些属性可能会更容易，尤其是当您开始为应用程序使用分布式环境时。

只要它存储了一些系统属性等，就可以了。只是别想这样存储你所有的数据！请看这里的讨论，为什么：也可能是这个问题的动力，为什么我在这里被否决了：很好的链接。看来我下午晚些时候要看书了。有个有趣的想法来缓存信息。在过去，我通过在前端缓存一些我需要的数据来做到这一点。