Yuvalanmış görünüm iyi bir veritabanı tasarımı mıdır?

Uzun zaman önce bir yerlerde okudum. Kitap, SQL Server'da iç içe geçmiş bir görünüme sahip olmamıza izin vermememiz gerektiğini belirtir. Bunu yapamamamızın nedeninden emin değilim, aksi halde yanlış ifadeyi hatırlayabilirim.

Öğrenciler

SELECT studentID, first_name, last_name, SchoolID, ... FROM students

CREATE VIEW vw_eligible_student
AS 
SELECT * FROM students
WHERE enroll_this_year = 1

Öğretmenler

SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers

CREATE VIEW vw_eligible_teacher
AS 
SELECT * FROM teachers
WHERE HasCert = 1 AND enroll_this_year = 1

Okullar

CREATE VIEW vw_eligible_school
AS 
SELECT TOP 100 PERCENT SchoolID, school_name 

FROM schools sh 
JOIN
     vw_eligible_student s 
     ON s.SchoolID = sh.SchoolID
JOIN 
     vw_eligible_teacher t
     ON s.SchoolID = t.SchoolID

İş yerimde, kurum içi veritabanı uygulamamızdan birini araştırdım. Birbirlerine iki ya da üç kat istifinin geldiğini buldum. Bu bana geçmişte ne okuduğumu hatırlattı. Herhangi biri bunu açıklamaya yardımcı olabilir mi?

Bunu yapmak uygun değilse, sadece SQL Server ile sınırlı olduğunu veya genel olarak veritabanı tasarımı için olduğunu bilmek istiyorum.

Ek Bilgi: Şirketimden bir örnek güncelledim. Çok fazla teknik olmadan (bu örnekte çok fazla sütun var) daha genel olması için biraz değişiyorum. Çoğunlukla kullandığımız iç içe geçmiş görünüm, soyut veya toplu görünüme dayanır. Örneğin, yüzlerce sütunlu geniş bir öğrenci masamız var. Diyelim, Eligible Student Viewbu yıl kayıt yaptıran öğrencilere dayanıyor. Ve uygun öğrenci görüşü, saklı yordamlar gibi başka yerlerde de kullanılabilir.

Platformdan bağımsız olarak, aşağıdaki açıklamalar geçerlidir.

(-) İç içe görünümler:

• anlamak ve hata ayıklamak zordur

  Örneğin, bu görünüm sütunu hangi tablo sütununa atıfta bulunur? Lemme, 4 görünüm seviyesi tanımlaması yaptı ...

• sorgu en iyi duruma getiricisi için en verimli sorgu planı ile gelmesini zorlaştırmak

  Bkz bu , bu , bu ve bu anekdot kanıtlar. İle karşılaştırın bu bir derleme maliyet olmadan iyileştirici doğru açmak iç içe görüşlerine akıllı yeterli sıklıkta olduğunu hangi gösterir ve optimal bir planı seçin değil.

  Görünüm sorgusunu taban tablolarıyla yazılmış bir eşdeğerle karşılaştırarak performans maliyetini ölçebilirsiniz.

(+) Öte yandan, iç içe görünümler şunları yapmanıza izin verir:

• toplamaları veya iş kurallarını merkezileştirme ve yeniden kullanma
• temel yapınızı uzaklaştırın (örneğin, diğer veritabanı geliştiricilerinden)

Nadiren gerekli olduklarını öğrendim.

Örnekte, belirli işletme tanımlarını merkezileştirmek ve yeniden kullanmak için iç içe geçmiş görünümleri kullanıyorsunuz (ör. "Uygun öğrenci nedir?"). Bu, iç içe görünümler için geçerli bir kullanımdır. Bu veritabanını koruyor veya ayarlıyorsanız, bunları kaldırmanın aleyhine tutar.

• Tutun: İç içe görünümleri koruyarak yukarıda belirtilen avantaj ve dezavantajlara maruz kalırsınız.

• Kaldır: İç içe görünümleri kaldırmak için:

  1. Görünümlerin tüm oluşumlarını temel sorgularıyla değiştirmeniz gerekir.

  2. Uygun öğrenci / öğretmen / okul tanımınız değişirse, ilgili görünüm tanımını güncellemenin aksine, ilgili tüm sorguları güncellemeyi hatırlamalısınız.

Bazen iç içe geçmiş görünümler, toplamaların tekrarlanmasını önlemek için kullanılır. Diyelim ki mesajları sayan ve onları kullanıcılara göre gruplandıran bir görüntünüz var,> 100 mesaja sahip kullanıcıların sayısını, bu tür bir şeyi sayan bir görüşe sahip olabilirsiniz. Temel görünüm dizine alınmış bir görünüm olduğunda bu en etkilidir - verileri biraz farklı bir gruplandırmayla temsil etmek için mutlaka başka bir dizine alınmış görünüm oluşturmak istemezsiniz, çünkü şimdi performansın büyük olasılıkla iki katına çıktığı için dizin bakımı için ödeme yapıyorsunuzdur. Orijinal görünüme karşı yeterli.

Bunların hepsi sadece seçtikleri * ancak sıralamayı veya üstünü değiştirdiğiniz yalnızca iç içe geçmiş görünümlerse, bunun bir dizi iç içe görünümden daha parametrelerle (veya satır içi tablo değerli işlevler) saklı bir prosedür olarak kapsanması daha iyi görünmektedir. BENİM NACİZANE FİKRİME GÖRE.

Daha sonra SQL (2005+) sürümleri görünümlerin kullanımını optimize etmede daha iyi görünüyor. Görünümler iş kurallarını birleştirmek için en iyisidir. EG: Çalıştığım yerde telekom ürün veritabanına sahibiz. Her ürün bir rateplana atanır ve bu rateplan değişebilir ve rateplandaki oranlar, oranlar arttıkça veya değiştirilirken etkinleştirilebilir / devre dışı bırakılabilir.

Kolaylaştırmak için iç içe görünümler yapabiliriz. İlk görünüm, hangi tablolara ihtiyaç duyulursa kullansın ve oranlara oranlarını birleştirdi ve sonraki görüş seviyelerinin ihtiyaç duyacağı gerekli verileri getirdi. 2. görünüm (ler) sadece aktif rateplansları ve aktif oranlarını izole edebilir. Veya sadece müşteri oranları. Veya çalışan fiyatları (çalışan indirimi için). Ya da iş yerine konut müşteri oranları. (rateplanslar karmaşıklaşabilir). Mesele şu ki, temel görüş, rateplanslar için genel iş mantığımızın ve oranların tek bir yerde bir araya getirildiğinden emin olmaktır. Bir sonraki görüş açısı bize belirli oranlara (türler, etkin / etkin değil, vb.) Daha fazla odaklanmamızı sağlıyor.

Sorguları ve görünümleri aynı anda oluşturuyorsanız, görüşlerin hata ayıklamayı karmaşıklaştıracağını kabul ediyorum. Ancak, güvenilir bir görünüm kullanıyorsanız, hata ayıklamayı kolaylaştırır. Bu görüntünün zaten zil sesiyle geçtiğini biliyorsunuz, bu yüzden büyük olasılıkla soruna yol açmayacağını biliyorsunuz.

Bununla birlikte, görüşlerinizle ilgili sorunlar ortaya çıkabilir. "bir ürün sadece etkin olmayan bir rateplan ile ilişkili ise ne olur?" ya da "bir rateplan sadece üzerinde etkin olmayan oranlara sahipse?" Bu, kullanıcı hatalarını yakalayan bir mantıkla ön uç seviyede yakalanabilir. "Hata, ürün etkin olmayan bir rateplan'da ... lütfen düzeltin". Bir faturalandırma çalıştırmasından önce kontrol etmek için sorgu denetimlerini de çalıştırabiliriz. (tüm planları seçin ve soldaki aktif rateplan görünümüne katılın, yalnızca etkin bir rateplan almayan planları, ele alınması gereken sorunlar olarak geri getirin).

Bu konuda iyi olan şey, görünümler, raporlama, faturalandırma vb. Sorguları büyük ölçüde azaltmanıza olanak tanır. Bir müşteri hesabı görünümüne, sonra da sadece aktif müşterilerin 2. seviyeli bir görüntüsüne sahip olabilirsiniz. Bunu müşteri adresi bakış açısıyla yapın. Ürün (ler) i görerek takımın (müşterinin sahip olduğu ürüne katıldı). Ürün (ler) rateplan görmek için ekip. Bunu ürün özelliklerine göre inceleyin. Bütünlük sağlamak için her deneme-n-hatalı, görüntüle, görüntüle, görüntüle. Görünümleri kullanarak son sorgunuz çok küçük.

Düzenle:

Görüntünün düz bir tablo sorgusundan daha iyi olacağının bir örneği olarak ... bazı değişiklikler yapmak için geçici bir yüklenicimiz vardı. Ona bazı şeyler için görüşlerin olduğunu söylediler, ancak bütün sorgularını düzleştirmeye karar verdi. Fatura, bazı sorgularından bazı şeyleri kaçırıyordu. Birden çok rateplans ve oranlar üzerine oranlar almaya devam ettiler. Sorguların yalnızca oranların, bu oranın bu oranları kullanması beklenen başlangıç ​​/ bitiş tarihleri ​​arasında olması durumunda fiyatların faturalandırılmasına izin verecek ölçütlerinin bulunmadığı ortaya çıktı. Hata. Bu görüşü kullanmış olsaydı, bu mantığı çoktan hesaba katardı.

Temel olarak, performansa karşı akıl sağlığı sağlamalısınız. Belki bir veritabanının performansını artırmak için her türlü süslü şeyi yapabilirsiniz. Ancak, yeni bir kişinin devralması / sürdürmesi kabussa, gerçekten buna değer mi? Gerçekten yeni bir adamın mantığını değiştirmesi gereken tüm soruları bulmak zorunda kalmak (ve onu unutmasını / yağlanmasını önlemek için risk almak) zorlamak zorunda kalması b / c birisinin görüşlerinin "kötü" olduğuna karar verdi ve Çekirdek iş mantığını 100'lerin diğer sorgularında kullanılabilecek bir çözümde birleştirmedi mi? Gerçekten işinize ve BT / IS / DB ekibinize kalmış. Ancak, performansa göre netliği ve tek kaynaklı birleştirmeyi tercih ederim.

Asıl mesele kendi içinde iç içe geçmiş görüşler değildir. Asıl mesele, geliştiricilerin mevcut görüşlere ek tweaks katması olarak iç içe görünümlerin yayılması. Ben aslında tanımındaki görünümlerden birine katılan 4 katman iç içe geçmiş bir görünümle sorgular buldum. Bir sorunu analiz etmek ve çözmek yerine kolay yoldan çıkarma eğilimimiz, konunun köküdür.

Ortamımda, üretim sunucusundan rapor sunucusuna çok sayıda tablo kopyalıyoruz. Rapor sunucusunda çoğaltılmış üretim tablolarına dayanan VE iç içe geçmiş birçok görünümümüz vardır. Çoğaltma başlamadan önce, çoğaltmayı mümkün kılmak için tüm görünümleri kaldırmamız gerekir (bırakma ve yaratmayı kullanırız çünkü tabloların yapısı genellikle üretimde değişir). Çoğaltma sona erdikten sonra, tüm görüşleri yeniden oluşturmalıyız.

Şimdi işte eğlenceli kısım: Görüşlerin çoğu iç içe olduğundan, onları belirli bir düzende yeniden inşa etmeliyiz. Görünüm tanımında herhangi bir değişiklik yaparken, doğru yeniden oluşturma sırasını korumaya özen göstermeliyiz. Bu tam bir karmaşa. Çoğaltma kullanıyorsanız veya görünümler için kaynak olan tablolarınızı bırakıp yeniden oluşturuyorsanız iç içe görünümleri kullanmaktan kesinlikle vazgeçiyorum.

Performans başka bir şeydir. Başka görünümlere dayanan görünümler, yürütülmesi gereken birden çok sorgudan başka bir şey değildir. Daha büyük sorguyu bir araya getirmek, bir iş yaratmak ve bir tablo oluşturmak daha kolaydır. Daha kolay ve performansı arttırır.