Relational DB 的 View of View AntiPattern？答案

【问题标题】：Relational DB's View of View of View AntiPattern?Relational DB 的 View of View AntiPattern？
【发布时间】：2014-08-11 12:25:13
【问题描述】：

我继承了一个导致我出现问题的数据库。

我需要向利益相关者描述一些可怕的事情。到目前为止，使用反模式的名称并将它们发送出去，将它们指向谷歌搜索，这是为我争取时间的最有效方法。

麻烦的是，我以前没有遇到过这种情况。这是正在发生的事情。

我有一个简单的单表，有几列。其中一列包含以下值：

660x90_SomeCity_SomeCountryISO_ImageName_SomeRubbish

或

SomeIataAirportCode_SomeCountry_660x90_SomeRubbish_ImageName

现在数据库包含一个（不可否认的是到目前为止和当前数据）无故障逻辑来提取和查找内容，以便输出具有额外的列，例如：

问题在于，这是通过在 50 个（不是开玩笑的）不同视图的迷宫中实现的逐步转换来实现的。我现在必须将逻辑形式化为

对我来说，这是一个可怕的反模式，应该全部在自定义函数中完成，或者最好在 ETL 过程中，在一个地方完成，以便捕获逻辑。

但是我没有时间，我想知道这是否是一种已知的反模式。通常我可以利用谷歌搜索的可信度来争取一点时间来真正解决这个问题。

【问题讨论】：

一列中有多个值是绝对不行的。它违反了第一范式。通常关系数据库至少是第三范式。如果我是你，我不会把时间浪费在提取数据的无穷无尽的视图和函数上。获取多列中的数据，重新考虑您的数据库设计...
我完全明白了。我将基表视为我的 ETL 的临时表和一个很好的规范化表输出 - 现在存在于最终视图中。我打算使用最后一个视图来填充新的规范化设计。然而，到达这一点的逻辑是如此分布在这 50 个奇怪的视图中，如果任何规则发生变化，我必须查看其中的大部分以进行修改。所以我想创建一个地方，负责说从这个复合源数据列中提取一个城市，不管格式如何，然后对城市做同样的事情，... .
为什么不使用存储过程，最好有一个 1000 行的存储过程，而不是在您需要更改时尝试跟踪 50 个视图或找出问题发生的原因。跨度>

【解决方案1】：

我将从这个涵盖violation of First Normal Form 的答案开始。

我还发现 this free ebook 可能很有价值。

我知道您所面临的是规模更大的事情，只需将几个值放在一个用逗号或其他标记分隔它们的字段中，但我不知道有任何反模式涵盖这种巴洛克式乱七八糟的。

最后，在这里您可以找到更多 about "replacing SQL logic with Views" as an antipattern（只需在文章中查找“作为 SQL 构建块反模式的视图”），但请注意，在这种情况下，问题似乎与数据访问效率低下有关.

最后一分钟编辑：也许这只是一般Golden Hammer 反模式的一个特例？（另见：http://en.wikipedia.org/wiki/Golden_hammer）

【讨论】：

【解决方案2】：

为什么不简单地重写SQL，然后打印出两者的执行计划，并显示两者的性能和时间。这应该足以向他们表明它需要改变（如果没有重大的性能差异，那么您唯一的另一个论点可能是可维护性，这是您将不得不通过向他们展示需要什么来争论的事情进行更改）。

【讨论】：