我想听听有关数据库设计问题的一些意见或讨论。我和我的同事们正在开发一个金融行业的复杂应用程序，该应用程序正在几个国家安装。
我们的承包商希望我们为所有国家/地区提供单一申请，因此我们自然会面临每个国家/地区不同工作流程的困难，并尝试使应用程序可调整以满足各种需求。
我今天遇到的问题是来自承包商方面IT部门负责人的请求，即我们根据它们所包含的表格和列保留数据库模型。
对于examlpe，我们得到了一个具有不同风险的表格，我们需要添加一个标记列IsSomething (BIT NOT NULL ...)。根据第三范式，它完全有资格存在于风险表中，对密钥没有传递依赖，非关键值......
但是，那个人说他想保留表格，所以我们不得不制作一个新表“riskinfo”并将数据1：1链接到新列。
您有什么看法？
答案 0 :(得分：2)
我们会在各个应用程序引用的表中添加列。
只要应用程序专门引用他们想要使用的列，并确保新字段可以为空或者定义了合理的默认值，因此它不会干扰插入，我看不到任何实际问题。< / p>
也就是说，如果一个应用程序执行select *然后继续按索引而不是名称引用列，则可能会在现有代码中产生问题。就我个人而言，由于我们的编码惯例（我和我怀疑代码审查过程会欺骗尝试它的人：P），我有信心没有引用我们的数据库这样做，但如果你不确定那么至少存在一些小风险这样的改变。
在您的实际情况中，我会回到承包商并说明您认为更改不会导致任何问题的原因并询问他们选择背后的理由。也许他们在他们的建议背后有一些特定于应用程序的智慧，也许只是与其他以不向后兼容的方式改变数据库结构的公司的偏执，或者可能只是他们公司的橡皮图章长的政策以前没有人受到挑战。直到你问你永远不会知道。
答案 1 :(得分：1)
这个问题确实是主观的，就像Binary Worrier评论的那样。我没有答案也没有任何建议。只需分享我的2美分。
你知道这些决定的理由吗？有时好的设计会因为没有破坏当前正在运行的应用程序而受到损害，或仅仅因为基于前一个应用程序已经完成了太多的事实。这也可能是许多其他非技术原因。
答案 2 :(得分：0)
很多时候，编程社区不合理地担心重新定义表格会产生连锁反应。通常，这是由于无法理解数据独立性，以及无法保护数据操作的数据独立性。有时，原始数据库设计师有问题。
大多数面向对象的程序员比我更了解封装。但是这些专家通常不了解数据独立性。任何学过如何操作SQL数据库但从未学过数据独立概念的人都是危险无知的。数据独立的表面方面可以在大约五分钟内学到。但要真正了解它需要时间和精力。
其他响应者提到了使用“select *”的查询。带有通配符的选择比列出表中所有列的名称的相同选择更依赖于数据。这只是几十个中的一个例子。
问题是，数据独立性和封装都追求相同的目标：包含模型变化的意外后果。
以下是如何让您的IT主管感到高兴。使用新名称定义一个新表，该新名称包含旧表中的所有列，以及现在必需的所有其他列。创建一个与旧表名称相同的视图，该视图包含与旧表具有完全相同的列和相同的顺序。通常，此视图将显示旧表中的所有行，旧PK仍将保证唯一性。
有一段时间，这将无法满足所有IT主管的需求。如果IT负责人真的说“我不理解数据库;所以不要改变任何东西”，那么在IT主管改变或改变之前，你就是小河。