我的同事创建了一个96列的SQL表

在这里，我们是2010年，具有4年或5年或经验的软件工程师，仍然在设计带有96个压裂柱的工作台。

我告诉他这将是一场噩梦。
我向他展示了我们必须使用普通语言将MySQL与C＃接口。
我解释说，列多于行的表有很大的味道。

不过，我得到“这样会更简单”。

我该怎么办？

编辑*

该表包含来自传感器的数据。
我们有带
Dynamic_D1X的传感器1
Dynamic_D1Y
[...]

Dynamic_D6X
Dynamic_D6Y
[...]

编辑2 *

好吧，我终于离开了那份工作。这是另一个程序员在几个月后昏昏欲睡的一个信号，是管理层没有意识到这是一个问题的另一个信号。

也许他这样做是有充分理由的，例如表演或投资回报率？。

最好的办法是问他问题。有了一定数量的“为什么”，您肯定会让他明白他本身可能是错的（如果他确实是错的）。

我自己有一个与绩效无关但与投资回报率（ROI）相关的案例。我有一个表，其中包含在一周的每个小时（一周中的168小时）具有特定值的对象。我们可以选择创建一个ObjectHour表，该表将包含值，还包含Object的键和小时数的天数。但是，我们也有机会将168个值排在右边。可能就像您的同事所做的一样。

开发人员估计了两种解决方案。简单的解决方案（168列）比设计合理的解决方案便宜很多。为客户带来完全相同的结果。

我们决定采用最简单/最便宜的解决方案，将精力集中在更重要的事情上，例如安全性。

将来，我们将有很多机会来改进它。上市时间是当时我们的首要任务。

不幸的是，您的普通开发人员仍然将关系数据库视为大型平面文件。他们会变得更好的唯一方法是，如果有人负责并以身作则。最近，我率先对数据库中的重要架构进行了重大的重新设计，并遵循了常见的关系实践。突然之间，我们的存储过程变得更加优雅，并且所有适当的索引似乎都因其诞生而就位了。自我驱动的开发人员在没有证据的情况下永远不会相信您。

之前在StackOverflow上已经讨论过类似的内容。

通常，表上有很多列并不一定意味着您做错了什么，但是它肯定会引发一些危险信号，因此您可以仔细查看设计。有时候，一张大桌子是正确的选择，但在许多情况下，其他选择更有意义。例如，一种选择是将存储分为两个表：一个表标识您的实体，另一个表实际上是描述这些实体的属性的键/值存储（因此，您最多可以有96 行每个实体）。其他设计也是可能的。与您的队友交谈，并根据数据规范化，代码可读性和可维护性（插入带有96个属性的语句来填充），性能影响，多长时间可以添加或更改新属性（列），找出稀疏度，找出哪种解决方案更好数据是多少（将填充96列中的多少列，还有NULL保留多少？），以及对报表的影响。任何开发人员都应该能够合理地证明他们的设计决策合理，并证明成本/收益之间的权衡（是的，每个设计决策都是权衡的）对他们有利。您的责任不是投诉或批评，而是提出替代方案并确保他们考虑这些问题。

是否用96列标准化了？是否满足1、2、3等NF？

可能有on实体有96个单独的属性。

否则，请让他在Simple Talk上阅读Joe Celko

这完全取决于。

规范化/非规范化的数据库设计都有其优点和缺点。

我的第一个数据库设计是一种标准化的美。它是灵活且可扩展的。对于除了我自己以外的任何人来说，在代码级别上都是令人难以置信的PITA，对我来说，这也是一个温和的PITA。

我的下一个尝试是扁平结构，并且（a）快了很多，（b）编写起来很容易。而且以后再规范化也不会是一件繁琐的工作。

因此，这可能是一种气味，但是其他一些数据库设计将具有自己令人愉悦的气味。

让他阅读这篇有关技术债务的文章。如果他仍然决定保留这种方式，那么至少您提出了建设性的意见。

查看（编辑后）的帖子，很显然这是一个严重的非规范化表。你该怎么办？如我所见，您有几种选择：

1. 尖叫你的同事，学习如何做他/她/她的工作。可能不太有生产力，但可能会说服其他同事不要惹您。以尖叫的疯子的声望很有用（不要问我怎么知道的）。
2. 向老板大喊同事是个白痴。预测灾难，然后积极致力于破坏项目。归咎于无能的同事在数据库设计上所做的一切。可能直接导致...
3. 退出。如果这是您的主意，那是最好的选择，但是＃2可能会导致非自愿辞职。如果被激怒的老板和/或同事从窗户扔下，请不要在膝盖上刮擦膝盖。（请注意，此处的先前研究很重要。如果老板办公室位于底楼以上，并且发现自己被身体强力推出窗外，则生存的机会会明显降低。请 提前计划！！）
4. 大量饮酒-或移至加利福尼亚并点亮（假设道具19（或其他）通过）。没什么好比的，可以加一些技巧来改善一个人对同事的看法（或者，我听说过）。（公共服务公告：KIDS！这些人是专业人士！请勿在家中尝试！）

分享并享受。

我将在这里闲逛，并假设他将剪切并粘贴大量代码以使用此“新”表。

如果是这样，您可能不会招致任何额外的技术债务。他只是分担了自己的技术债务，可能正朝着某种大统一的方向迈进。

如果他有一些需要96列的可靠方法论，请考虑在这种特殊情况下以其他方式进行操作的实际好处。如果没有，那就给他带来怀疑的好处，但是要提醒他，下次您想进入计划阶段时，下次他做出我们都认为是相当愚蠢的举动时。

完全取决于将要访问架构的应用程序的用例，一次需要什么数据块。以某种方式可以证明表格设计的合理性。

我会把他送到石器时代，强迫他使用文件，或者至少教他如何使用Blob。

真的，有96列...永远不可能是对的。也许ORM会有所帮助。（除非您需要性能，但是您可以让一个更了解数据库的人来处理它）

为此，我将全力以赴，但这就是为什么我将商店中数据建模和软件工程的职责分开的原因。程序员似乎很少以集合的形式思考，而是专注于数据使用（而不是维护第三范式，索引或其他数据库性能问题）。基于我们对纯数据建模/架构问题的经验不足，我们作为程序员还倾向于对数据库结构上的决策持不同意见，而不是我们应该有的分歧。恕我直言，我喜欢我有数据架构师和建模师来接管需求，构建表/ proc /等，然后完全由我来处理输出。

但是，在不知道这种设计的实际原因的情况下（我已经研究了天气传感器，该传感器具有超过96种不同的数字输出=大量的表列）...似乎就像在泄气。