Bir enum ve tabloyu senkronize tutma

11

Veritabanına veri gönderecek bir program yapıyorum ve tanıdık olduğundan emin olduğum bir desene koşuyorum: Bir enum olarak hizmet veren büyük olasılıkla (çok büyük olasılıkla) sabit değerlerin kısa bir tablosu. Diyelim ki şu tablo denir Status:

  durum
  Kimlik Açıklaması
  --------------
   0 İşlenmemiş
   1 Beklemede
   2 İşlendi
   3 Hata

Programımda başka bir tablo için durum kimliği belirlemem ya da yeni bir durum kimliği içeren bir kaydı güncellemem gerekiyor.

Ben bir numaralandırma durumu kimliği sabit kod ve hiç kimse veritabanını değiştirmek umuyoruz. Ya da açıklamaya göre değerleri önceden getirebilirim ( bunun yerine bunu kodlamak ).

Bu iki numaralandırma ve tabloyu senkronize tutmak için doğru yaklaşım ne olurdu?

database enum

— MPelletier
kaynak

Neden işleri senkronize değil senkronize tutuyorsunuz? Senkronizasyon (söyle) garip!

— MrFox

1

@suslik İkisi de aynı şekilde telaffuz edilir. Senkronize Et ve Senkronize Et .

— MPelletier

1

Bir numaralandırma ve veritabanı tablosu çoğaltmadır. Veritabanı tablosu diğer uygulamalar tarafından kullanılmadığı sürece, tablodan vazgeçer ve sadece numaralandırma kullanırdım. Tablo birden fazla uygulamada kullanılacaksa, durumları çalışma zamanında veritabanından yükleyin.

— Peter Smith

Bu koşullara bağlıdır. Bu durumda, iş akışı veya görev durumu değerleri olarak, süreçler genellikle değişme eğiliminde olduğundan, bunları statik olarak daha dinamik tutmayı tercih ederdim; ve yazılım sürüm programları için banttan çıkma eğilimindedir. Öte yandan, yeni durumların getirilmesi veya mevcut durumların kaldırılması muhtemel olmayan istikrarlı bir hizmet varsa, numaralandırmayı sabitlemek / onları daha sonra nasıl kullanıldığına bağlı olarak (daha sonra kayıtların nasıl kullanıldığına bağlı olarak) zorlamak zorunda kalabilirim.

— JustinC

@PeterSmith Veritabanı bir tabloda değil, yalnızca Java numaralandırmanızdaysa kısıtlamaları zorlayamaz. Veritabanınızdaki değerleri sınırlayacaksınız, değil mi?

— David Conrad

5

Bu farklı durumların program mantığınızı etkilediğinden şüphelendiğim için, programınızdaki numaralandırmayı zor kodlayabilirim. Yeni bir statünüz varsa, programınızın bu yeni duruma nasıl tepki vermesi gerekir?

Veritabanı uygulamanızın bir parçası olduğundan, bir başkasına, bir çeşit konuşmaya başvurmadan birini etkilemenin mantıklı olacağını düşünmüyorum.

— Matthew
kaynak

Yeni durumlarla ilgili değil (hem veritabanında hem de programda kesinlikle bir değişiklik yapılmasını gerektirir), ancak Kimlik değerleri.

— MPelletier

2

Anlam değerini neden değiştirmeden değiştireceğinizi anlamıyorum. Bu tür numaralandırmalar otomatik olarak artırılmaz ve bunlar gerçekten sadece veritabanında hata ayıklayan insanlar için okunabilirlik içindir, çünkü tipik olarak uygulamanız sorgulama yapacak ve kimliğin ne olacağını zaten biliyor pendingolacaktır. Tabii ki bir Statustabloya sahip olmak size referans bütünlüğü verir, ama bu yapmaya çalıştığım noktayı belirtir.

— Matthew

Evet, fikir bu. Ama eğer kimlikleri bir yere ve başkalarına yerleştirirsem, ikisinin de haklı olduğu varsayımı üzerinde çalışıyorum . Gevşek bir bağlantı değil mi?

— MPelletier

3

Bu varsayımları her zaman yaparız, eğer bir tablo tanımı düşünürseniz, programımız bir sorgu yazarken tanımın böyle olduğunu varsayar. StatusTablo uygulamasının çalışma zamanı yoluyla dinamik düşünülmemelidir ve bu nedenle ben gibi okumak gerektiğini düşünüyorum.

— Matthew

8

Normalde uygulama başladığında (genellikle bir HashMap veya böyle bir şey) statik bir önbellek bu verileri yüklemek. Enum bir şekilde değiştirilmiş olduğu için yeniden derlemek zorunda kalmaz.

— FrustratedWithFormsDesigner
kaynak

2

Bunlar durum olduğundan, hiçbir DB değişikliğinin programınızı bozmayacağından emin olmak için uygulamaya sabit olarak kodlanmalıdır (en azından kolay değil). Bu önemlidir, çünkü eklenmesi gereken her durum ilk önce kodlanmalı ve DB'ye eklenmemelidir.

Örneğin bir rapor almanız gerektiğinde bu durum değerlerini DB'ye doğru açıklamalarıyla yazmış olmalısınız.

Genellikle DB bağlanacak ve belirli bir tabloda listelenen durumların tüm bellekte sabit kodlanmış aynı kimlik / ad değerlerine sahip olduğunu doğrulamak küçük bir kod snippet var. Eşleşmezlerse yazılımın yürütülmesini durduracağım.

İhtiyaçlarınıza bağlı olarak, biraz farklı davranışlar uygulamak isteyebilirsiniz, ancak genel olarak bu durumların yine de kodlanmış olması iyi bir fikirdir.

— Alex
kaynak

2

Projemde benzer sorunlarımız var (eski kod, yaşasın!) En büyük sorun, "numaralandırma tabloları hiçbir zaman değişmeden" ve kod kopana kadar. Yavaşça göç ettiğimi azaltmak için iki stratejim var.

Birincisi ve en iyisi, mümkün olduğunda bu değerlere doğrudan referansları ortadan kaldırmaktır. Her zaman sor, "neden doğrudan numaralandırma değerini kullanmalıyım?" Çoğu durumda, bu kodun çok fazla sabit kodlu varsayımlara sahip olduğunu veya veriler üzerinde çok fazla manipülasyon yapmaya çalıştığının bir işaretidir. Değiştirilenleri işlemek için veritabanında daha iyi ilişkiler veya daha esnek bir kod yapamayacağınızı görün.

Bu işe yaramadığında, B planına gidiyorum: kod üretimi. Tablolar nadiren değiştiğinden ve düzenli olarak yeni derlemeler yayınladığımız için, bir kod üreticisi numaralandırma tablolarını okuyabilir ve numaralandırma kodunu yazabilir. Bu dinamik olarak oluşturulan kütüphane daha sonra projede kullanılır. DB değişirse, bir sonraki derleme derlenmez, bu da gizemli çalışma zamanı hataları almaktan çok daha iyidir.

— CodexArcanum
kaynak

Bir enum referanslarını nasıl ortadan kaldırırsınız? Örneğin, bu durumda bir duruma göre sıralama veya arama yapıyorsunuz. DB sihirli değeri olması da benimle iyi oturmuyor. Arama tabloları bunun içindir.

— nportelli

Geçmişte bunun tam tersini yaptım. Enum'da her kod değişikliği olduğunda, uygulama önyüklemesinde bu değerleri Veritabanı ile senkronize eder. Burada kod gerçeğin kaynağıdır. Veritabanı bunun bir temsilidir. Tipik olarak kod kavrayamıyorum DB değerleri yok saymak ama bu şekilde, gerekirse DB otomatik olarak temizlemek için bir mekanizma olsun.

— Anshul