Bu bir DB şemasını yapılandırmanın saçma bir yolu mu yoksa tamamen bir şey mi eksik?

İlişkisel veritabanları ile oldukça fazla çalışma yaptım ve iyi şema tasarımının temel kavramlarını oldukça iyi anladığımı düşünüyorum. Geçenlerde, DB'nin yüksek ücretli bir danışman tarafından tasarlandığı bir projeyi devralmakla görevlendirildim. Bağırsaklarım içgüdüsel olursa lütfen bana bildirin - "WTF ??!?" - garantili mi, yoksa bu adam benim dünyamda kullandığı kadar dahi mi?

Söz konusu DB çalışanlardan gelen istekleri girmek için kullanılan bir içi uygulama. Sadece küçük bir bölümüne baktığımızda, kullanıcılar hakkında ve yapılan istek hakkında bilgileriniz olur. Bunu şöyle tasarlardım:

Kullanıcı tablosu:

UserID (primary Key, indexed, no dupes)
FirstName
LastName
Department

İstek tablosu

RequestID (primary Key, indexed, no dupes)
<...> various data fields containing request details
UserID -- foreign key associated with User table

Basit değil mi?

Danışman bu şekilde tasarladı (örnek verilerle):

UsersTable

UserID  FirstName   LastName
234     John        Doe
516     Jane        Doe
123     Foo         Bar

DepartmentsTable

DepartmentID   Name
1              Sales
2              HR
3              IT

UserDepartmentTable

UserDepartmentID   UserID   Department
1                  234      2
2                  516      2
3                  123      1

RequestTable

RequestID   UserID   <...>
1           516      blah
2           516      blah
3           234      blah

Veritabanının tamamı, kendi tablosunda kapsanan her veri parçası ve her şeyi birbirine bağlayan sayısal kimliklerle bu şekilde oluşturulmuştur. Görünüşe göre danışman OLAP hakkında bir şeyler okudu ve 'tamsayı arama hızını' istedi

Ayrıca tüm bu tabloları çapraz referanslamak için çok sayıda saklı yordama sahiptir.

Bu geçerli tasarım, küçük ve orta ölçekli bir SQL DB için mi?

Yorumlarınız / cevaplarınız için teşekkürler ...

Bana çok mantıklı geliyor. Bu sadece çok normalize oldu, aksi takdirde sahip olamayacağınız esnekliği sağlar. De-normalize edilmiş veriler popodaki bir acıdır.

Bir WTF'nin garanti olduğunu ya da adamın herhangi bir delice dahi tasarım yaptığını sanmıyorum - oldukça standart bir veritabanı normalleşmesi.

Departman tablosunun nedeni bölümleri ayrı bir masaya koymazsanız, "Satış", "satış", "Satışçılar", "Yelkenler" ve "Satış" bölümlerindeki kullanıcılarla uğraşmanız gerekecek olmasıdır. bunu önlemek için bir şeyler yapmazsan. Ekstra masaya sahip olmak, bunu yapmanın en iyi yolunun (bir parçası) olması.

Bir UserDepartment masası olması gerekip gerekmediği daha zor bir çağrıdır, ki bu elbette ne kararın hem çıkış hem de delilik anlamına gelmez. Bir yandan tüm masa tasarımınızın ve mantığınızın kullanıcı başına bir bölüm üstlendiği bir acıydı, sonra değişiyor, diğer yandan yıllarca ve yıllar boyunca sebepsiz yere ekstra bir katılım yapmak gerçek bir olasılık ve aynı zamanda bir acı.

Şahsen, UserDepartment tablonun büyük olasılıkla overkill olduğuna katılıyorum. Dahil olsa bile, olasılıklar zamanla insanların departman başına yalnızca bir kullanıcı olduğunu varsayan sorular yazmasıdır, bu nedenle her iki dünyanın en kötüsüyle sonuçlanır - masaya ihtiyaç duymadan hiçbir sebep olmadan ekstra bir katılım ve kullanıcı başına birden fazla departmana izin verilmediğinde, kod yine de çalışmıyor.

EDIT - Çok ya da çok ilişkinin desteklenmesi gerekip gerekmediğinin temel itici gücü, işletme kurallarının açık olması. Birden fazla bölümdeki bir kullanıcının nasıl çalıştığı hakkında hiçbir fikriniz yoksa, tabloyu eklemenin pek bir anlamı yoktur, çünkü kodunuz bir kullanıcının birden fazla bölümdeki durumlarını doğru bir şekilde işleyemez.

Her durumda, kullanıcı başına birçok bölüme izin verdiğinizi hayal edin. Daha sonra departmana bağlı olarak komisyon tayin etmek için bir iş kuralı uyguladınız. Daha sonra birden fazla bölüme izin verildi. Neyse ki, komisyon kodunuzu, bunu dikkate alan bir şekilde yazma öngörüsünüz de vardı. Ne yazık ki, her iki bölümdeki kullanıcılar için her bölümden komisyon eklediniz . Yönetim, her satış için kişilerin rolüne dayanmanızı istedi. Peki, masayı önceden almak ne kadar iyiydi? Peki ya hiç ihtiyacın olmayan "sadece durumunda" olan diğer masalardan ne haber?

SONRA DÜZENLEME - Danışmanın tüm bu aracı tabloları eklemek istemiş olabileceği bir diğer sebep, bu takip eden soruda ele alınmaktadır; bir veri tabanını yeniden düzenlemenin neden yeniden doğrulama kodundan daha zor olduğunu ve bu da sizi doğru yönde yönlendirmeye meyilli olan bazı nedenler vermiştir. "İhtiyacınız olan tüm tabloları yerleştirin" yaklaşımı.

Gereklilik kullanıcı başına birden fazla bölüme sahipse, bu tasarım mantıklı olur. Buradaki tek yakınma, gerekli UserDepartmentTableolmayan bir yedek anahtara sahip olmaktır UserDepartmentID(sadece UserIdve DepartmentIdbirleşik birincil anahtar yapın).

Bir kullanıcı yalnızca tek bir bölüme aitse, tasarımınız mantıklı olur (bölüm arama tablosu hala iyi bir şey olsa da).

Sorunuzda bazı gereksinimler net değil. Doğru cevap, müşterinizin ne istediğine bağlıdır.

0-Bir kullanıcı ile çalışan arasındaki fark nedir?

1-Bir çalışanı varsaymak = kullanıcı, ya bir çalışan departmanları değiştirirse?

2-Bir grup çalışan 1 talepte bulunabilir mi?

3-Bir çalışan birden fazla bölüme ait olabilir mi? Peki ya CEO

4-Talepte bulunabilecek bir çalışan grubu var mı?

5-Bir çalışan kaydı silindiğinde talebe ne olur?

6-Bir isteği silebilir misiniz? İstek silindiğinde ne olur (çalışan kaydını RI ile silmediğinizden emin olun)

7-Çalışan “aynı” talebi birden fazla kez yapabilir (“aynı” kelimesini tanımlayın)

8-Çalışanlar için şirketten ayrıldıklarında talepler nasıl ele alınır (isteklerini iptal eder veya istekleri siler?)

Daha fazla soru olabilir, ancak amacım, çözümün tam gereksinimlere ve proje kapsamına bağlı olduğudur. Bu belirlendikten sonra şema doğrudan türetilebilir. Buna göre sunulan her iki çözüm de doğru olabilir.

Açık bir şekilde yüksek ücretli danışmanınızın yaptığı şekilde bir birleştirme masası kullanmanın bazı avantajlarından bahseden birkaç noktadan oluşan bir form eklemek istiyorum.

• Düzgün bir şekilde dizine eklenir (örneğin, UserDepartmentTable iki yabancı anahtarı dizine eklerse), yabancı anahtarların benzersiz olmaması nedeniyle, böyle bir birleştirme tablasında yalnızca küçük bir performans kaybı olur. Yabancı anahtarların benzersiz olmaları garanti edilirse, tanıdığım küçük veritabanı teorisine UserDepartmentTable.Departmentgöre, Usertablodaki diğer sütunları aramaktan daha zor değildir .
• Birleştirme tablosu, kullanıcı ile departman arasındaki ilişki hakkındaki diğer bilgileri ayarlama konusunda size daha fazla esneklik sağlar (örneğin, yaratılıştaki zaman damgaları).
• Birleştirme tablosu, ilişkilendirmeyi oldukça kolay bir şekilde "sürmenize" olanak tanır (örneğin, kullanıcı bölümleri değiştirdiğinde, bazı dizin boolean bayrağını UserDepartmentTable.Activeyanlışlamak ve etkin olan yeni bir ilişkilendirme oluşturmak gibi) tetikler . Aynı zamanda iki masalı modelle (sadece Kullanıcı ve Departman) departman birlikteliğine sahip olmak da mümkündür, ancak daha zordur ve birincil anahtarların kopyalanmasını önlemek için en az bir sütun daha eklemek veya veritabanı akrobasi yapmak gerekir.
• Kolayca bire çok ya da çoktan bire ya da çoktan çok dernek atamanıza izin verir.

Olduğu gibi, yüksek ücretli danışmanınızın yaptığı şeyi yapmamak için birkaç neden var.

• Yukarıdaki faydaların tümü, gelecekteki ihtiyaçların beklenenleri olup, bugün için işleri karmaşık hale getirmektedir. YAGNI uyumlu değil. İki tablo modelinizden bir kat tablo modeline geçiş yapan bir geçişi yazmak daha sonra büyük bir zorluktur. İşletmenizin ihtiyacı ortaya çıktığında bunu yapabilirsiniz. Bundan önce yapmak kafa karıştırıcı olabilir.
• Diğer geliştiricilerin kafasını karıştırır. Evet, durumunuzun bir web geliştiricisinin (danışmanların kararlarını gözden geçirdiğiniz yerde) bir katılım tablosunu anlamak ve tanımak olacağını söyleyebilirim, ancak hala gerekenden daha karmaşık ve iş ihtiyacının eksikliğini göz önünde bulundurarak, karışıklığa neden olur.

İhtiyaç duyduğum bilginin tam yapısı olmadan söyleyemem korkunç mu değil mi. Ancak en azından gösterilen parça "WTF" tasarımlarından değildir. Sadece 3. Normal Veri Biçimi Formu olarak görünüyor (teorik olarak ayrıca 4. ve 5. sıradayız)

Kullanıcı konuşması için bazı konuşmalarda, gösterilen parçadaki "doğal" ve "yapay" anahtarların iki okulu arasında yer verilebilir. Daha fazlası değil, gördüğüm kadarıyla

Normalleştirme bir sürü sebebi iyi DB-geliştirici / tasarımcı kuraldır * de * normalleştirmeler hız kazanmak çoğunlukla için gelişmelerin ortasında bazen kullanılmaktadır