我们目前正在开发一个应用程序,其中使用数据库表来存储平台设置,例如最大文件大小、最大用户数、支持的电子邮件等。
这意味着每次添加平台设置时,我们都必须向该表中添加一列。
在我以前的项目中,我习惯于将此类信息存储在文件中。
哪种方式更好/更快?
附注:我几乎可以确定有人已经有了这样的问题,但我似乎找不到它
我们目前正在开发一个应用程序,其中使用数据库表来存储平台设置,例如最大文件大小、最大用户数、支持的电子邮件等。
这意味着每次添加平台设置时,我们都必须向该表中添加一列。
在我以前的项目中,我习惯于将此类信息存储在文件中。
哪种方式更好/更快?
附注:我几乎可以确定有人已经有了这样的问题,但我似乎找不到它
CREATE TABLE Configuration.GlobalSettings
(
SectionName VARCHAR(50),
SettingName VARCHAR(50),
SettingValue VARCHAR(1000),
SettingType TINYINT
);
SectionName
和SettingName
是主键,我们只是将它们拆分以便更轻松地查询部分内容,并允许单独加载部分内容到处理程序,而不必一次性加载整个内容。 SettingValue
是一个字符串,而SettingType
是一个鉴别器,告诉我们应该如何解释设置值(例如1 =字符串,2 =布尔型,3 =十进制等)。
这意味着您不必为新的设置更改表结构,只需在部署脚本或设置这些内容的任何地方添加一个新的设置即可。
我们认为这种方式比文件更好,因为这意味着可以在需要时通过管理界面轻松编程更改配置值,这可以强制执行可以输入每个设置的逻辑。您无法像使用文件那样轻松地执行此操作(当然,这是可能的)。
作为管理多个站点的特别大型应用程序的负责人,我可以告诉您,在本地文件中保存配置是非常麻烦的。通常情况下,配置被读取并缓存,并且无法在运行时更改,其他系统需要扩展规模,在这些系统中,配置需要重复更改和弹跳。
如果设计人员将系统属性保留在数据库中,那么在系统架构实施期间,我的生活将会变得更轻松10%。
这取决于您的应用程序。
将设置存储在数据库中有几个优点:
缺点:
将设置存储在文件中的优点:
缺点:
这意味着每次添加平台设置都必须向该表添加一列 - 具体取决于您使用的数据库,但您可以将整个设置存储为XML(SQL Server允许此操作),以便在表中不需要更改架构来添加某项设置;您需要做的就是修改XML,向其中添加元素或从其中删除元素。
但最终,您必须自己决定,因为并没有对所有人都是更好或更糟的方法。
NULL
列值。 - Allenphyour-project/
├─ app/
│ ├─ ...
│ └─ config/
│ ├─ config.yml
│ ├─ config_dev.yml
│ ├─ config_prod.yml
│ ├─ config_test.yml
│ ├─ parameters.yml
│ ├─ parameters.yml.dist
│ ├─ routing.yml
│ ├─ routing_dev.yml
│ └─ security.yml
├─ ...
我认为像其他人所说的那样,这取决于你的应用环境和需求。但是如果我不得不选择一个通用规则,我会说两者都需要。 首先,你需要创建一个数据库表来存储所有的配置信息。这有两个好处: 1)版本控制 - 允许您轻松跟踪以前的配置。 2)管理 - 您可以创建一个接口,让用户访问并更改设置。
其次,在将网站发布到生产环境中后,您需要创建一个文件来保存所有这些设置,以便轻松访问。实际上,如果您正在使用PHP进行网络编程,那么该文件应该是一个包含数组数据(键值对)的php文件,无需进一步操作即可使用。也就是说,如果您需要的最终输出是yaml或json格式的数组,那么就不需要将它们转换成数组。
就像其他人所说的,这取决于情况。需要问的问题是:设置需要多经常更改?如果需要更改,是否意味着正在进行更大的更改,或者已经存在接受不同值的功能?最重要的是...你的部署过程是什么?如果您有自动化部署流程,并且预测值更改的频率为每周或更长时间,我通常会使用设置文件。
为什么?版本控制和环境推广。使得在这里轻松切换这个和那个的确方便,但几乎不可能说“我的开发环境稳定并按预期工作,让我们将更改推广到下一个环境。”为什么?因为上周五未知的验收测试人员将enableSuperDuperFeatureEveryoneExpects切换为false。现在有解决这个问题的方法,在具有5个配置和1个开发人员的小型应用程序中,这不是问题,但是如果您正在处理具有8个团队,超过40个模式的100个配置表的企业应用程序,则拥有永无止境的噩梦。这可以通过配置模式来解决...但我个人会尽量在数据库中保留尽可能少的配置,除非您的应用程序很小...而定义“小”我会说,一旦有多个团队在应用程序上工作,您的应用程序就不再是小型的。
数据库配置的另一个问题是防止在运行时输入无效条目。如果您的应用程序有一个配置,比如defaultLandingPageAfterAuth,只接受home和dashboard这两个值,而某人在周五下午不小心将homw放入生产环境中,会发生什么?现在,您可以使用数据库枚举...我建议这样做...但您会吗?