Это хорошая схема базы данных членских платежей? - PullRequest
Новая
       8

Это хорошая схема базы данных членских платежей?

3 голосов
/ 09 мая 2009

Я делаю проект для управления членством и другими видами платежей, но в основном это членство, поэтому я создал полиморфную схему. любая идея, улучшение, по какой-то причине я не полностью убежден в схеме.

Как вы увидите, идея наличия месяца, года NULL-ABLE позволяет сохранить запись любого другого платежа 

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;

Ответы [ 6 ]

5 голосов
/ 09 мая 2009

Я бы также включил отметку даты и времени для получения платежа и, возможно, отметку, если платеж будет полным или неполным.

4 голосов
/ 15 мая 2009

Несколько комнетов:

  1. В этом случае я хотел бы рассмотреть перечисление month. Это, безусловно, может устранить всю двусмысленность, если только вам не нужно делать математику в этом поле (это было раньше).

  2. Деньги должны храниться в виде десятичной дроби, а не числа с плавающей запятой. Странные закругления заползут, если нет.

  3. Понятия цены заказа отсутствуют. Если они недоплатят, как вы узнаете, на сколько?

  4. (Вид связан с 3). Обычно вы видите это как счет-фактуру и представление типа платежа (даже если вы не выставляете счета-фактуры), так что это означает, что один платеж может представлять более одного заказа и наоборот, так что это подразумевает отношения многих ко многим.

  5. Вас волнует, как они заплатили? (Чек, кредитная карта, наличные и т. Д.?)? 1021 *

  6. Зачем делать заказ с несколькими платежами, если они могут быть получены только один раз в месяц? Что бы вы сделали, если платежи получены в течение того же месяца? Должны ли здесь быть отношения один-к-одному?

2 голосов
/ 16 мая 2009
  • То же самое, что и десятичное число вместо числа с плавающей запятой.
  • Где сумма заказа? Как узнать, должны ли они деньги или нет?
  • Добавление payment_date к payments позволит вам избавиться от orders.last_check_on в пользу представления
  • Нет ли идентификационной информации для платежа? Проверьте # или что-то? Дублирующиеся записи кажутся здесь проблемой ...
  • payments.month и payments.year кажутся странно расположенными. Если бы это было для системы членства, я бы предположил, что вы просто платите, как вы идете. Таким образом, 6 платежей дадут вам 6 одновременных месяцев членства - начиная с даты заказа. Нет необходимости отслеживать, за какой месяц производится оплата (иначе, что это значит, когда я плачу за 6 и 7 месяцев, но не за 1-5?) Если здесь есть некоторые сложности, это может быть другой или два стола эта концепция.

... проект для управления членством и другими видами платежей

type enum («членство», «другое»)

идея наличия месяца, года NULL-ABLE позволяет сохранить запись любого другого платежа

Может быть, я не здесь, но похоже, что вы пытаетесь угадать будущие требования. Если это так ... НЕ. Единой схемы базы данных, подходящей для всех, не существует, поэтому не ставьте под угрозу приложение, которое вы создаете, для приложения, которое вы можете или не можете создать в будущем.

Если у вас есть конкретные варианты использования вне членства, то поделитесь ими. Но у меня есть ощущение, что лучше всего подавать с двумя разными моделями. Type и обнуляемые столбцы обычно кричат ​​о том, что вы пытаетесь втиснуть в отличие от вещей в одной таблице.

2 голосов
/ 16 мая 2009

Я согласен с предыдущими ответами от jtyost2 и Yishai.

Еще одно замечание, наше соглашение заключается в именовании таблиц сущностей в единственном числе, соответствующих имени класса. То есть мы называем одну строку (мы называем один экземпляр класса) вместо того, чтобы называть набор. Вопрос, который мы задаем, состоит в том, что одна строка в этой таблице представляет одну, что? И мы используем это единственное имя для класса и для таблицы. (Предвидя возражения, да, я признаю, что другие разработчики и другие фреймворки следуют соглашению о «множественном названии таблицы». Rails даже достаточно умен при мультипликации, чтобы генерировать таблицу «people» из класса Person.)

Но когда имена таблиц начинают быть множественными, я замечаю, что часто только некоторые имена таблиц становятся множественными, и в итоге получается сочетание единственного и множественного имен. 

`partner_id`
`order_id`

Ваши столбцы внешнего ключа названы так, как мы их назовем. Мы придерживаемся соглашения для столбца внешнего ключа: используйте имя родительской таблицы, за которым следует _id. Для нескольких связей с одной и той же таблицей мы используем имя роли в дополнение или вместо имени таблицы.

Я бы также предложил добавить определения ограничений внешнего ключа в базу данных, даже если механизм MyISAM не применяет их.

Добавить ограничение первичного ключа для столбца ID в каждой таблице (кажется, что он отсутствует в таблице partner.

Идентифицирует естественные ключи с помощью уникального индекса.

Мне кажется, есть две модели для платежей:

  • один платеж полностью за каждый заказ

Это модель, которую Amazon, похоже, использует. К заказу могут применяться бонусные купоны и кредиты, но когда дело доходит до оплаты, я делаю ровно один платеж за заказ.

  • платежей на баланс аккаунта

Другая модель заключается в использовании учетной записи и применении сборов, кредитов и платежей к учетной записи. Эта модель обычно используется такими коммунальными службами, как телефонная компания. Это позволяет использовать такие понятия, как текущий баланс и причитающаяся сумма.

Ваш дизайн кажется нетрадиционным в этом отношении. Там нет понятия учетной записи клиента. Тем не менее, похоже, что за один заказ произойдет несколько платежей.

1 голос
/ 21 мая 2009 
CREATE TABLE [dbo].PaymentLog(  
    TransactionNumber int IDENTITY(1,1) NOT NULL,  
    ReferenceID int NOT NULL,  
    ReferenceType varchar(20) NULL,  
    TransactionID int NULL,  
    CustomerID int NULL,  
    PaymentMethod char(4) NULL,  
    LogType varchar(20) NULL,  
    UserHostAddress varchar(20) NULL,  
    Content nvarchar(4000) NULL,  
    ReasonCode varchar(20) NULL ,  
    Flag nvarchar(20) NULL ,  
    Note nvarchar(200) NULL,  
    [InDate] [datetime] NOT NULL CONSTRAINT DF_PaymentLog_InDate DEFAULT (GETDATE()),    
    [InUser] [nvarchar](100) NULL,  
    CONSTRAINT PK_PaymentLog PRIMARY KEY CLUSTERED (  
        TransactionNumber  
    )   
)
GO

CREATE NONCLUSTERED INDEX [IX_PaymentLog_ReferenceID] ON [dbo].PaymentLog (  
    ReferenceID ASC  
) WITH FILLFACTOR = 90  
GO
0 голосов
/ 10 мая 2009

Кроме того, у меня есть источник в другой таблице, так как вам может понадобиться добавить несколько источников по мере роста приложения.

...