T-SQL 数据库设计和表格答案

【问题标题】：T-SQL database design and tablesT-SQL 数据库设计和表格
【发布时间】：2023-03-26 00:16:01
【问题描述】：

我想听听关于数据库设计问题的一些意见或讨论。我和我的同事正在开发一个金融行业的复杂应用程序，该应用程序正在多个国家/地区安装。

我们的承包商希望我们为所有国家/地区保留一个应用程序，因此我们自然会面临每个国家/地区不同工作流程的困难，并尝试使应用程序可调整以满足各种需求。

我今天遇到的问题是来自承包商方面的 IT 部门负责人的请求，要求我们根据它们所包含的表和列来保留数据库模型。

例如，我们有一个不同风险的表，我们需要添加一个标志列IsSomething (BIT NOT NULL ...)。根据第三范式，它完全有资格存在于风险表中，对键没有传递依赖，非键值...

但是，这家伙说他想保持表格原样，所以我们必须创建一个新表格“riskinfo”并将数据 1:1 链接到新列。

你有什么意见？

【问题讨论】：

我会改写你的问题。你冒着因为“主观和争论”而被关闭的风险。我会直截了当地问“这是一个可以接受的想法吗”并消除讨论的欲望。
如果这听起来很主观和有争议，我真的很抱歉。肯定没有这样的意图。试着把它作为一个和我一样惊讶的程序员来阅读，你可能会对它有不同的感觉。我不会更改字符。
二进制，我发布了一个正在开发应用程序的背景，然后描述了一个情况（绝对清楚）。然后给出了一个例子，所以没有人对问题的细节感到困惑。然后是最后一个问题.. 我同意，这听起来可能与许多观点不同.. 下一次，没有大写锁定.. 但请原谅我，我不是以英语为母语的人.. 这些问题对我来说听起来不合情理。

标签： sql database-design

【解决方案1】：

我们将列添加到我们的表中，这些列一直被各种应用程序引用。

只要应用程序专门引用了它们要使用的列，并且您确保新字段可以为空或定义了合理的默认值，因此它不会干扰插入，我看不出任何真正的问题。

也就是说，如果应用执行 select * 然后继续按索引而不是名称引用列，您可能会在现有代码中产生问题。就我个人而言，我相信由于我们的编码约定，没有任何引用我们的数据库会这样做（我怀疑代码审查过程会私刑尝试它的人：P），但如果您不确定，那么至少存在一些小风险到这样的改变。

在您的实际情况下，我会回到承包商那里，并给出您认为更改不会导致任何问题的理由，并询问他们选择背后的理由。也许他们的建议背后有一些特定于应用程序的智慧，也许只是因为与其他以不向后兼容的方式更改数据库结构的公司打交道而偏执，或者也许这只是他们公司的一项政策，得到了长期的橡皮图章以前，没有人受到挑战。直到你问你才知道。

【讨论】：

感谢您的建议。我的印象是偏执狂在后面..但是，这将是一个讨论的主题，我希望这个问题可以很容易地解决。我认为承包商试图拥有一套永远不会改变的核心表..因为我们一直在添加新功能并且它们是“特定于国家/地区的”，他们希望有一些易于理解的基表国家。我只是觉得他们的解决方案人手不足，而且不是很系统。但是......他们的小请求已经开始讨论更深层次的问题......这可能很有用。

【解决方案2】：

这个问题确实像 Binary Worrier 评论的那样是主观的。我没有答案，也没有任何建议。只是分享我的 2 美分。

您知道做出这些决定的理由吗？有时，为了不破坏当前工作的应用程序，或者仅仅因为在前一个应用程序的基础上做了太多的事情，好的设计会受到损害。也可能是许多其他非技术原因。

【讨论】：

我同意 .. 有时 .. 妥协 .. 非技术原因。我理解在某些情况下它的必要性。当一个简单的表需要另一个标志列时，就不会这么想了。有没有人遇到过一些文献或网页来处理这个非技术性违反 db 模型的问题？
这里的“主观”词是咒语吗？对不起，我确实是新手。但从我的角度来看，一个人不可能是主观的。客观性作为一个词永远不会完全表达其含义。在说出任何自己的意见之前声明尊重其他意见是自我欺骗客观存在的一个很好的例子。虽然..'可能你有不同的意见。我同意你的看法。'我知道我想要的讨论是关于不同的问题，但我发现主观性问题相对有吸引力。
@Daniel，“主观”意味着你不能真正有一个明确的正确或错误答案。虽然您可以选择不接受任何答案，但通常建议您接受答案或将其标记为 wiki。
@Daniel，不要为了接受而接受答案。 fyjham 也提出了一些非常好的观点:)
是的，我同意 .. 这就是为什么我首先接受了你的，当他出现时，我改变了主意并接受了他的 :-) 不过，感谢你的关心。

【解决方案3】：

编程社区经常不合理地担心重新定义表所产生的连锁反应。通常，这是由于未能理解数据独立性，以及未能保护其对数据的操作的数据独立性造成的。有时，最初的数据库设计者会出错。

大多数面向对象的程序员比我更了解封装。但是这些专家通常不理解关于数据独立性的深蹲。任何学习过如何操作 SQL 数据库但从未学习过数据独立性概念的人都是危险的无知。可以在大约五分钟内了解数据独立性的肤浅方面。但要真正学习需要时间和精力。

其他响应者提到了使用“select *”的查询。与列出表中所有列名称的相同选择相比，带有通配符的选择更依赖数据。这只是众多例子中的一个。

问题是，数据独立性和封装性都追求相同的目标：包含模型更改的意外后果。

以下是让您的 IT 主管满意的方法。使用新名称定义一个新表，其中包含旧表中的所有列，以及现在需要的所有附加列。创建一个与旧表同名的视图，该视图包含与旧表完全相同的列，并且顺序相同。通常，此视图将显示旧表中的所有行，并且旧 PK 仍将保证唯一性。

有时，这将无法满足 IT 主管的所有需求。如果 IT 主管真的是在说“我不懂数据库；所以不要改变任何东西”，那么你就在这条小河上，直到 IT 主管改变或被改变。

【讨论】：

有价值的答案，谢谢。我会考虑以程序员认为合乎逻辑的方式来塑造数据库，同时我可以让 IT 主管乐于使用视图，从而使“核心”表在他眼中保持不变。