it-swarm.dev

Bir veritabanı tasarlarken en önemli hususlar nelerdir?

Deneyimli programcılardan yeni bir veritabanı tasarlarken en önemli hususlar olarak gördüklerini bilmek isterim.

23
Cunners

Öncelikle ve en önemlisi iş alanını öğrenip anlayın.

1) Yoğun bir web sitesi gibi yüksek bir işlem oranına mı bakıyorsunuz yoksa küçük bir şirket İK sistemi gibi düşük kullanım mı arıyorsunuz?

2) Güvenlik önemli bir konudur - kişisel bilgileri mi, yoksa finansal verileri mi kullanıyorsunuz? Yoksa sadece bir ürün kataloğu mu

3) Kullanıcılarınız birçok güncelleme/ekleme yapacak mı, yoksa sadece salt okunur mu?

4) Kaç kullanıcı, kullanım şekilleri nelerdir (azami yük veya eşit dağıtılmış)

5) 24x7, 16x5 veya diğer çalışma sürelerine ihtiyacınız var mı, 24x7 bakım için hiçbir zamanınız olmadığından çok daha zordur

6) DB ne kadar büyüyecek? Eğer gerçekten büyükse, tablolarınızı bu ve/veya bölümleri dikkate alacak şekilde tasarlamanız gerekir.

7) Kurumsal kümeye sıcak arıza veya sadece normal hosting ile bakmak gerekiyor mu?

8) DB nasıl yönetilecek, çoğu DB projesinde kullanıcılar ve uygulamaları için çaba harcanmasının% 95'i harcanıyor, DB yöneticisi unutuldu

9) DB Admin, öncekilerden gelen yedeklemeleri, diğer sistemlerde yapılan değişiklikleri, diğer sistemlere entegrasyonu, veri yüklemeyi içerir

10) Aslında Veri yükleme ve mevcut verileri kullanma başlı başına bir diğer büyük konudur.

Bir başlangıç ​​için bu kadar

22
MrTelly

Veri tabanı, iş süreci tasarımınıza ikincildir ve iş sürecinizi doğrudan ve basit bir şekilde temiz bir şekilde desteklemelidir. İyi biçimlendirilmiş, temiz ve varlık modelinden çok daha fazla fayda sağlayacaksınız. burada ve orada dizin. Dolayısıyla, süreciniz tanımlandıktan sonra, bunu kabul edip, anlam ifade eden ilişkilerle olabildiğince temiz bir şekilde “varlıklara” bölersiniz. Varlıklarınızı öğrendikten sonra, veritabanı tablolarına dönüştürürler.

Yapılacak en önemli şeylerden biri, genel mimarlığı yapmamaktır.

Size bazı dişler ile cevap vermek için, örnek olarak bir "araç" varlığı alalım. Bir aracın birden fazla tekerleği vardır. Araca takılı birden fazla tekerlek olacağını bilmek için kritik bir kararınız var. Yapmak için 2 seçeneğiniz var - "Tekerlekler" i ayrı bir varlık yapabilir ya da "Araç" varlığında "tekerlek sayısını" bir tamsayı alanı yapabilirsiniz.

Eğer kesinlikle biliyorsanız her bir tekerleği hakkında çok fazla değişen bilgi saklamanız gerekeceğini, o zaman bir "Tekerlek" öğesi yaratın. Artık varlıklar arasında (araba ve tekerlek) bir ilişkiniz var.

Olmazsa, basit bir alan gayet iyi yapacaktır.

Bu kritik kararları düşünmek ve mümkün olduğunca basit hale getirmek, bir veritabanı tasarlarken benim için en önemli şey. Uygulamanızın bir sonraki katmanını/katmanlarını oluşturduğunuzda işler arasında gerçekten kolay ve gerçekten zor olmak arasındaki farkı yaratabilir.

16
Brandon

1 - Tutarlılık

Zamanla veritabanınız değişecek ve diğer kişilerin de onunla çalışması gerekecek. Kendinize ve onlara bir iyilik yapın ve yapıların, temel alan bilgisine sahip herhangi bir makul kişinin, tablonun içeriğini önceden tahmin edebileceği şekilde adlandırıldığından emin olun. Kullandığınız bazı temel yapıları (not defteri kadar basit olabilir) yazmak için zaman ayırın.

Örnekler:

  • Birincil anahtarların tümü IdTableName ile başlar
  • Tablo isimlerinin kasası Pascal'dır.
  • Yabancı anahtarların tümü TableNameId
  • ext ...

Alt çizgi kullanmayı veya kullanmamayı (alt çizgi için başka bir dönüşüm yerine koyma) kullanıp kullanmama, kullandığınız veya kullanmadığınız sürece tutarlı olduğunuz sürece günün sonunda önemli değildir. 

Veritabanınız, veri bütünlüğü için son savunma hattıdır. Tüm veri erişiminizi saklı yordamlar yoluyla yapın ve kontrol kısıtlamaları, yabancı anahtarlar vb. Kullanarak verilerin bütünlüğünü uygulayın. Verileri doğru yazın, CHAR (5) daha spesifik ve kesin olduğunda VARCHAR (50) kullanmayın.

Başka biri basit tutmakla ilgili bir şeyden bahsetti. Son fakat en az değil, bir şey inşa çünkü "gelecek" in ihtiyacınız olacak "düşünüyorum". İşler hızla değişiyor ve kullanacağınız şeyler yerine "kullanacağınızı" düşündüğünüz şeyler üzerinde daha fazla bakım yapmak zorunda kalacaksınız.

7
Ryan Pedersen

Veritabanının modellemesi gereken gerçek dünyaya bağlılık.

6
S.Lott

Şahsen "Mere Mortals İçin Veritabanı Tasarımı" nın bir kopyasını almanızı veya ödünç almanızı öneririm. Bir veritabanı tasarlarken göz önünde bulundurmanız gereken her şey o kitapta listelenir ve veritabanını oluşturabileceğiniz çok sistemli ve mantıklı bir sıradadır. Tablo ve Sütun tanımları sıkıcı, ancak sonunda kullanılan her dakikaya değer.

Kitap Google Kitaplar üzerinden veya Amazon.com'daki sayfa önizlemesi ile ilk bölümü okuyabileceğinize inanıyorum.

Zaman içinde veya bu siteden 'en iyi uygulamalar' olarak öğrenebileceğiniz bazı bilgiler var, ancak ilk denemede sıfırdan doğru şekilde tasarım yapan hiçbir şey yok.

4
William Holroyd

Verilerinizi bilin.

2
johnny

ayrıca veritabanının ne için kullanılacağını da anlamak zorundasınız. işlemler için (OLTP) ise, olabildiğince normalleştirilmelidir ve amaç işlemlerin olabildiğince çabuk tamamlanmasıdır. eğer analiz ve/veya raporlama içinse (OLAP), toplama yapacağınız birçok yerde denormalize edilmelidir. OLTP veritabanları için tasarım konuları OLAP veritabanlarına uygulanamaz ve bunun tersi de geçerlidir.

1
cruizer

Bilgi gereklilikleri en önemli kısımdır.

Bu, CMS tarafından verilen bir cevaptan "sisteminizin amacını belirleme" demenin başka bir yoludur.

Kavramsal veri modelleme, bilgi gereksinimlerini toplamak ve sunmak için sadece organize bir yoldur. Veritabanında depolanan ve sunulan her değer bir özelliğe ve her bir özelliğe bir etki alanına bağlıdır. Nitelikler, sırasıyla varlıkları veya varlıklar arasındaki ilişkileri tanımlar. Konu varlıkları ve ilişkileri, verilerin tanımladığı "gerçek dünya" nın kavramsal yapısını oluşturur. Bir ERD'yi kavramsal bir modelden oluşturmak sıkıcı olmasına rağmen kolaydır. 

Bundan sonra, bir DBMS seçebilir, mantıksal veritabanını tasarlayabilir, fiziksel veritabanını tasarlayabilir ve oluşturabilirsiniz. Her adımda, verdiğiniz kararlar veri bağımsızlığından dolayı geri dönüşümlüdür. Veri bağımsızlığı, performans sonuçları dışında, veri tabanı içindeki tasarım kararlarını kapsar. Tabii ki aracını bilmek zorundasın. 

Modelleri yönetmek için bir araca sahip olmak ve bunları diyagramlara ve komut dosyalarına dönüştürmek bu süreci hızlandırmakta ve hataları azaltmakta çok yardımcı olabilir. 

Ancak, bilgi gereksinimlerinizde ciddi hatalar veya eksiklikler varsa, bunun için akıllıca bir tasarım veya uygulama yapılmayacaktır.

1
Walter Mitty

kim inşa edecek ve koruyacak, nerede, nasıl ve ne ile. Bunu yapmak için ya da sadece onu kanatlamak için yöntem, prosedür ve işlemleriniz var mı? Kesinlikle, İş ihtiyaçlarının bir uygulamadan bağımsız bir ERD'de yakalanması gereken gerekli verileri yönlendirmesi gerekir. Ancak, zaman içinde verileri kimin koruyacağını da düşünmelisiniz. Ayrıca verilere "kimin" sahip olduğu gibi. Varlık ve öznitelik tanımları var.

1
JoeG

Temel bir nokta kümesi:

  • Sisteminizin amacını belirleyin.
  • Sisteminizin ihtiyaç duyacağı varlıkları belirleyin.
  • Her işletmenin hangi bilgileri sağlaması gerektiğini tanımlayın.
  • Varlıklarınız arasındaki mevcut ilişkileri tanımlayın
  • Kullanıcı verileriniz hakkında bilmek ve ne yapmak ister?.
  • Kavramsal ve Mantıksal Veri Tabanı Tasarımı
  • Normalizasyon ve ERD
  • Benzersiz değerlere sahip alanları tanımlayın.
  • Alanlarınız için uygun veri türlerini seçin.
  • Veri bankası yeniden düzenleme.
1
CMS

İyi bir veritabanı aşağıdaki gibi değerlendirilebilir:

Eğer bir veritabanı uygun şekilde tasarlanmışsa, şemadan başka hiçbir şeye bakarak bir işletmenin nasıl çalıştığını anlayabilmelisiniz.

Başka bir deyişle, veritabanı is iş. Veritabanı, işletmenin nasıl yönetildiğini yansıtmıyorsa, veritabanı yanlış veya işletme yanlış.

Veri tabanı ayrıca gerçekten, gerçekten çivilemeye ihtiyaç duyduğunuz şeylerden biridir. Kötü kodu her zaman düzeltebilirsiniz, ancak nadiren kötü bir şema değişikliğinden geri dönebilirsiniz. Doğru yaptığınızdan emin olun.

1
Cory R. King
  • Adlandırma Kuralları: bir kural grubuna bağlı kalın
  • Normalleştirme: (normalizasyonun kapsamı) - bu, veri varlığının karşılaştırılması için yapılan okuma sayısına veya güncelleme sayısına bağlı olacaktır.
  • İlişkisel Bütünlük ve Diğer Kısıtlamalar: Bazı insanlar Yabancı Anahtarların kullanımını savunurken bazıları kullanmıyor, ancak sizin ihtiyacınıza ve kişisel tercihinize göre büyük bir tartışma olduğu için bunu seçmelisiniz ama ben her zaman FK'leri kullanmayı tercih ederim
  • Veri tabanı diyagramları oluşturmak, mümkünse ekiple birlikte analiz etmek ve tartışmak.
0
WhoIsNinja