假设我有两个或多个处理 SQLite 数据库的进程——一个“播放器”进程和许多“编辑器”进程。
“播放器”进程读取数据库并更新 View - 在我的例子中，它是根据数据库中存储的事件混合到声卡的波形。
“编辑器”进程是该数据库的任何编辑器:它不断更改数据库。
现在我希望播放器能够快速反射(reflect)编辑更改。
我知道 SQLite 提供钩子(Hook)来跟踪同一进程中的数据库更改，但似乎很少有关于如何在多个进程中执行此操作的信息。
我可以不断地轮询数据库、比较记录和触发事件，但这似乎效率很低，尤其是当数据库增长到很大时。
我正在考虑使用日志表和触发器，但我想知道是否有更简单的方法。
最佳答案
关系数据库不是您的最佳首选。
为什么？
您希望所有编辑器都将更改传递给您的播放器。
您的播放器实际上是所有这些编辑器的服务器。您的播放器需要多个打开的连接。它必须监听所有这些连接的变化。它必须显示这些更改。
如果更改确实很大，您可以转向混合解决方案，其中编辑器保留更改并通知玩家。
无论哪种方式，编辑都必须通知玩家他们有更改。这比玩家试图发现数据库中的变化要简单得多。
更好的设计是一个服务器，它接受来自编辑器的消息，保存它们，并通知玩家。该服务器既不是编辑器也不是播放器，而只是确保处理所有消息的代理。它接受来自编辑和玩家的连接。它管理数据库。
有两种实现方式。服务器是播放器。服务器与播放器是分开的。服务器的设计没有改变——只有协议(protocol)。当服务器是播放器时，服务器直接调用播放器对象。当服务器与播放器分离时，服务器写入播放器的套接字。
当播放器是服务器的一部分时，当从编辑器收到消息时直接调用播放器对象。当播放器分离时，小型读取器从套接字收集消息并调用播放器对象。
播放器连接到服务器，然后等待信息流。这可以是来自编辑器的输入，也可以是对服务器保存在数据库中的数据的引用。
如果您的消息流量足够小，网络延迟不是问题，编辑器会将所有数据发送到服务器/播放器。如果消息流量太大，则编辑器写入数据库并向服务器/播放器发送仅包含数据库 FK 的消息。
请在您的问题中澄清“如果编辑器在通知时崩溃，则播放器将永久困惑”。
这听起来像是播放器服务的糟糕设计。除非它没有从各个编辑那里获得状态，否则它不可能“永远搞砸”。如果它从编辑器获取状态(但试图镜像该状态，例如)，那么您应该考虑这样一种设计，玩家只需从编辑器获取状态并且不会“永远搞砸”。
关于python - 如何将在不同进程中完成的 SQLite 数据库更改通知进程？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/677028/