我正在构建数据库帮助程序和提供程序，并且在以下方面遇到了最佳实践。
说我有一条消息要发送，它的状态为＆＃34;待定＆＃34;，＆＃34;发送＆＃34;，＆＃34;已发送＆＃34;，＆＃34;已发送＆ ＃34;＆＃34;失败＆＃34;并且数据库将跟踪每条消息及其当前状态。
我的初始布局是拥有＆＃34; message_status_type＆＃34;表并将所有不同的状态放入此表中。然后为＆＃34;消息＆＃34;创建一个外键。用于跟踪消息的当前状态并基本上规范化数据库的表。
现在有了android这是最好的方法吗？或者有没有理由不规范化只需将message_status_type（s）存储为消息表中的整数，并在提供者或合同中查找以将ID转换为文本值？
或者最佳做法是保留一个单独的表并让提供者合并数据以抽象出一个＆＃34; message_status_type＆＃34;表？
答案 0 :(得分：0)
首先，您似乎计划将数据库用作消息队列：在继续之前，您应该谷歌并了解其中的缺点。我之前已经做过这件事并且从来没有出现问题，但在高吞吐量情况下锁定可能存在问题。
我个人更喜欢有一个带有外键约束的单独表：它确保所有消息都是您期望的类型，任何人都可以在数据库中查看并查看消息类型。我的消息类型表通常包含每种类型的描述，如果I18n不是问题，您可以将其用于显示标签。有成本：任何插入到消息表中都需要验证消息类型是否满足FKC。此外，在您需要添加新消息类型的任何时候，您都需要使用新类型更新数据库，如果您要维护dev / prod实例，这可能会令人讨厌。