Yeni özellikleri işlemek için veritabanlarını yeniden düzenleme veya yükseltme


9

Bir veritabanı şeması sorusuna verilen çeşitli yanıtlar , mevcut gereksinimlerin bir parçası olmayan bir özellik için veritabanını normalleştirmek üzere ek bir tablo önerdi (Çalışanlar / kullanıcılar ve farklı departmanlar arasında çoktan çoğa ilişki sağlamak için bir Kullanıcı Bölümü tablosu) ait olmak.).

Normalleşmeye karşı değil. Veritabanı tasarımı söz konusu olduğunda, gelecekte birilerinin isteyeceğinden emin oldukları özellikleri eklemek için güçlü bir itme var gibi görünüyor. Aşırı mühendisliğe bir güvence sağlamak için özellikleri karşılamak için veritabanına tablo / alan eklemek çok zor mu? Gerekirse uygulamanın geri kalanı gibi yeniden düzenlenemez veya yükseltilmez mi? İşleri yeniden yapmak asla eğlenceli değildir, ancak verileri bir tablodan yeni bir tabloya taşımak yapılabilir. Bu düşünme çizgisinin nerede biteceğinden emin değilim.

Düzenleme: Bu kadar çok bir kaçınma var, ben kaç proje büyük bir veritabanı değişikliği gerektiren veya yeni bir tablo yerine DepartmentID2 alan eklemek gibi alınan normalize olmayan yaklaşımlar eklemek bir özellik eklemiyorum. Bir çalışan için birden fazla departman ihtiyacı, ortak bir alan adı sorunudur. Sadece çoktan çoğa ilişkilerle dolu birçok veritabanı şemasını fark etmedim.


1
+1 Bunu sorduğun için teşekkürler. Orijinal sorumun yanıtlarını okurken çok şey öğrendim ve bu da anlayışlı bir konu.
Jim

Yanıtlar:


3

Veritabanı yeniden düzenleme hakkında yazılmış bir kitap var. Kod yeniden düzenleme gibi, veritabanı yeniden düzenleme için standart yollar vardır. Tek fark, kod yeniden düzenleme yaparken, nesnenin / kodun durumunu göz önünde bulundurmanıza gerek yoktur, veritabanlarında veriyi dikkate almanız gerekir, çünkü veri kaybetmek kullanıcılar için (veya aslında herkes için) ).

Veritabanı yeniden düzenleme hakkında daha fazla bilgiyi buradan edinebilirsiniz .


Bu site ilk etapta soruyu
soran şeydir

14

Kodu yeniden düzenlemek kolaydır - kodu değiştirmeniz ve regresyon testlerinizi yapmanız yeterlidir.

Veritabanlarını yeniden düzenlemek zordur - verileri (potansiyel olarak büyük miktarda) taşımanız, hiçbirinin düşmediğinden emin olmanız, yeni şemada kısıtlamaların korunmasını sağlamanız gerekir. Ve veriler üzerinde denetim gereksinimleriniz varsa, neden farklı şekilde organize edildiğini açıklayabilmeniz ve yeniden odaklanma öncesi verileri ile yeniden gönderme sonrası verileriyle eşleştirebilmeniz gerekir. Ayrıca, eski yedeklemelerinizin hiçbiri yeni bir şema ile eşleşmeyecektir, bu da başka bir risktir.

Korkunç şeyler.


Veritabanı testleri farklı olmamalıdır. Tüm değişiklikler bir denetim gerektirir ve yedeklemeleri etkiler. Bu ihtiyacı fark etmeden önce ne kadar veri toplayacaksınız? Verileri dönüştürdüyseniz, bu özellik daha da belirgin olacaktır.
JeffO

8
@Mathew Flynn için +1. Bu ihtiyacı fark etmeden önce ne kadar veri toplayacaksınız? MİLYON satır. Başka bir sorun, birçok kez SİZİN veritabanını kullanan tek şey değildir. Veritabanının üzerinde çalışan birçok uygulama olabilir ve bunların varlığını bile bilmiyor olabilirsiniz (örneğin, vahşi "BI" uygulamaları). Veritabanı şemaları değişiklikler şunlardır korkutucu.
Angelo

2
Bazen milyarlarca satır
HLGEM

1
Milyarlarca satırla uğraşıyorsanız, onları nasıl taşıyacağınızı daha iyi bilirsiniz
JeffO

3

Çok fazla zaman geçirmek ve biraz zaman harcamak arasında gelecekte önemli miktarda zaman kazanmak için yeterli özellik eklemek için ince bir çizgi var.


1
Bu tartışmayı izole edilmiş bir örnek için yapabilirsiniz, ancak zamanın 'bitleri' ne zaman çok fazla eklenir?
JeffO

Kendi deneyimlerime göre, aslında projelerin büyük çoğunluğu için durum böyle. Ama aynı zamanda deneyim ile geliyor ve son derece öznel olduğunu tahmin ediyorum :) Birisi size tam bir tarif verebilir (böylece 'ince çizgi') şaşırırdım.
0x4B1D

@ Jeff O: 'Bit' olmayacak. Sistemin hem başlangıçta öngörülen zaman dilimini hem de istihdamınızı geride bırakabileceğinden, sertleştirme için% 10 veya% 20 geliştirme süresi yatırımı gereklidir.
rwong

3

Teori şu ki, 2 tablo arasında çok sayıda ilişkiyi desteklemek için bir bağlantı tablosu eklerseniz, o zaman verilerde gerçekten çok fazla bir ilişki olsa bile, herkes SQL'i öyle bir şekilde yazacaktır ki birçok kişiye desteklenir her şey "sadece çalışır".

Uygulamada her zaman bunun doğru olduğunu bulmadım, ancak SQL'in çok daha fazlasını desteklemek için olması gerekene daha yakın olduğunu varsayalım.

Ama sorunuza özel olarak almak için, aslında orada olduğunu birçok çoğa 1 çoğa bir ilişki dönüştürme ağrı adil bir miktar. Nedeni, SQL olmasıdır değil nesneler olduğunu kapsülleme hedefleri aynı çeşit ile tasarlanmış ve insanların iş katmanında bir nesne için görünürlüğe sahip olan rahat olacağından daha çok sorgular veritabanı katmanında daha tabloları kullanın.

Bu nedenle, çoktan çoka ilişkide bir değişiklik, orijinal 2 tabloları içeren her sorguyu etkileyecektir, genellikle iş katmanında gerçekleşenden çok daha geniş basamaklı bir etki. Bu yüzden insanlar bunun olmasını önlemek için önemli uzunluklara gidiyorlar.

IMHO ilişkisel cebiri belirtmek için SQL'den daha iyi bir dilimiz olsaydı buna gerek kalmazdı. Sorgudaki her tablo için görünmezliğe ihtiyaç duymayan nesnelere göre bir SQL sorgusu parça parça oluşturmak mümkün olsaydı bu olmazdı. LINQ (SQL'e veya Varlıklara) gibi şeyler bunu çözmeye çalışır, ancak çok karmaşık bir çözümdür ve optimize etmek zordur (ve LINQ'nun söz konusu olduğu ve her seferinde kollektif bir ininin yükseldiği DBA kullanıcı gruplarına gittim). Birinci sınıf ilişkisel cebir işlevleriyle evrensel olarak desteklenen bir veritabanı dili hayal ediyorum ...

Bu arada, evet, 1'den çoğa ve çoğundan çoğa refactor olabilirsiniz, ancak çok fazla iş olabilir.


Her ilişkiyi çoktan çoğa çevirmeyecek misin?
JeffO

@Jeff O - Sorunuzu anladığımdan emin değilim. Şüphe duyduğunuzda, orijinal sorunuzun çeşitli cevaplarında bahsedilen tuzaklardan kaçınmak için çoktan çoğa modelim. Neredeyse tüm ilişkileri çoktan çoğa yapan veritabanlarını koruduktan sonra biraz daha ihtiyatlı büyüdüm, çünkü ilişkilerin 1'den çoğa görünmesini sağlayan görünümler oluşturmak gibi şeyler yapmışlardı (bu, pratikte, hepsi). Böylece her iki dünyanın da en kötüsü vardı. Bunu kendi tasarımlarımda hiç yaşamadım, ama orada bir eğitici hikaye olarak var.
psr

3

Genellikle bunu PHB'lere açıklarım - kod duvarlar ve çatı, veritabanı temeldir.

Duvarların hareket ettirilmesi ve çatının değiştirilmesi yapılabilir. Temelin değişmesi için çok fazla kazma ve duvarları ve çatıyı yeniden inşa etmek gerekir.

Deneyimsiz geliştiricilerin (ve kolej profesörlerinin) söylediği şey, "mühendislik üzerine" tecrübeli geliştiricilerin "gelecekteki prova" olarak adlandırdığı şeydir. Spesifikasyonun söylediklerine rağmen, ALM sırasında neyin değişeceğini veya performans sorunlarının nerede ortaya çıkacağını biliyorsunuz, böylece tablo yapınızı en doğru şekilde almak istiyorsunuz.

Güncelleme komut dosyalarının müşteri sunucularına dağıtılması önemsiz bir projedir ve her müşterinin DBA'sı her şeyi üç kez kontrol etmek istiyor. Bazı ekstra sütunlar ve tablolar sonuçta o kadar da kötü değil.


1

Bir ilişki bire birdir ama eğer genel kural olabilir gelecekte çok çok sonra birçok bir sayıda yapmak olacak.

Çalışan / bölüm klasik bir örnektir. En küçük şirketler bu etkin şekilde birçok ilişki bir tanesidir çoğu zaman . Bununla birlikte, neredeyse her zaman çok sayıda hale geldiği bir durum vardır - mühendislerinizden biri yönetime geçer, ancak mühendislik sırasında geliştirdiği bir ürünü desteklemekten hala sorumludur veya satış elemanlarınızdan biri ürün geliştirme, ancak önemli bir müşteriyle yakın ilişkisi olduğu için hala bu müşteri için satış elemanıdır.

Birinden çoğa çok kişi olarak uygulanırsa çok daha pahalı değildir - ancak çok sayıda kişiyi desteklemek için bir veritabanını ve uygulamayı yeniden düzenlemek pahalı ve zorluklarla doludur.


Müşterinin ihtiyacı öngörmediği birçok olgun alan (İK gibi) olduğunu kabul ediyorum, ancak bunun gerçekleşmesi gerektiğinin farkındasınız.
JeffO

0

Yazılım tasarımına (ve muhtemelen başka birçok şeye) bakmanın iki yolu vardır - Taktik bir görüş veya stratejik bir görüş. Her birinin kendi avantajı ve dezavantajları vardır.

OO yazılım modifikasyonları bile hala bir acıdır, sadece kodlama kısmı zordur, aynı zamanda bir şikayet ortamlarında (mevcut teknoloji durumu göz önüne alındığında) üretimde bir değişikliği teşvik etme süreci olması gereken büyük sistemler için gerçek değildir. 7/24 çalışıyor.

Takip ettiğim benim "diyen insan ilkesini Mümkün olduğunda, tasarım paylaşılan yazılım eserler stratejik bazı yolla YAGNI ilkesine aykırı gibi bu gelebilir, ancak bu benim görüşüm -". Bu yaklaşım, karmaşıklığın ve kaynakların maliyeti üzerinde daha az yeniden çalışmayı garanti eder.

Sizin durumunuzda, yeni bir birleşim tablosu eklemek için gereken aktiviteler şunları içerir: tasarım, tasarım onayı, şemayı değiştirme, 3 tablo için CRUD için birkaç yöntemi yeniden yazma (bazı okumalar hariç), dizin oluşturma, için GUI oluşturma Yeni tablo için CRUD, kullanıcının oluştururken PK'ları seçmesine izin vermek, yeni tablonun güncellenmesi, vb. Oh, ve bu arada ünite testini, kullanıcı kabul testini, sistem testini ve üretim tanıtımını unutmayın.

Bu yeterli değilse, gerçek kabus bilgi kaybından gelir. Başlangıçta kavşak tablonuz yoksa ve bir çalışan ile bir departman arasındaki ilişkinin / ayrımın gerçekleştiği tarihleri ​​yakalamaya karar verdiyseniz, kavşak tablosundaki tarihi otomatik olarak dolduramazsınız. Bunları manuel olarak girmelisiniz (veriye sahipseniz).

Bu yüzden, bunu en baştan öngörmek daha iyidir.


Her şeyi en baştan öngörmek daha iyidir.
JeffO

0

Matthew'un dediği gibi, veri yönetiminin de dikkate alınması gerektiği için veritabanlarını yeniden düzenleme / değiştirme genellikle yazılıma göre daha fazla işin içine girer. Örneğin, 'DB API' - sprocs / views vb. Kullanarak uygun bir veritabanı birimi testleri paketine sahip olduğunuzdan emin olun, istemci uygulamalarını temel şemanızdan ayırın.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.