配置文件vs数据库表

我特别感兴趣的场景是多台服务器具有在某些配置参数上运行的守护进程。（因为这是一个学习练习，我欢迎超出这个特殊情况的任何想法）问题是，配置参数应该放在哪里。配置文件vs数据库表

A.中央数据库表

B.一个配置文件推送到每个框

这是最常见的，我碰到过。其他值得注意的是，在代码常量中（需要重新编译才能部署，除非它们真的是常量，否则选择这么糟糕的选项），将配置文件安装在共享位置上。

只是想从社区知道你如何去做选择。

来源

2010-07-06 neal aise

这一切都取决于您所管理的操作规模。

如果位置数量很大和/或更改频繁，请使用数据库。

否则，请使用配置文件。

如果对集中式数据库的访问速度太慢或无法接受是故障点，但规模仍然很大，请使用像Puppet这样的自动化系统。

来源

2010-07-06 22:34:44 Borealid

最后一点可以通过从站和查询缓存来缓解。 – 2010-07-10 09:37:33

如果可能，我的首选是数据库。我愿意在应用程序启动时支付性能成本。保存数据库的选项比配置文件更多。 – Vadim 2011-10-22 14:12:21

大多数需要在服务器/应用程序之间共享配置参数的公司最终创建了自己的配置机制，并将它们存储在家庭关系数据库中。我认为规模并不重要。必须登录到多台服务器才能检查文件系统上的配置是一场噩梦。但是，即使在中央数据库中管理配置时，您仍然必须确保配置易于访问。我已经看到这种类型的配置在3家不同的公司使用，而且它是以真正成功的方式使用的唯一地方，就是应用程序公开了一个简单的用户界面，允许系统管理员调整设置。如果只能通过使用SQL客户端访问，那么您会发现配置很容易“丢失”或者更糟糕，重复。

上面的海报提到了Puppet，我从来没有用过，但它看起来很有趣。但它看起来并不像它支持Windows [1]：http://www.puppetlabs.com/puppet/requirements/

来源

2010-07-06 22:45:40 warriorpostman

同意具有用于访问参数的用户界面/或至少一个API。它限制了你获取/设置配置参数的方式，当然也允许你在配置文件和db表之间切换回来:) – 2010-07-10 09:40:31

如果配置属性可以在运行时更新，集中在数据库中的属性将使生活更轻松。

来源

2010-07-06 23:25:01 btreat

配置文件vs数据库表

回答

相关问题