İyi tasarlanmış bir veritabanının üstüne iyi kod yazmak için herhangi bir umut var mı?

İşte benim durumum. Son zamanlarda miras aldığım birkaç programdan biri arka uçta korkunç bir veritabanı ile oluşturuldu. Saygın yaratıcıları görünüşte ilişkisel kavramları takdir etmediler. Her istemci için benzersiz bir istemci kimliği olarak adlandırılan bir tablo. Seksen üç şifreli alan. Kod, düzinelerce sıralı satır içi SQL deyimi ile yordamsaldır.

Aynı veritabanında çalışan önemli bir yan uygulama sağlanmadığımız için, onu sıfırdan yeniden oluşturmakla görevlendirildim. Tek bir geliştiriciyim, zamanımın en az yarısı operasyonlar tarafından alındığı için birincil sorumluluğum bile değil. Şu andan itibaren 30 gün boyunca kaçınılmaz bir son teslim tarihi var.

Deneyimime rağmen, bu veritabanını ve mevcut uygulamayı onlardan çok daha iyi tasarlayabileceğime eminim, ancak veritabanını değiştirmenin, mevcut uygulamayı ayarlamam ve emin olmadığım için gerçekten gerçekçi olduğunu düşünmüyorum ' t Ek uygulamayı hızlı bir şekilde oluşturmaya ihtiyaç duyarken herhangi bir şeyi kırmayın.

Diyelim ki korkunç veri tabanına takıldım. Böylesine kötü bir yapı ile çalışmaya ihtiyaç duyduğumda, ona uygun yazdığım herhangi bir şey, bir şey tamamen bozulana veya yeni işlevsellik gerekene kadar rafa kaldırılacak teknik borç yığınına katkıda bulunur mu? Umarım işlevsel bir uygulamanın yanı sıra bu duruma nasıl yaklaşabilir ve ondan iyi bir şey alabilir miyim?

edit: kimse ilgilenirse, biz bu korkunç veritabanı ve üzerinde koştu uygulama hurdaya sona erdi. Nihayetinde her ikisi de bize düşen ve hiçbir şey yapmayan iki farklı müteahhit için yan başvuru (bunu kurmakla ilgilenmedim) yaratıldık. Bugün hala kullanımda olan üç gün içinde bir düzeltmenin korkunç, kısmen işlevsel bir hackini atlatmak zorunda kaldım.

Umut var, ama özellikle kimse veritabanı tasarımının korkunç olduğunu fark etmezse, yokuş yukarı bir savaş. Nastiness'i soyutlama katmanlarıyla soyutlamaya çalışabilirsiniz, ancak şansınız savaşa değmeyecektir.

Benim tavsiyem, uygulamanın kendisinin temiz ve düzgün bir şekilde tasarlanacağı veritabanı üzerinde yeterli soyutlamalar yaratmak olacaktır; Bu arada o takdirde hiç veritabanını çözebilirsiniz, uygulama o veritabanı tasarlanmıştır nasıl umursamıyor çünkü etkilenmeyecektir.

Bu, normalde yerinde olan ve çoğu zaman sıfır düşünce ile tasarlanmış bir veritabanı ile uğraşırken kullandığım yaklaşımdır. Depo veya ağ geçidiyle konuşmak için bazı hizmet katmanlarına sahip Havuz veya Ağ Geçidi kalıplarının birkaç seçenek uygulaması, zayıf tasarımı karantinaya almaya yardımcı olacaktır.

Tüm DB öğelerini işleyen bir arayüz katmanı oluşturun ve ardından uygulamanızı bununla arayüze yazın. Veritabanının "sabit" olması durumunda "arayüzünüzü" değiştirmeniz / güncellemeniz yeterlidir. Bu yaklaşım, kötü bir veritabanı veya başka uygulamaları besleyen ve karıştırılamayan bir veritabanı ile uğraşırken bana tonlarca zaman kazandırdı.

Ah ... Bir kabus karmaşasını miras aldınız, kuruluşunuz için kullanılabilir hale getirmek için 30 gününüz var ve günün yarısı operasyon görevlerine mi alındı?

Eminim refactor olabilir ama kesinlikle bu süre içinde değil.

Sorunuzu cevaplamak için böyle bir tasarıma gerçekten iyi bir kod yazabileceğinizi sanmıyorum. Teknik borç zaten çok fazla. Ben olsaydım, yapabileceğim özellikleri hacklerdim ve daha fazla zamanınız olduğunda ve ekibinizdeki kişilerin daha iyi hitap etmesi için daha sonraki bir tarihte tam bir yeniden düzenleme için baskı yaparım.

Yeniden düzenleme için itmeye dikkat edin. Bazen daha yüksek bir seviye, bir ürün kaynak kodu ve mülkiyet hakları satın alma kararı alır ve paralarını tamamen boşa harcadıklarını düşünmek istemezler. Benim yaptığım bir işte durum böyleydi. Ne yazık ki yöneticiler böyle yazılım satın alma konusunda kararlar alırlar ve ne satın aldıklarını değerlendirmek ve sürdürülebilir olup olmadığını ve büyük miktarda teknik borcu olup olmadığını görmek için hiçbir zaman teknik katılım elde etmezler. Bu durumda, kötü karar siyasi bir karardır ve yeniden düzenleme için zorlamak işinizi tehlikeye atabilir.

Veritabanları diğer kodlar gibi yeniden düzenlenebilir. Başka hiçbir şeyin bozulmadığından emin olmak için test yazmanız ve yazmanız gereken koddan etkilenen kısmı düzeltin. Diğer tüm yeniden düzenleme işlemleri gibi her seferinde küçük bir parça yapın. Dağınıklığı temizlemeye başlamanıza yardımcı olabilecek veritabanı yeniden düzenleme konusunda iyi bir kitap var. http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1

Başkaları da var, ama şahsen bu teknikteki teknikleri okudum ve çalıştım.

Ve sizin için daha kolay bir yapıya dönüştürmek için kötü dönüşümsel iş yapmak için görünümler oluşturarak veritabanını sorgulamak için gereken şekilde yeniden yapılandırabilirsiniz unutmayın.

Paranızın karşılığını en iyi şekilde almak için, "ilişkiselliğin" bir kısmını geri yüklemek ve daha anlamlı sütun adları sağlamak için güncellenebilir görünümler oluşturun.

Bir olasılık, nasıl istediğinizi yapılandırılmış (en azından ona daha yakın) ikinci bir veritabanı oluşturmak ve iki veritabanı arasında çoğaltma kurmak olabilir. Daha sonra kodunuzu yeni veritabanına yazabilir ve daha fazla zamanınız olduğunda ilgilenmek için mevcut veritabanını (ve uygulamayı) olduğu gibi bırakabilirsiniz.

Doğrusu, hala çok açık ~ 15 günlük işte bunu yapıp yapamayacağınız soruya . Özellikle, iki yönlü çoğaltmaya (yani, yeni uygulamanız veriyi gerçekten güncelleyecek) veya yalnızca tek bir yola (yeni uygulamanız yalnızca kullanıcıların verileri görüntülemesine izin verir) ihtiyacınız olduğuna bağlıdır. İkinci durum (elbette) başa çıkmak için önemli ölçüde daha kolaydır.

İki yönlü çoğaltmaya ihtiyacınız varsa, bu işi yapmak için yeterli zamanın olmamasıdır. Özellikle, yapının önemli ölçüde dönüştürülmesini içeren iki yönlü çoğaltma asla önemsiz değildir ve mevcut araçlar genellikle onu oldukça zayıf bir şekilde destekler (örneğin, her iki yönde tüm veri dönüşümleri için tüm SQL'i el ile yazmak zorunda kalmak).

Sadece tek yönlüye ihtiyacınız varsa, mümkün olabileceği sınırda olabilir . Aynı zamanda biraz para harcamaya izin verip vermemenize de bağlı olacaktır - muhtemelen biraz daha hızlı ve daha kolay hale getirecek tam olarak bu tür bir görev için tasarlanmış birkaç veri ambarı uygulaması vardır. yönetmek için - ama çoğu ucuz değil .