Bu iyi bir üyelik ödeme veritabanı şeması var mı?

5 Cevap php

Ben üyelik ve diğer ödeme türlü yönetmek için bir proje yapıyorum, ama esas üyelik yüzden bir polimorfik şema oluşturulmuş. Herhangi bir fikir, iyileştirme, ben şeması hakkında tamamen ikna yok nedense.

Gördüğünüz gibi, yıl null-MÜMKÜN başka herhangi bir ödeme kaydını kaydetmek ay olan fikri izin edilir

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;

5 Cevap

Bir ödeme tam veya eksik miktar ise ben de ödeme muhtemelen alınmış ve marka için bir tarih zaman damgası içerir.

Birkaç commnets:

  1. Ben ay bu durumda bir enum yaparak düşünecektim. Bu alanda matematik yapmak gerekir sürece kesinlikle, tüm belirsizliği kaldırmak olabilir (bu daha önce oldu).

  2. Para bir Decimal değil, bir şamandıra olarak saklanmalıdır. Değilse garip yuvarlama şeyler sürünme olacaktır.

  3. Bir siparişin fiyat hiçbir kavram yoktur. Onlar eksik olursa, nasıl ne kadar bilirler?

  4. (3 ilgili Kind) Genellikle bu yüzden, (eğer fatura sorunu bile), bu bir ödeme birden fazla sipariş temsil gelebileceğini ima diye, ve tersi bir fatura ve ödeme türü temsili olarak görecekti birçok ilişki için bir çok ima eder.

  5. Eğer onlar ödenen nasıl önemsiyor musun? (Vb Kredi Kartı, Nakit, Çek?)

  6. Sadece bir ay içinde bir tane alınabilir eğer Neden birden fazla ödeme ile sipariş yapmak istiyorsunuz? Ödemeleri aynı ay içinde alınan olsanız ne yapardınız? Gerçekten burada sadece bir-bir ilişkisi olmalı mı?

Ben jtyost2 ve Yishai dan önceki cevapları ile hemfikir.

Bir diğer not, bizim kongre sınıf adı eşleşen, tekil varlık tabloları isim olduğunu. Yani biz bir satır (biz sınıfın bir örneğini adlandırabilirsiniz) yerine seti adlandırma isim vardır. Biz sormak soru, bu tabloda bir satır bir şeyi temsil eder, nedir? Ve biz sınıf ve tablo için bu tekil ad kullanabilirsiniz. (Evet, ben diğer geliştiriciler ve diğer çerçeveler 'tablo adı çoğul' kuralını takip tanımadığınız, itirazları öngörülmesi. Raylar bir kişi sınıftan bir "halk" tablo oluşturmak için pluralization de bile yeterince akıllı.)

Tablo adları çoğul alma başladığınızda, ben genellikle sadece tablo bazı isimlerin çoğul olsun fark, ve bu tekil ve çoğul isimler bir karışımı olmak biter.

`partner_id`
`order_id`

Yabancı anahtar sütunları biz onları isim olurdu tam şekilde adlandırılırlar. Biz yabancı bir anahtar sütun için takip kongre _id ardından adını üst tablo, kullanmaktır. Aynı tabloya birden ilişkiler için, biz ek veya tablo adı yerine rolünün adını kullanın.

MyISAM motor onları zorlamaz bile ben de, veritabanında yabancı anahtar kısıtlaması tanımları ekleyerek öneririm.

Her masada kimlik sütunda birincil anahtar kısıtlaması Ekle (o partner sofranızdan eksik görünüyor.

Bir Unqiue indeksi ile doğal tuşları tanımlayın.

Bu ödemeler için iki model vardır gibi geliyor bana:

  • Her sipariş için tam bir ödeme

Bu Amazon kullanmak gibi görünüyor modeldir. Orada bonus kuponları ve kredileri için uygulanan, ancak aşağı ödeme söz konusu olduğunda, ben sipariş için tam bir ödeme yapabilir.

  • Bir hesap bakiyesine yapılan ödemeler

Diğer model bir hesap kullanmak, ve hesap ücretleri, kredi ve ödemeler uygulamaktır. Bu genellikle telefon şirketi gibi programları tarafından kullanılan modeldir. Bu cari denge nedeniyle miktar gibi kavramların sağlar.

Tasarım bu açıdan sıradışı görünüyor. Bir müşteri hesabı hiçbir kavramı yoktur. Bir sipariş için birden fazla ödeme olacak gibi Ancak, bu gibi görünüyor.

  • Ditto için para yerine float ondalık tutarındadır.
  • Nerede sipariş miktarı var? Onlar borcum olup olmadığını nasıl anlarsınız?
  • payment_date payments Bir görüşe orders.last_check_on kurtulmak izin istiyorum ekleme
  • Bir ödeme için hiçbir tanıtıcı bilgi var mı? # Falan edin? Burada bir sorun olacak gibi yinelenen girdiler görünüyor ...
  • payments.month ve payments.year garip bir biçimde yerleştirilmiş görünüyor. Bu bir üyelik sistemi için ise, ben sadece ödeme-you-go gibi-varsayıyorum ediyorum. Yani, 6 ödemeleri üyeliği 6 eşzamanlı ay alacağı - sipariş tarihten başlayarak. Bir ödeme için ne ay izlemek gerek (aksi halde, ne ben ayda 6 ve 7 için ödeme yaparken demek, ama değil 1-5? Gelmez) burada biraz daha karmaşıklık varsa, onu tutmak için başka bir tablo veya iki olabilir var bu kavram.

... Üyelik ve diğer ödeme türlü yönetmek için bir proje

type enum ('üyelik', 'diğer')

ay olan fikri, yıl null-MÜMKÜN başka herhangi bir ödeme kaydını kaydetmek izin edilir

Burada baz kapalı olabilir, ancak gelecekteki ihtiyaçları tahmin etmeye çalışıyoruz gibi geliyor. Bu durum buysa ... ETMEYİN. Orada kimse-boyut-uyan tüm veritabanı şema - yani sen veya gelecekte inşa olmayabilir uygulaması için bina konum uygulamayı ödün vermeyen.

Eğer üyelik dışında somut kullanım durumları varsa, bunları paylaşmak. Ama, ben en iyisi 2 farklı modelleri ile hizmet edeceğimi bir his var. Type ve null sütunlar genellikle aynı tabloya şeyler aksine kerata çalışıyoruz o çığlık.

Eğer uygulama büyüdükçe birkaç kaynakları eklemek gerekebilir gibi Ayrıca, farklı bir tablo kaynağı olurdu.

etiketler