这是一个好的会员付费数据库模式吗？

Question

我正在做一个项目来管理会员资格和其他种类的付款，但主要是会员资格，所以我创建了一个多态模式。任何想法，改进，由于某些原因，我不完全相信这个模式。

正如您将看到的，月、年为空的想法是允许保存任何其他付款的记录

CREATE TABLE IF NOT EXISTS `orders` (
  `id` int(11) NOT NULL auto_increment,
  `partner_id` int(11) NOT NULL,
  `status` enum('pending','accepted','cancelled','other') NOT NULL,
  `created_on` datetime NOT NULL,
  `concept` varchar(250) NOT NULL,
  `type` enum('membership','other') NOT NULL default 'membership',
  `source` enum('dineromail','casati','deposit','other') NOT NULL default 'dineromail',
  `notes` text NULL,
  `last_check_on` datetime default NULL,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM  ;


CREATE TABLE IF NOT EXISTS `payments` (
  `id` int(11) NOT NULL auto_increment,
  `order_id` int(11) NOT NULL,
  `month` int(11) default NULL,
  `year` int(11) default NULL,
  `amount` float NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `idx-order_id-month-year` (`order_id`,`month`,`year`)
) ENGINE=MyISAM ;


CREATE TABLE IF NOT EXISTS `partners` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `name` varchar(255) default NULL,
  `last_name` varchar(255) default NULL,

) ENGINE=MyISAM;

Answer 1

我还会包括一个日期，时间戳，当收到付款，并可能标记，如果付款是完整或不完整的金额。

Answer 2

以下是几个通信：

在这种情况下，我会考虑将作为枚举。它当然可以消除所有的歧义，除非你需要在那个字段上做数学运算(这是之前的那个)。

1. 钱应该存储为小数，而不是浮点数。如果不这样做，奇怪的舍入会悄悄出现。
2. 订单的价格是没有概念的。如果他们少付了钱，你怎么知道他们付了多少钱?多对多(与3有关)你通常会把它看作是发票和付款类型的表示(即使你不开发票)，所以这意味着一次付款可以代表多个订单，反之亦然，所以这意味着你关心他们如何付款的多对多relationship.
3. Do (
4. )？(支票、信用卡、现金等？)
5. 如果一个月内只能收到一次付款，为什么要下多次付款的订单？如果在同一个月内收到付款，您会如何处理？这里真的应该只有一对一的关系吗？

Answer 3

我同意jtyost2和Yishai之前的回答。

另一个注意事项是，我们的约定是用单数命名实体表，与类名匹配。也就是说，我们命名一行(我们命名类的一个实例)，而不是命名集合。我们要问的问题是，这个表中的一行代表一个什么？我们对类和表使用这个单数名称。(预见到反对意见，是的，我确实认识到其他开发人员和其他框架遵循“复数化表名称”的约定。Rails甚至在复数方面足够智能，可以从Person类生成一个"people“表。)

但是，当表名开始变得复数时，我注意到通常只有一些表名变得复数，最终变成了单数和复数的混合名称。

`partner_id`
`order_id`

您的外键列的命名方式与我们命名它们的方式完全相同。对于外键列，我们遵循的约定是使用父表的名称，后跟_id。对于与同一个表的多个关系，我们使用角色的名称作为表名的补充或替代。

我还建议在数据库中添加外键约束定义，即使MyISAM引擎不强制执行它们。

在每个表的ID列上添加一个primary key约束(它似乎在partner表中缺失。

使用唯一索引标识自然键。

在我看来，有两种支付模式：

• 为每个订单提供一次全额付款

这就是亚马逊似乎在使用的模型。可能会有奖金优惠券和积分应用于订单，但当涉及到付款时，我只为订单支付一次。

• 对帐户余额的付款

另一种模式是使用帐户，并对帐户应用费用、信用和付款。这是电话公司等公用事业公司通常使用的模型。这允许像当前余额和到期金额这样的概念。

在这方面，你的设计似乎不合常规。没有客户账户的概念。然而，似乎一个订单会有多次付款。