黑洞相当于什么？
我正在使用 MySQL 5.5 工作一段时间后，在 postgreSQL （最新） 中开始一个新项目。
过去，我大量使用 blackhole 表来简化我的应用程序代码。
它允许我在应用程序代码中进行一次插入：
INSERT INTO blackhole1 (val1, val2, val3, val4 ...
CREATE TRIGGER ai_blackhole1_each AFTER INSERT ....
BEGIN
INSERT INTO table1 (....
INSERT INTO table2 (....
INSERT INTO log (.....
并在黑洞表中使用触发器将值插入到不同的表中。
我在 postgreSQL 中使用什么来替换此功能？
我知道我可以使用存储过程，但这意味着我无法将数据感知控件连接到
黑洞表。所以我希望这个棒尽可能接近 MySQL 原版。
I'm starting a new project in postgreSQL (lastest) having worked with MySQL 5.5 for a while.
In the past I've made heavy use of blackhole table to simplify my application code.
It allows me to do one insert in application code:
INSERT INTO blackhole1 (val1, val2, val3, val4 ...
CREATE TRIGGER ai_blackhole1_each AFTER INSERT ....
BEGIN
INSERT INTO table1 (....
INSERT INTO table2 (....
INSERT INTO log (.....
And have a trigger in the blackhole table insert the values into different tables.
What do I use in postgreSQL to replace this functionality?
I know I can use a stored procedure, but that means that I cannot connect data-aware controls to a
blackhole-table. So I would love the stick as close to the MySQL original as possible.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用 PostgreSQL 9.1，您可以像您一样创建触发器与 MySQL 一起使用。请注意，在 9.1 之前的版本中无法在视图上创建触发器。
您是否对 MySQL 中的 blackhole 表使用存储引擎 BLACKHOLE 还是它只是一个名称？ PostgreSQL 中没有可插拔存储引擎，但您可以通过 PostgreSQL 中的视图上的 INSTEAD OF 触发器获得与 MySQL 中的存储引擎 BLACKHOLE 相同的行为。我不太明白您关于数据感知控件的观点：据我所知，您在 BLACKHOLE 表（存储引擎）中没有任何数据感知，但是在另一方面，您当然可以将休眠实体映射到数据库视图。
使用触发器来简化应用程序代码是好是坏取决于实际用例。例如，与用于日志记录和审核的应用程序逻辑相比，我更喜欢触发器，因为这种方法为连接到数据库的不同应用程序以及管理员的临时查询/语句提供了单一解决方案。但根据我的经验，触发器并不能消除复杂性，而只是将其转移到数据库层。这通常会使多层应用程序更难扩展和维护。
With PostgreSQL 9.1 you can create triggers the same way you can do it with MySQL. Note that it is not possible to create triggers on views in versions before 9.1.
Do you use storage engine BLACKHOLE for your blackhole tables in MySQL or is it just a name? There are no pluggable storage engines in PostgreSQL, but you can get the same behavior as with storage engine BLACKHOLE in MySQL with INSTEAD OF triggers on a view in PostgreSQL. I don't quite get your point concerning data-aware controls: afaik you don't have any data-awareness in a BLACKHOLE table (the storage engine), but on the other hand you can of course e.g. map a hibernate entity to a database view.
Whether it is a good or bad idea to use triggers to simplify application code depends on the actual use case. For example I prefer triggers over application logic for logging and auditing, because this approach offers a single solution for different applications connecting to the database as well as for ad hoc queries/statements by an administrator. But from my experience triggers do not remove complexity but just shift it to the database layer. This generally makes a multi-layered application harder to extend and maintain.