如何通知在不同进程中完成的SQLite数据库更改过程？

假设我有两个或更多处理SQLite数据库的进程 - 一个"播放器"进程和许多"编辑器"进程.

"播放器"进程读取数据库并更新视图 - 在我的情况下,根据存储在数据库中的事件,它将是混合到声卡的波形.

"编辑器"进程是该数据库的任何编辑器:它不断地更改数据库.

现在我希望播放器快速反映编辑更改.

我知道SQLite提供了钩子来跟踪同一进程中的数据库更改,但似乎没有关于如何使用多个进程执行此操作的信息.

我可以不断地轮询数据库,比较记录和触发事件,但这似乎效率很低,特别是当数据库增长到很大的时候.

我正在考虑使用日志表和触发器,但我想知道是否有一个更简单的方法.

关系数据库不是您最好的首选.

为什么？

您希望所有编辑都将更改传递给您的播放器.

您的播放器 - 实际上 - 是所有这些编辑器的服务器.您的播放器需要多个开放连接.它必须听取所有这些连接的变化.它必须显示这些更改.

如果更改非常大,您可以转到混合解决方案,编辑器会持续更改并通知播放器.

无论哪种方式,编辑都必须通知他们玩家他们有变化.它比尝试发现数据库中的更改的玩家简单得多.

更好的设计是服务器,它接受来自编辑者的消息,持久化并通知玩家.此服务器既不是编辑器也不是播放器,而只是一个确保处理所有消息的代理.它接受来自编辑和玩家的连接.它管理数据库.

有两种实现方式.服务器是播放器.服务器与播放器分开.服务器的设计不会改变 - 只有协议.当服务器是播放器时,服务器直接调用播放器对象.当服务器与播放器分开时,服务器会写入播放器的套接字.

当播放器是服务器的一部分时,当从编辑器接收到消息时,将直接调用播放器对象.当播放器分开时,小型阅读器从套接字收集消息并调用播放器对象.

播放器连接到服务器,然后等待信息流.这可以从编辑器输入,也可以是服务器在数据库中持久存储的数据的引用.

如果您的消息流量足够小,以便网络延迟不成问题,编辑器会将所有数据发送到服务器/播放器.如果消息流量太大,则编辑器会写入数据库并向服务器/播放器发送仅带有数据库FK的消息.

请澄清"如果编辑在通知时崩溃,则播放器会在您的问题中永久搞乱".

这听起来像是一个糟糕的播放器服务设计.它不能"永久搞砸",除非它没有得到各个编辑的状态.如果它从编辑器获得状态(例如,试图镜像该状态),那么你应该考虑一种设计,其中玩家只是从编辑器获得状态而不能"永久搞砸".