Kayıt durumları nasıl saklanır (beklemede, tamamlandı, taslak, iptal edildi…)

Oldukça fazla uygulama tablolarında kayıtların 'tamamlandı', 'taslak', 'iptal edildi' gibi bir duruma sahip olmasını gerektirir. Bu durumları depolamanın en iyi yolu nedir? Burada ne elde etmek göstermek için * çok kısa) bir örnektir.

Basit bir Blog uygulamam var ve her gönderinin bir durumu var: yayınlandı, taslak veya beklemede.

Ben bunu görmek veritabanında bu modellemek için 2 yolu vardır.

1. Post tablosunda durum metnini içeren bir metin alanı vardır.
2. Post tablosunda, PostStatus tablosundaki bir kaydın kimliğini içeren bir durum alanı vardır

Buradaki Blog örneği çok basit bir örnektir. Bir numaralandırma (destekleniyorsa) yeterli olabilir. Ancak, durumların listesinin herhangi bir zamanda değişebileceğini dikkate almak için soruya verilen yanıtları istiyorum, bu yüzden daha fazla eklenebilir veya kaldırılabilir.

Herkes her birinin avantajlarını / dezavantajlarını açıklayabilir mi?

Şerefe!

Bu benim ilk tercihim, başka bir tablo kullanmak ve durumu normalleştirme için daha iyi olarak aramak daha iyi ve her zaman normalleştirmenin veritabanları için iyi olduğu öğretildi

Durumun başka bir tabloya indeks olarak kaydedilmesi gereksiz bir komplikasyondur. Durumu doğrudan tabloda okunabilir bir şekilde saklayın. Uygulama kodunda sabitleri veya numaralandırma türünü kullanın. Bu, daha basit uygulama koduyla sonuçlanacak ve veri katmanında hata ayıklamayı kolaylaştıracaktır.

Bu verileri denormalize etmez, sadece gösterimi değiştirir. Veritabanı numaralandırmaları doğrudan destekliyorsa, bunu kullanın. Aksi takdirde sütun değerlerini kısıtlamak için bir kısıt kullanın. Her iki şekilde de bir kısıtlamanız olacaktır: sütun değerleri üzerinde doğrudan bir sınırlama veya bir yabancı anahtar kısıtlaması.

Evet, durumu farklı kullanıcılara farklı göstermeniz gerekebilir. Bu, kalıcılık katmanında değil, sunum katmanında çözülmesi gereken bir sunum problemidir.

Durum metnini saklamak IMO iyi bir fikir değildir, çünkü birisi bunun yerine "tamamlandı" olarak adlandırılması gerektiğine karar verebilir ve veritabanınızı güncellemeniz, birisi metni kodladıysa programa bakmanız gerekir.

Birçok programda gördüklerim ya sayısal bir kod (1 = yeni, 2 = taslak, 3 = doğrulamada, 4 = tamamlandı, 99 = iptal edildi) ya da kısa bir alfasayısal kod ("YENİ", "DRA", "INV "," COM "," CAN "). Daha sonra kodu (programda veya veritabanında) daha insan tarafından okunabilir hale getirir, bu genellikle iyi bir şeydir. Diğer yandan, sayısal kodlar "büyüktür" veya "küçüktür" karşılaştırmaları yapmayı kolaylaştırır, örneğin

select * from myrecords where status < Status.Complete;

İlişkisel veritabanlarının üç kuralı:

1. Normale
2. Normale
3. Normale

Yani sorunuz kendi kendine cevap veriyor. Durumu kendi tablosunun içinde tutun ve kimliğiniz olarak GUID / UUID'leri kullanın . Endeksli GUIDS çok hızlıdır ve artan sayılara özgü problemleri çözer. Bir kimlik ile kimliği kullanarak tüm tamamlanmış gönderiler için DB isteyin gibi serin şeyler yapabilirsiniz ve ilişkisel db paradigması içinde çalıştığınız için, çok hızlı. Sadece bir alanınız varsa, DB her satırda döngü yapmalı ve bir metin karşılaştırması yapmalıdır, belki de munging ile ve bu çok yavaştır.

Gönderi durumu adları değişebilir, gönderi durumu hakkında daha fazla bilgi tabloya girebilir, normalleşirseniz her şey çalışır .

Örneğin, ek cephane olarak karşılaştırma cephanesi bahsine izin veren durum seviyeleri ekleyebilirsiniz. Ancak, konumlandırma anahtarına bağlı değildir ve DB bütünlüğüne zarar vermeden durum seviyesinin yeniden düzenlenmesine izin verir. Ayrıca otomatik düzeylendirme anahtarıyla ilişkili düzeyiniz varsa, ek düzeyler de ekleyebilirsiniz.

Evet, PostStatus tablosuna sahip olan 2. seçeneğe gitmelisiniz.

Diğer cevaplarda belirtilen tüm avantajların dışında.

Durumların eklenmesi veya kaldırılması gerektiğini göz önünde bulundurarak, PostStatus tablosunda "etkin" bir sütununuz olabilir, bu nedenle durum kaldırılırsa "etkin" sütunu "N" olarak işaretleyin, böylece durum ekleme veya kaldırma ve ayrıca mevcut kayıtlar sorunsuz kalır.

Tam normalleştirme için, bir varlığın durumundaki bir değişikliğin aslında ayrı bir varlıkta, örneğin 'statusChange' olarak modellenmiş olduğu anlayışlı cevaplara eklemek istiyorum.

StatusChange varlığıyla ekstra bir birleşim yapmanız gerekir, ancak değişikliği yapan aktör, değişikliğin neden oluştuğuna dair olası yorumlar ve statusChange'in gerçekleştirildiği tarih ve hatta muhtemelen etkili olur.

Kayıt tablosunda durum için metin kullanmak muhtemelen iyi bir fikir olmayabilir, çünkü bu değişebilir ve ekleme / güncelleme üzerinde herhangi bir veri bütünlüğü kontrolü yapmak zor olacaktır. Numaralandırma veri türüne sahip bir DBMS kullanıyorsanız, bunun yerine bunu kullanabilirsiniz (muhtemelen performanstan ödün verilmeyecektir ... bağlı olarak).

Durumunuzda herhangi bir meta veri gerekiyorsa (açıklama, tarafından oluşturulmuş açıklama, kolay ad, ...) durumları ayrı bir tabloda depolamanız ve kayıt tablonuzda bir durum anahtarına sahip olmanız gerekir (yabancı anahtar kullandığınızdan emin olun). Kimlik mutlaka bir sayı olmak zorunda değildir, yalnızca durum tablosunun PK'sidir. Ayrıca, durumlar kendi tablolarındaysa bunları varsa kayıt türleriyle (tablolar) paylaşabilirsiniz. Durum tablosuna bir JOIN ile performans sorunları hakkında endişe olmaz.

Ne yaparsanız yapın, sihirli durumlardan kaçının (aktif için 1, silinmiş için 2, ...). Bu, her zaman yeterince geniş bir zaman çizelgesinde kaybolma eğilimi gösteren dokümantasyon ve geleneğe dayanır. Nümerik kimlikleri kullanıyorsanız, db'nizin herhangi bir yerinde bir metin ilişkilendirmesi olduğundan emin olun.

Veritabanı tasarımının amacına bağlıdır.

Veritabanını uygulamayı destekleyecek şekilde tasarlarsanız (yani nesneler (kod) her şeyin efendisiyse) bir numaralandırma (veya desteklemeyen sınıflar için bir psuedo numaralandırma) kullanarak ve numaralandırma adını saklamak bir iyi bir fikir, çünkü hala numaralandırma aracılığıyla izin verilen değerleri kontrol ve ayrıca ham verileri görüntülemek zorunda kaldığınızda tabloyu okumak için biraz daha kolay hale getirir (kod gerçekten tüm kurallar bu sık sık değil). Ancak numaralandırma işaretlenirse. Sonra genellikle enum değerini (tamsayı) saklarım.

Durum çok önemlidir, posta bilgisini her aldığınızda durumunu almanız gerekir veya yayınları duruma göre filtrelemek istersiniz. Başka bir tabloda durumunuz varsa, bu bilgiyi almak için birleştirme yapmanız gerekir ve böylece performans tehlikeye girer. Kesinlikle aynı tabloda durumunuz olmalıdır. Ve üzerine bir indeks koy! Hala tamsayı durum veya belki numaralandırma alanı olarak kullanabilirsiniz.

Doğru çözüm, CQRS ile bir Etkinlik Deposu / Kaynağı veya bir blok zinciri kullanmaktır. RDB'deki olayları yakalamadaki sorun, RDB'nin tek bir olayın anlık görüntüsünü zamanında depolaması ve "Durumlar / Durumlar" gibi şeylerin zamanla gelişen mutasyonlar dizisidir.