İlişkisel Veritabanı Tasarım Kalıpları? [kapalı]

283

Tasarım örüntüleri genellikle nesne yönelimli tasarımla ilgilidir. İlişkisel veritabanlarını oluşturmak ve programlamak için tasarım modelleri
var mı?
Birçok sorunun mutlaka yeniden kullanılabilir çözümleri olmalıdır.

Örnekler arasında tablo tasarımı, saklı yordamlar, tetikleyiciler vb.

Martinfowler.com'a benzer, bu tür kalıpların çevrimiçi bir deposu var mı ?

Kalıpların çözebileceği sorunlara örnekler:

Hiyerarşik verilerin depolanması (örneğin, tür içeren tek tablo, 1: 1 tuşlu birden çok tablo ve farklılıklar ...)
Değişken yapıda veri saklama (örneğin, genel sütunlar ile xml ve ayrılmış sütunlar ...)
Verileri denormalize edin (minimum etkiyle nasıl yapılır, vb ...)

design-patterns database-design rdbms

— Sklivvz
kaynak

Hiyerarşik veri depolama için burada en iyi soru-cevap talebinde

— bulunacağım

1

Bizim göre on-konu rehberlik, " : Bazı sorular bunlar yukarıda listelenen kategorilerden birine uyması bile, konu dışı hala sorular için bize soran ... Bir kitap, aracı, yazılım kütüphanesi, öğretici veya başka tavsiye veya bulmak site dışı kaynaklar konu dışı ... "

— Robert Columbia

@RobertColumbia sorulduğunda 2008 yılında konu

— konuydu

İlişkisel veritabanları ve yazılım mühendisliğinin birçok alanında bu tasarım deseni kaynakları listesine göz atın github.com/DovAmir/awesome-design-patterns

— dov.amir

150

Martin Fowler'in İmza Dizisinde Yeniden Düzenleme Veritabanları adlı bir kitap var . Bu, veritabanlarının yeniden düzenlenmesi için tekniklerin bir listesini sağlar. Veritabanı kalıplarının bir listesini çok duyduğumu söyleyemem.

Ayrıca David C. Hay'ın Veri Modeli Desenlerini ve ilkini temel alan ve çok daha iddialı ve ilgi çekici olan bir Meta Veri Haritası'nı tavsiye ederim . Önsöz tek başına aydınlatıcıdır.

Ayrıca, önceden hazır bazı veritabanı modellerini aramak için harika bir yer Len Silverston'un Veri Modeli Kaynak Kitap Serisi Cilt 1 , evrensel olarak uygulanabilir veri modelleri (çalışanlar, hesaplar, nakliye, satın almalar, vb.), Cilt 2 , sektöre özgü veri modelleri (muhasebe, sağlık, vb.), Cilt 3 veri modeli modelleri sağlar.

Son olarak, bu kitap görünüşte UML ve Nesne Modelleme ile ilgili olsa da, Peter Coad'ın Renkli UML ile Modellemesi , herhangi bir nesnenin / veri modelinin 4 çekirdek arketipinin bulunduğu öncülünden başlayarak "arketip" odaklı bir modelleme süreci sağlar

— Michael Brown
kaynak

1

Kitap Scott W. Ambler ve Pramod J. Sadalage tarafından yazılan [Veritabanlarını Yeniden Düzenleme: Evrimsel Veritabanı Tasarımı] [1] ve gerçekten çok iyi. [1]: ambysoft.com/books/refactoringDatabases.html

— Panos

3

Ambler kitabıyla ilgili olarak: Hayır, aynı sebeple "sütun ekleme" veya "FK kısıtlaması oluşturma" ifadelerini aynı nedenden dolayı desen olarak listeleyemezsiniz.

— Tegiri Nenashi

Bu yeniden düzenleyici bir model değil. Ayıklama yöntemi gibi veya parametreyi yeniden adlandırın. Yeniden düzenleme ve kalıplar el ele gider.

— Michael Brown

Eklenecek olan: Fowler tarafından "Analiz Modelleri". Hay's stuff

— Neil McGuigan

2

Len Silverston'un Cilt 3, "Tasarım Desenleri" olarak değerlendireceğim tek kişi. İlk 2 kitapların yazıldığı zaman diliminde ortak olan örnek veri modellerini göstermektedir. Cilt 3, aslında belirli bir sorun senaryosu için birden fazla tasarım desenine sahiptir. Örneğin, bölüm 4 hiyerarşileri / toplamaları / eşler arası senaryoları kapsar ve her birinin artılarını ve eksilerini içeren birden çok tasarım sunar.

— DarrellNorton

46

Tasarım kalıpları önemsiz derecede yeniden kullanılabilir çözümler değildir.

Tasarım desenleri tanım gereği tekrar kullanılabilir. Bunlar diğer iyi çözümlerde tespit ettiğiniz kalıplardır .

Bir desen önemsiz bir şekilde tekrar kullanılamaz. Bununla birlikte, deseninizi takip ederek aşağı tasarımınızı uygulayabilirsiniz.

İlişkisel tasarım desenleri aşağıdakileri içerir:

Yabancı anahtar kullanarak Bire Çok ilişkiler (ana-ayrıntı, ebeveyn-çocuk) ilişkileri.
Köprü tablosu ile çoktan çoğa ilişkiler.
FK sütununda NULL'larla yönetilen isteğe bağlı bire bir ilişkiler.
Yıldız Şeması: Boyut ve Gerçek, OLAP tasarımı.
Tamamen normalleştirilmiş OLTP tasarımı.
Bir boyutta birden çok dizinlenmiş arama sütunu.
PK, bir veya daha fazla uygulama tarafından kullanılan açıklama ve kod değerlerini içeren "arama tablosu". Neden kod var? Bilmiyorum, ama ne zaman kullanılmaları gerektiği, bu kodları yönetmenin bir yoludur.
Uni-tablo. [Bazıları buna anti-desen diyor; bu bir model, bazen kötü, bazen iyi.] Bu, ikinci ve üçüncü normal formu ihlal eden önceden birleştirilmiş birçok öğeye sahip bir tablo.
Dizi tablosu. Bu, sütunlarda bir dizi veya değer dizisi içererek ilk normal formu ihlal eden bir tablodur.
Karma kullanımlı veritabanı. Bu, işlem işleme için normalleştirilmiş, ancak raporlama ve analiz için birçok ek dizin içeren bir veritabanıdır. Bu bir anti-desen - bunu yapma. İnsanlar yine de yapıyor, bu yüzden hala bir model.

Veri tabanı tasarlayan çoğu kişi yarım düzine "Bunlardan bir diğeri" kolayca çıngırak olabilir; bunlar düzenli olarak kullandıkları tasarım örüntüleridir.

Bu, idari ve operasyonel kullanım ve yönetim kalıplarını içermez.

— S.Lott
kaynak

Gördüğüm diğer bazı desenler çok ebeveynli çocuk tablosu (yani, herhangi bir tabloya bağlanabilen bir nesne tipine ve nesne kimliğine sahip global notlar gibi) veya kendinden referanslı bir FK'dir (yani, worker.manager -> çalışan. İD). Ayrıca birçok sütun içeren tek bir yapılandırma tablosu kullandım.

— r00fus

1

Neden karışık kullanımlı bir veritabanı bir anti-desendir. Bir veritabanından rapor almak istersem ne yapmam gerekiyor?

— zeytin

3

@lhnz: İşlemsel bir veritabanı tasarımından çok sayıda büyük rapor alamazsınız - raporlama için kilitleme işlemleri yavaşlatır. Karmaşık birleşimler (tekrar tekrar gerçekleştirilir), işlem performansına karşı bir başka vuruştur. Her ikisini de tek bir veritabanında yapamazsınız. Çok sayıda büyük rapor yapmak için, verileri bir yıldız şemasına taşımalısınız. Yıldız şeması kalıbı raporlama için optimize edilmiştir. Ve verilerin taşınması herhangi bir kilit tartışmasını kaldırır.

— S.Lott

Tabloları daha "uyumlu" veri tutuyorsanız, şemanın normalleştirilmesi satır kilidi çekişmesini azaltır mı? Benim düşüncem, eğer büyük bir tablo 2 çeşit veri kümesine yazıyorsa, ancak her ikisi de aynı satırdaysa, bu gereksiz kilit çekişmesine yol açacaktır.

— CMCDragonkai

6

AskTom muhtemelen Oracle DBs'deki en iyi uygulamalar hakkında en yararlı kaynaktır. (Genellikle belirli bir konuda bir Google sorgusunun ilk kelimesi olarak "asktom" yazarım)

İlişkisel veritabanlarıyla tasarım modellerinden bahsetmenin gerçekten uygun olduğunu düşünmüyorum. İlişkisel veritabanları zaten bir soruna bir "tasarım modeli" uygulamasıdır (sorun "bütünlüğünü korurken verilerin nasıl temsil edileceği, saklanacağı ve çalışılacağı" ve tasarım ilişkisel modeldir). Diğer yaklaşımlar (genellikle eski sayılır) Gezinme ve Hiyerarşik modellerdir (ve başkalarının var olduğundan eminim).

Bunu söyledikten sonra, "Veri Ambarı" nın veritabanı tasarımında biraz ayrı bir "desen" ya da yaklaşım olduğunu düşünebilirsiniz. Özellikle, Yıldız şeması hakkında bilgi edinmek isteyebilirsiniz .

— Galghamon
kaynak

4

Veritabanı geliştirme uzun yıllar sonra bazı başlıyor ve diyebiliriz ki başlamadan önce cevap gerekir bazı soru vardır:

sorular:

Gelecekte başka bir DBMS kullanmak ister misiniz? Evetse, geçerli DBMS'nin özel SQL öğelerini kullanmaz. Uygulamanızdaki mantığı kaldırın.

Kullanmaz:

tablo adlarında ve sütun adlarında beyaz boşluklar
Tablo ve sütun adlarında Ascii olmayan karakterler
belirli bir küçük harfe veya büyük harfe bağlama. Ve asla yalnızca küçük ve büyük harflerle farklılık gösteren 2 tablo veya sütun kullanmayın.
"FROM", "BETWEEN", "DELETE" vb. tablolar veya sütun adları için SQL anahtar kelimeleri kullanmaz

recomendations:

Unicode desteği için NVARCHAR veya eşdeğerini kullanın, o zaman kod sayfalarıyla ilgili bir sorununuz olmaz.
Her sütuna benzersiz bir ad verin. Bu, birleştirme sırasında sütunu seçmeyi kolaylaştırır. Her tablonun "ID" veya "Name" veya "Description" sütunları varsa çok zordur. XyzID ve AbcID kullanın.
Karmaşık SQL ifadeleri için bir kaynak paketi veya eşittir kullanın. Başka bir DBMS'ye geçmeyi kolaylaştırır.
Hiçbir veri türüne fazla baskı yapmaz. Başka bir DBMS bu veri türüne sahip olamaz. Örneğin Oracle işlerinde SMALLINT'in yalnızca bir numarası yoktur.

Umarım bu iyi bir başlangıç noktasıdır.

— Horcrux7
kaynak

7

Yorumlarınız oldukça öğretici ve yararlı olsa da, tasarım kalıpları değildir. Bunlar en iyi uygulamalardır. Teşekkürler,

— Sklivvz

7

Benzersiz sütun adları için öneriye katılmıyorum. Dezavantajlı bir şey olmasa bile customerid demekten ziyade customer.id demeyi tercih ederim.

— Paul Tomblin

1

Sorunuz biraz belirsiz, ancak sanırım UPSERTbir tasarım deseni olarak düşünülebilir. Uygulamak gerekmez diller için MERGE, sorunu çözmek için birkaç alternatifi (uygun satırlar varsa, UPDATE; else INSERT) varoldukları için.

— Sören Kuklau
kaynak

UPSERT, bir komut ve SQL dilinin bir parçasıdır. Bu bir örüntü değil.

— Todd R

UPSERT, SQL dilinin bazı varyantlarında bir komuttur - bir dizi platformda yoktur veya sadece son zamanlarda elde edilmiştir.

— Steve Homer

@ToddR - "Desenler" in, bir dil veya modeldeki eksikliklerden başka bir şey olmadığını, kullanıcının etrafta çalışma ortamı oluşturması gerektiğini duydum. UPSERT'in ne yaptığını bilmiyorum, ancak bazı SQL'lere eklenmiş olsa da, diğerleri değil, bir model.

— Martin F

1

Bir desene göre ne demek istediğinize bağlı. Kişi / Şirket / İşlem / Ürün ve benzerlerini düşünüyorsanız, evet - zaten çok sayıda genel veritabanı şeması var.

Factory, Singleton ... düşünüyorsanız hayır - DB programlama için çok düşük seviyelerde oldukları için bunlara ihtiyacınız yok.

Veritabanı nesnesi adlandırmasını düşünüyorsanız, tasarımın kendisi değil, kurallar kategorisi altındadır.

BTW, S.Lott, bire çok ve çoktan çoğa ilişkiler "kalıp" değildir. Bunlar ilişkisel modelin temel yapı taşlarıdır.

— Andrew Aziz değil
kaynak

(örneğin, kişi, müşteri, çalışan) gibi veritabanı mirası hakkında belki de böyle bir şey tasarım deseni olarak düşünülebilir?

— Muflix