在数据库中拥有属性表是一个坏主意吗？
通常，当我需要存储系统属性（例如管理信息、版本等）时，我会使用平面文件（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 的输入并允许我将各种类型存储为字符串。这是好的做法还是我的做法是错误的？
如果不是，我应该以什么方式存储此类信息？
Often, when I need to store system properties like admin info, versions, and so on, I use a flat file (database.properties, init.properties, etc). This seems common in other programs that I see and use on a daily basis.
Sometimes a flat file isn't ideal for a number of reasons. Deploying a web app to numerous clients often comes with limitations. In these cases, I use a database table to hold the information. For example, let's say I have some admin data that I wish to save, and perhaps some specifics about my environment. I might do something like this:
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"
I realize this breaks SQL's typing and allows me to store all sorts of types as strings. Is this good practice or have I been going about this the wrong way?
If not, in what way should I be storing this type of info?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为这很好，但您可能需要考虑在读取数据时将数据缓存在内存中，这样您就不必继续返回数据库。如果您缓存数据，则将其存储在使更新最容易的地方。将数据存储在数据库中的优点是，维护或创建接口来管理这些属性可能会更容易，尤其是在您开始为应用程序使用分布式环境时。
I think this is fine but you might want to consider caching your data in memory when you read it so that you don't have to keep going back to the DB. If you cache your data then store it wherever will make your updates the easiest. The advantage of housing the data in your DB is that it might be easier to maintain or create interfaces to manage those properties especially once you start to use a distributed environment for you application.
我使用了类似的结构来存储属性数据，并且我认为只要表保持相对较小就可以了。像这样的实体属性值 (EAV) 表可能会消耗更多空间并且表现出比传统的列结构表更慢的查询性能，但这对于合理大小的应用程序属性集来说不应该是问题。
I've used a similar structure for storing property data, and I think it's fine as long as the table will remain relatively small. An entity-attribute-value (EAV) table like this may consume more space and exhibit slower query performance than a traditional column-structured table, but that shouldn't be an issue for a reasonably-sized set of application properties.
这对于少量不常访问的数据来说是很好的。
对于查看架构的用户来说，实际上最好不要看到单个应用程序属性。
这减少了架构更新的问题。 （经常添加/删除应用程序属性。）
它不适合大量数据或频繁访问的数据，因为与数据库相比，每次检索数据库需要做更多的工作，并且占用更多的空间。常规模式。
This is fine for small amounts of very infrequently accessed data.
It may actually be better for a user looking at the schema to not see individual app properties.
This reduces problems with schema updates. (App properties are frequently added/removed.)
What it is not suitable for is large amounts of data or frequently accessed data, as there is far more work for the database to do here per retrieve, and more space taken up, than for a conventional schema.