Web内部交流平台的SQL数据库设计

Question

我正在开发一个允许用户相互交易信用的小型 Web 应用程序。我想在我的初始设计（效率、灵活性、安全性等）中加入你们的 cmets。

特别是，典型的交易发生如下：

用户 A 可以提议做某项工作以换取 X 积分。用户 B 和 C 可以接受该提议。将从 B 和 C 的账户中扣除总共 X 个学分。作业完成后，X 积分将添加到 A 的帐户中。 A 可以使用赚取的积分与其他用户进行交易。

我正在考虑一个包含 3 个表的数据库：Job、Transaction 和 Account。帐户表将跟踪每个用户获得和花费的信用。

每次用户 A 为用户 B 和 C 完成一项工作时：

• Transaction表中记录了两笔交易：一笔从B到A的转账，一笔从C到A的转账

• 账户表将被更新：A、B、C 的账户中的可用积分将被更新

• 作业表也已更新。

（所有这些操作都将包装在一个 SQL“事务”中，即所有记录都被更新，或者不更新）

当交易被恢复时（例如，A 和 B 之间，但 A 和 C 之间没有），A 和 B 的 Account 和 Account_History 将被更新，A 和 B 之间的交易将被设置为“revert”。

Rails 中的草图如下：

• 类作业

  属性：:job_id, :total_credit,:created_at, :updated_at

  belongs_to :seller, :class_name => “用户”belongs_to :buyers, :class_name => "User" # 一项工作可以为多个用户完成

• 类交易

  属性：transaction_id、:buyer_id、:seller_id、:status、
  :credit, :created_at, :updated_at

  belongs_to :seller, :class_name => “用户”belongs_to :buyer,
  :class_name => "用户#每次信用交换一个交易记录
  属于_to :account

• 类帐户

  属性：:account_id, :user_id, :available_credit

  belongs_to: 用户

我不确定我是否应该：

1. 创建 Account_History 表以显示提取的摘要统计信息 来自 Account 表（例如上个月的交易、总信用 赚取/花费等）给客户，或将这些信息存储在一个系列中 缓存查询。

   表示一个待处理的交易（即，当 B 接受 A 的要约但 工作尚未完成）和已完成的事务（即，当 B 接受 A 的工作）在事务表中的单独记录中。这 其他选择只是改变交易状态 待完成。

感谢您的 cmets。

Answer 1

更传统的方法是使用更多的复式记帐设计。

您几乎可以在任何地方阅读有关此设计的信息，但这里有一个指向pretty good discussion 的链接，了解它是什么以及它是如何工作的。

您的设计的结果是您需要一个单独的表来将示例事务的两个部分绑定到一个工作单元中。您需要一个表，每个业务交易有一个条目，另一个表，该交易中涉及的每个帐户都有一个条目。在引用的链接中，这些是 JOURNAL 和 POSTING 表。

在这种设计中，可用积分不会存储在帐户中，除非您希望将其作为非规范化。通常情况下，总是会计算余额。

您可以决定创建一个帐户余额历史记录表以用于报告目的，但如果您的系统允许编辑旧交易（它不会， 如果它是一个传统的会计系统）。

如果您想区分待处理的事务和已完成的事务，则可以在事务上放置一个状态标志（在引用的链接中，JOURNAL 表中）。但是，还有一个更全面的会计惯例，它会给每个用户两个帐户，一个是已获得的信用，一个是未获得的信用。在此方案中，使用您的示例，B 和 C 会将一些信用存入 A 的待处理信用帐户。这将立即在 B 和 C 的账户上产生提款，这样他们就不会在其他地方花费这些积分。当 A 完成工作时，这些积分将从 A 的待处理帐户转移到 A 的当前帐户。如果工作被取消，您将进行交易以从 A 的待处理帐户转回 B 和 C 的当前帐户。

这种方式可能看起来有点复杂，但它的明显优势是始终记录发生的一切。