我所在的团队的需求经常变化。我看到在应用程序层中保持约束使我们的生活变得轻松。如果我要遵循在 DB 中指定大多数约束的最佳实践，我会看到我的团队成员遇到困难。当需求变更需要数据库约束变更时，我们必须迁移整个数据。迁移似乎是一个大问题。我们应该做什么？考虑到需求经常变化，最佳实践是什么？
我们希望保持 DB 模式的灵活性，同时又具有数据一致性。
在保持足够灵活的同时，我们仍然可以对 DB 施加哪些限制？
作为一名数据专业人士，我将直接告诉您将约束留在数据库中。
但是，没有正确或错误的答案，因为这取决于您准备应对的风险。
如果您不想要关系完整性，请使用 XML 或 JSON 或其他不是 RDBMS 的东西。但是，如果您想使用 SQL Server 或 Oracle 或 PostgreSQL，请直接在应用程序中进行管理。
但是，在此过程中，会出现数据损坏和孤立记录。这种风险是真实存在的，但我无法告诉您风险有多大。
如果像这样修复损坏的工作少于维护数据库中的约束的工作，那么这是一个可控的风险。
另一方面，如果您无法忍受修复损坏或孤立数据的想法，那么将约束留在数据库中，并花一些钱购买合适的工具来帮助您进行数据库更改和迁移。
PS“敏捷”不是糟糕设计或缺乏文档的借口。
我得到 $50/hr 去修复数据库。几乎不可避免地，一个耗费大量时间和金钱的大问题可以追溯到最初设计阶段制定的捷径。冒着将未来客户扼杀在萌芽状态的风险，这是我的免费建议：不要这样做。
数据库的设计应该建立在两个基础之上。首先当然是数据本身的性质。分析类型、域、关系等是一项不可逾越的任务。二是数据完整性。看在Pete 的份上，不要认为这是一种痛苦，一种必须避免的障碍。如果需要约束，就把它放进去。不要拖延。您可以稍后感谢我。
所以你有一群应用程序开发人员像鸡一样跑来跑去，他们的头被锁在某个地方的抽屉里。还有什么是新的？
不要让它们靠近数据库。甚至不在同一个房间。甚至不要考虑让他们建议模式设计。问他们两个问题：
然后开发我所谓的“抽象墙”。这包括一堆视图和支持的存储过程。这些视图会给他们提供他们可以访问的数据库对象——如果他们真的坚持获得对“数据库”的直接访问。对于为每个表创建平均十个视图，我不会三思而后行。他们希望如何查看数据？为它写一个视图。
存储过程确实是开发人员应该想要的。这些可以提供广泛而灵活的 API，因此他们可以对他们想要的数据执行任何操作，当他们想要这样做时，以他们最容易使用的任何形式获取（或提供）数据。无需直接访问数据库。
灵活，我的意思是这个抽象层可以根据您（和您的开发人员）的核心内容进行开发、重新开发、更改和增长——而无需更改数据库本身的结构布局。
在一个客户的站点，我到达那里时他们刚刚完成一个项目，该项目包括从表中删除一列。结果该列与同一表中的另一列重复。但是所有的应用程序都直接访问表格，因此整个公司（而且它是一家大公司）有任意数量的屏幕、表单和代码可能会在查询或 DML 操作中使用该列。我很惊讶地得知这个特定项目是在 12 个月前开始的。他们花了一年时间才从表中删除一个无用的列！当我建议使用视图时，有人说，“是的。但是我们将不得不维护所有这些视图”，并且这个建议无处可去。
视图只是一个查询。维护起来有多难？但是删除列操作本可以在不更改应用程序代码的情况下在两周的冲刺中完成！
灵活性和数据完整性——您可以兼得。只需要做一点工作，是的，您必须维护这些视图。
| 归档时间： |
|
| 查看次数： |
139 次 |
| 最近记录： |