“黑洞”桌子是邪恶的吗？

Question

阅读这个问题，我刚刚了解了blackhole表技巧的存在:基本上包括使用单个表插入数据，然后使用一个触发器将数据拆分到许多其他表中。

我想知道，一旦从事这个项目的开发人员意识到这一点，这是否会导致问题。

这种技术的利弊是什么？

编辑：当我看到这个例子时想到的闪现是关于事务的:如果由于某种原因事务失败了，您将找到带有原始数据的blackhole行，用于历史目的，或者帮助调试--但这似乎是我在黑洞中所能看到的唯一+1。想法？

Answer 1

我不认为黑洞有任何真正的优点。

编写用于移动数据的触发代码可能并不比编写代码在正确的位置插入数据要少得多。

正如克里斯蒂安·奥达德( Christian Oudard )所写的那样，它并不能降低复杂性--只是把它移到一个很难调试的地方。

不利方面：

在软件开发中，“副作用”通常是个坏主意。触发器是副作用--我打算做一件事(在表中插入数据)，它实际上做了很多其他的事情。现在，当我调试我的代码时，我必须把所有的副作用都保留在我的脑子里--而且副作用本身也可能有副作用。

大多数软件在维护上花费的时间比在开发中花费的时间多得多。将新开发人员引入团队并解释黑洞技巧可能会增加学习曲线--在我看来是微不足道的(我认为)。

因为触发器是副作用，如果你不小心的话，很容易引发大量的触发器，所以我一直试图设计我的数据库而不依赖触发器；如果触发器显然是正确的，我只让我最有经验的开发人员创建它们。黑洞的诡计使触发器变成了一种正常的、有规律的工作方式。当然，这是个人的观点。

Answer 2

提示您的原始问题并不是MySQL的“黑洞”的核心。

黑洞是什么？

在MySQL中，BLACKHOLE是一个简单地将所有数据INSERTed丢弃到其中的http://dev.mysql.com/doc/refman/5.5/en/blackhole-storage-engine.html，类似于一个空设备。使用这个后端有很多原因，但它们往往有点深奥：

• “仅限中继”的二进制日志过滤从站。 参见文档，以及这里和这里。
• 基准测试 例如，在不担心存储引擎开销的情况下测量二进制日志的开销。
• 各种计算技巧 见这里。

如果您不知道为什么需要伪装成表的数据接收器，就不要使用它。

你要问的是什么技巧？

正在考虑中的使用似乎是：

1. 将INSERTed数据重定向到其他表
2. 审计日志原始INSERTion操作
3. 丢弃原始插入数据

因此，对“邪恶”或利/弊问题的答案与对可插入/可更新的视图(实现#1的常见方式)、基于触发器的审计日志记录(大多数人如何执行#2)和行为重写/抵消(有许多方法完成#3)的问题的答案相同。

那么，答案是什么？

当然，答案是，“有时这些技术是合适的，有时不是。”:)你知道你为什么要这么做吗？应用程序是实现此功能的更好的地方吗？抽象是太脆弱，太漏，太僵硬，等等吗？

Answer 3

这看起来不是个好主意。如果您想让前端代码保持简单，为什么不直接使用存储过程呢？如果不是为了保持前端代码的简单性，我根本就不明白这一点。