İster beğenelim ister beğenmesiz, çoğumuz olmasa da çoğumuz düzenli olarak veri tabanları ile çalışır veya bir gün biriyle çalışmak zorunda kalabiliriz. Vahşi doğada yanlış kullanım ve kötüye kullanım miktarı ve her gün ortaya çıkan veritabanı ile ilgili soruların hacmi göz önüne alındığında, geliştiricilerin bilmesi gereken belirli kavramlar olduğunu söylemek doğru olur - tasarım yapmasalar veya birlikte çalışmasalar bile veritabanları bugün. Yani:

Geliştiricilerin ve diğer yazılım profesyonellerinin veritabanları hakkında bilmeleri gereken önemli kavramlar nelerdir?

Yanıt Yönergeleri:

Listenizi kısa tutun.
Yanıt başına bir kavram en iyisidir.

Açık olun .
"Veri modelleme" önemli bir beceri olabilir , ama bu tam olarak ne anlama geliyor?

Gerekçenizi açıklayın.
Konseptiniz neden önemlidir? Sadece "dizin kullan" demeyin. "En iyi uygulamalara" girmeyin. Kitlenizi daha fazla bilgi edinmeye ikna edin.

Kabul ettiğiniz cevapları oylayın.
Önce diğer insanların cevaplarını okuyun. Yüksek dereceli bir cevap, iki düşük dereceli cevaptan daha etkili bir ifadedir. Ekleyecek daha çok şeyiniz varsa, bir yorum ekleyin veya orijinal belgeye bakın.

Kişisel olarak sizin için geçerli olmadığı için bir şeyi küçümsemeyin.
Hepimiz farklı alanlarda çalışıyoruz. Buradaki amaç, veritabanı acemilerinin, en önemlisi unvanı için rekabet etmemek üzere, veritabanı tasarımı ve veritabanı güdümlü geliştirme konusunda köklü, çok yönlü bir anlayış kazanması için yön sağlamaktır.

Geliştiricilerin veritabanları hakkında bilmeleri gereken ilk şey şudur: veritabanları ne için ? Nasıl çalışıyorlar, nasıl oluşturuyorlar, hatta veritabanındaki verileri almak veya güncellemek için nasıl kod yazıyorsunuz. Ama ne için bunlar?

Ne yazık ki, bunun cevabı hareketli bir hedef. Veritabanları heykeline, 1970'lerden 1990'ların başına kadar, veri paylaşımı içindir. Bir veritabanı kullanıyorsanız ve veri paylaşmıyorsanız ya akademik bir projeye katıldınız ya da kendiniz de dahil olmak üzere kaynakları israf ediyordunuz. Bir veritabanı kurmak ve bir DBMS'yi ehlileştirmek o kadar anıtsal görevlerdi ki, birden çok kez kullanılan veriler açısından geri ödemenin yatırıma uygun olması çok büyüktü.

Son 15 yılda, veritabanları sadece bir uygulama ile ilişkili kalıcı verilerin depolanması için kullanılmaktadır. MySQL , Access veya SQL Server için bir veritabanı oluşturmak o kadar rutin hale geldi ki veritabanları neredeyse sıradan bir uygulamanın rutin bir parçası haline geldi. Bazen, ilk sınırlı görev görev sürekliliği ile yukarı doğru itilir, çünkü verilerin gerçek değeri görünür hale gelir. Maalesef, tek bir amaç göz önünde bulundurularak tasarlanan veritabanları, kurumsal çapta ve görev açısından kritik bir role itilmeye başladıklarında genellikle önemli ölçüde başarısız olurlar.

Geliştiricilerin veritabanları hakkında öğrenmeleri gereken ikinci şey, tüm veri merkezli dünya görüşüdür . Veri merkezli dünya görüşü, süreç merkezli dünya görüşünden çoğu geliştiricinin öğrendiği her şeyden daha farklıdır. Bu boşlukla karşılaştırıldığında, yapılandırılmış programlama ile nesne yönelimli programlama arasındaki boşluk nispeten küçüktür.

Geliştiricilerin en azından genel bir bakışta öğrenmesi gereken üçüncü şey, kavramsal veri modelleme, mantıksal veri modelleme ve fiziksel veri modelleme dahil veri modellemedir.

Kavramsal veri modelleme , veri merkezli bir bakış açısından gerçekten ihtiyaç analizidir.

Mantıksal veri modelleme genellikle belirli bir veri modelinin kavramsal veri modellemesinde keşfedilen gereksinimlere uygulanmasıdır. İlişkisel model diğer tüm spesifik modellerden çok daha fazla kullanılır ve geliştiricilerin ilişkisel modeli kesin olarak öğrenmeleri gerekir. Önemsiz bir gereklilik için güçlü ve ilgili bir ilişkisel model tasarlamak önemsiz bir görev değildir. İlişkisel modeli yanlış anlarsanız iyi SQL tabloları oluşturamazsınız.

Fiziksel veri modelleme genellikle DBMS'ye özgüdür ve geliştirici aynı zamanda veritabanı oluşturucu veya DBA değilse, çok ayrıntılı olarak öğrenilmesi gerekmez. Geliştiricilerin anlaması gereken şey, fiziksel veritabanı tasarımının mantıksal veritabanı tasarımından ne ölçüde ayrılabileceğidir ve yüksek hızlı bir veritabanı üretmenin sadece fiziksel tasarımı değiştirerek ne ölçüde başarılabileceğidir.

Geliştiricilerin öğrenmesi gereken bir sonraki şey , hız (performans) önemli olmakla birlikte, veritabanının kapsamını gözden geçirme ve genişletme yeteneği veya programlamanın basitliği gibi diğer tasarım iyiliği ölçümlerinin daha da önemlidir .

Son olarak, veritabanlarıyla uğraşan herkes , verilerin değerinin genellikle onu yakalayan sistemden daha uzun sürdüğünü anlamalıdır .

Whew!

İyi soru. Belirli bir sırada olmayan bazı düşünceler şunlardır:

1. Normalleştirme, en azından ikinci normal forma kadar gereklidir.

2. Doğru basamaklı silme ve güncelleme hususları ile referans bütünlüğü de gereklidir.

3. Kontrol kısıtlamalarının iyi ve doğru kullanımı. Veritabanı mümkün olduğunca çok iş yapsın.

4. İş mantığını hem veritabanına hem de orta katman koduna dağıtmayın. Tercihen orta katman kodunda birini veya diğerini seçin.

5. Birincil anahtarlar ve kümelenmiş anahtarlar için tutarlı bir yaklaşıma karar verin.

6. Dizini aşmayın. Dizinlerinizi akıllıca seçin.

7. Tutarlı tablo ve sütun adlandırma. Bir standart seçin ve ona uyun.

8. Veritabanında boş değerleri kabul edecek sütun sayısını sınırlayın.

9. Tetikleyicilerle taşınmayın. Kullanımları var ama aceleyle işleri zorlaştırabilirler.

10. UDF'lere dikkat edin. Harikalar, ancak bir sorguda ne sıklıkta çağrılabileceğini bilmediğinizde performans sorunlarına neden olabilirler.

11. Celko'nun veritabanı tasarımı kitabı alın. Adam kibirli ama eşyalarını biliyor.

İlk olarak, geliştiricilerin veritabanları hakkında bilinmesi gereken bir şey olduğunu anlamaları gerekir. Bunlar sadece SQL'e yerleştirdiğiniz ve sonuç kümelerini çıkardığınız sihirli cihazlar değil, kendi mantığı ve tuhaflıkları olan çok karmaşık yazılım parçalarıdır.

İkincisi, farklı amaçlar için farklı veritabanı kurulumları vardır. Bir veri ambarı varsa, bir geliştiricinin çevrimiçi işlem veritabanından geçmiş raporlar hazırlamasını istemezsiniz.

Üçüncüsü, geliştiricilerin birleştirmeler dahil temel SQL'i anlamaları gerekir.

Bu geçmişte, geliştiricilerin ne kadar yakından dahil olduğuna bağlıdır. DBA'ların koridorun hemen altında olduğu ve DBA'ların kendi alanlarında olduğu yerlerde geliştirici ve fiili DBA olduğum işlerde çalıştım. (Ben üçüncü sevmiyorum.) Geliştiriciler veritabanı tasarımı dahil varsayalım:

Temel normalleşmeyi, en azından ilk üç normal formu anlamalıdırlar. Bunun ötesinde bir DBA alın. ABD mahkemeleriyle (ve burada rastgele televizyon şovları sayılır) deneyimi olanlar için, "Anahtara, tüm anahtara ve anahtardan başka bir şeye bağlı değil, bu yüzden size Codd'a yardım edin."

Dizinler hakkında bir ipucu sahibi olmaları gerekir, yani hangi dizinlere ihtiyaç duydukları ve performansı nasıl etkileyebilecekleri hakkında fikir sahibi olmaları gerekir. Bu, işe yaramaz indekslere sahip olmamak, ancak sorgulara yardımcı olmak için bunları eklemekten korkmamak anlamına gelir. DBA için başka her şey (denge gibi) bırakılmalıdır.

Veri bütünlüğü ihtiyacını anlamaları ve verileri nerede doğruladıklarını ve sorun bulurlarsa ne yaptıklarına işaret edebilmeleri gerekir. Bu veritabanında (kullanıcı için anlamlı bir hata mesajı vermek zor olacak) olmak zorunda değil, ama bir yerde olması gerekir.

Bir planın nasıl elde edileceği ve genel olarak nasıl okunacağı hakkında temel bilgiye sahip olmalıdırlar (en azından algoritmaların etkili olup olmadığını söylemek için yeterli).

Bir tetikleyicinin ne olduğunu, bir görüşün ne olduğunu ve veritabanı parçalarını bölümlemenin mümkün olduğunu belirsiz bir şekilde bilmelidirler. Herhangi bir ayrıntıya ihtiyaç duymazlar, ancak DBA'ya bu şeyleri sormayı bilmeleri gerekir.

Elbette üretim verilerini, üretim kodunu ya da bunun gibi şeyleri karıştırmamayı bilmeli ve tüm kaynak kodlarının bir VCS'ye girdiğini bilmelidirler.

Şüphesiz bir şey unuttum, ancak eldeki gerçek bir DBA varsa, ortalama geliştiricinin bir DBA olması gerekmez.

Temel Dizinleme

Ben her zaman bir tablo veya hiçbir dizin veya keyfi / yararsız dizinleri ile tüm bir veritabanı görmek için şok oldum. Veritabanını tasarlamasanız ve sadece bazı sorular yazmak zorunda olsanız bile , en azından anlamak hala önemlidir:

• Veritabanınızda endekslenen ve olmayanlar:
• Tarama türleri, nasıl seçildikleri ve sorgu yazma şekliniz arasındaki fark bu seçimi nasıl etkileyebilir;
• Kapsam kavramı (neden sadece yazmamanız gerekir SELECT *);
• Kümelenmiş ve kümelenmemiş dizin arasındaki fark;
• Neden daha büyük / büyük dizinler daha iyi olmayabilir;
• Neden filtre sütunlarını işlevlere sarmaktan kaçınmalısınız?

Tasarımcılar ayrıca ortak dizin anti-kalıplarının da farkında olmalıdır, örneğin:

• Access desen önleme (her sütunu tek tek dizine ekleme)
• Catch-All anti-pattern (Görünüşe göre, bu sütunlardan herhangi birini içeren akla gelebilecek her sorguyu hızlandıracağına dair yanlış izlenim altında, tüm veya çoğu sütun üzerinde bir büyük dizin).

Bir veritabanının dizinlemesinin kalitesi - ve yazdığınız sorgularla bundan yararlanıp yararlanmamanız - açık arayla en önemli performans yığınını oluşturur. SO ve kötü performanstan şikayet eden diğer forumlarda yayınlanan 10 sorudan 9'unun her zaman düşük endeksleme veya anlaşılmaz bir ifade nedeniyle ortaya çıktığı görülüyor.

normalleştirme

Normalize edilmiş bir tasarımla ("Bölge başına toplam satışları göster") tamamen anlaşılır olabilecek aşırı karmaşık bir sorgu yazmakta zorlanan birini görmek beni her zaman üzüyor.

Bunu başlangıçta anlar ve buna göre tasarlarsanız, daha sonra kendinizi çok fazla acıdan kurtaracaksınız. Normalleştirdikten sonra performans açısından normalleştirilmesi kolaydır; başlangıçtan itibaren bu şekilde tasarlanmamış bir veritabanını normalleştirmek o kadar kolay değildir.

En azından, 3NF'nin ne olduğunu ve oraya nasıl ulaşacağınızı bilmelisiniz. Çoğu işlem veritabanında bu, sorguların yazılmasını kolaylaştırmak ile iyi performansı korumak arasında çok iyi bir dengedir.

Dizinler Nasıl Çalışır?

Muhtemelen en önemlisi değil, ama en küçümseyen konudur.

Dizin oluşturmayla ilgili sorun, SQL eğiticilerinin genellikle bunlardan hiç bahsetmemesi ve tüm oyuncak örneklerinin herhangi bir dizin olmadan çalışmasıdır.

Daha deneyimli geliştiriciler, " Bir dizin sorguyu hızlı hale getirir " den daha fazla dizin bilmeden oldukça iyi (ve karmaşık) SQL yazabilir .

Bunun nedeni, SQL veritabanlarının kara kutu gibi çok iyi bir iş çıkarmasıdır:

Bana neye ihtiyacın olduğunu söyle (gimme SQL), ben hallederim.

Ve bu, doğru sonuçları almak için mükemmel bir şekilde çalışır. SQL yazarı, sistemin sahne arkasında ne yaptığını bilmesine gerek yok - her şey sooo slooooow oluncaya kadar .....

İşte o zaman indeksleme bir konu olur. Ama bu genellikle çok geç ve birileri (bazı şirketler?) Zaten gerçek bir sorundan muzdarip.

Bu nedenle , dizin oluşturmanın veritabanlarıyla çalışırken unutulmaması gereken 1 numaralı konu olduğuna inanıyorum . Ne yazık ki unutmak çok kolay.

feragat

Argümanlar ücretsiz e-kitabım " Use The Index, Luke " önsözünden ödünç alınmıştır . Zamanımın çoğunu dizinlerin nasıl çalıştığını ve bunların nasıl doğru şekilde kullanılacağını anlatarak geçiriyorum.

Ben sadece bir gözlem işaret etmek istiyorum - yani yanıtların çoğunluğu ilişkisel veritabanları ile değiştirilebilir olduğunu varsayar. Nesne veritabanları, düz dosya veritabanları da vardır. Eldeki yazılım projesinin ihtiyaçlarını değerlendirmek önemlidir. Programcı bakış açısından, veritabanı kararı daha sonraya ertelenebilir. Diğer yandan veri modelleme erken elde edilebilir ve çok başarılı olabilir.

Veri modellemenin önemli bir bileşen olduğunu ve nispeten eski bir kavram olduğunu düşünüyorum ancak yazılım endüstrisinde birçok kişi tarafından unutulmuş bir kavram. Veri modelleme, özellikle kavramsal modelleme, bir sistemin işlevsel davranışını ortaya çıkarabilir ve kalkınma için bir yol haritası olarak kullanılabilir.

Öte yandan, gerekli veritabanı türü, ortam, kullanıcı hacmi ve sabit disk alanı gibi kullanılabilir yerel donanımları içeren birçok farklı faktöre göre belirlenebilir.

SQL enjeksiyonundan kaçınma ve veritabanınızı nasıl koruyacağınız

Her geliştirici bunun yanlış olduğunu bilmelidir: "Bir veritabanı işleminin profilini çıkarmak profil oluşturma kodundan tamamen farklıdır."

Geleneksel anlamda açık bir Big-O vardır. Bir EXPLAIN PLAN(veya eşdeğeri) yaptığınızda algoritmayı görürsünüz. Bazı algoritmalar iç içe döngüler içerir ve O ( n ^ 2) 'dir. Diğer algoritmalar B-ağacı aramaları içerir ve O ( n log n ) 'dir.

Bu çok, çok ciddi. Endekslerin neden önemli olduğunu anlamanın merkezinde yer alır. Hız-normalizasyon-denormalizasyon dengesinin anlaşılmasında merkezi bir öneme sahiptir. Bir veri ambarının neden işlemsel güncellemeler için normalleştirilmemiş bir yıldız şeması kullandığını anlamak için çok önemlidir.

Kullanılan algoritmadan emin değilseniz aşağıdakileri yapın. Dur. Sorgu Yürütme planını açıklar. Dizinleri uygun şekilde ayarlayın.

Ayrıca, sonuç: Daha Fazla Endeks Daha İyi Değil.

Bazen bir işleme odaklanan bir dizin diğer işlemleri yavaşlatır. İki işlemin oranına bağlı olarak, bir dizin eklemenin iyi etkileri olabilir, genel bir etkisi olmayabilir veya genel performansa zarar verebilir.

Her geliştiricinin veritabanlarının farklı bir paradigma gerektirdiğini anlaması gerektiğini düşünüyorum .

Verilerinize ulaşmak için bir sorgu yazarken, küme tabanlı bir yaklaşım gerekir. Etkileşimli bir geçmişe sahip birçok insan bununla mücadele eder. Ve yine de, onu kucakladıklarında, çözüm kendini tekrarlayan odaklı zihinlerinde ilk sunan çözüm olmasa da, çok daha iyi sonuçlar elde edebilirler.

Mükemmel soru. Bakalım, ilk önce hiç kimse birleşimleri tam olarak anlamayan bir veri tabanını sorgulamayı düşünmemelidir. Bu, direksiyon simidinin ve frenlerin nerede olduğunu bilmeden araba kullanmak gibidir. Ayrıca veri türlerini ve en iyisini nasıl seçeceğinizi bilmeniz gerekir.

Geliştiricilerin anlaması gereken bir diğer şey, bir veritabanı tasarlarken aklınızda bulundurmanız gereken üç şey olmasıdır:

1. Veri bütünlüğü - eğer verilere güvenilemiyorsa, temelde hiçbir veriniz yoktur - bu, diğer birçok kaynağın veritabanına dokunabileceğinden, uygulamada gerekli mantığı koymama anlamına gelir. Veri bütünlüğü için kısıtlamalar, yabancı anahtarlar ve bazen tetikleyiciler gereklidir. Onları kullanmayın çünkü onları sevmiyorsunuz veya anlamaktan rahatsız olmak istemiyorsunuz.

2. Performans - kötü performans gösteren bir veritabanını yeniden düzenlemek çok zordur ve performans en baştan dikkate alınmalıdır. Aynı sorguyu yapmanın birçok yolu vardır ve bazılarının neredeyse her zaman daha hızlı olduğu bilinmektedir, bu yolları öğrenmemek ve kullanmamak kısa görüşlüdür. Sorgu veya veritabanı yapıları tasarlamadan önce performans ayarlama hakkındaki bazı kitapları okuyun.

3. Güvenlik - bu veriler şirketinizin can damarıdır, sıklıkla çalınabilecek kişisel bilgiler içerir. Verilerinizi SQL enjeksiyon saldırılarına, sahtekarlık ve kimlik hırsızlığına karşı korumayı öğrenin.

Bir veritabanını sorgularken yanlış yanıtı almak kolaydır. Veri modelinizi iyice anladığınızdan emin olun. Sık sık gerçek kararların sorgunuzun döndürdüğü verilere dayanarak verildiğini unutmayın. Yanlış olduğu zaman, yanlış iş kararları verilir. Bir şirketi kötü sorgulardan öldürebilir veya büyük bir müşteriyi kaybedebilirsiniz. Verilerin bir anlamı var, geliştiriciler genellikle bunu unutuyor gibi görünüyor.

Veriler neredeyse hiç kaybolmaz, verileri bugün nasıl elde etmek yerine zaman içinde depolamayı düşünün. Yüz bin kaydı olduğu zaman iyi çalışan bu veritabanı on yıl içinde çok iyi olmayabilir. Uygulamalar nadiren veri kadar sürer. Performans için tasarımın kritik olmasının bir nedeni de budur.

Veritabanınız, uygulamanın görmesi gerekmeyen alanlara ihtiyaç duyar. Çoğaltma için GUID'ler, eklenen tarih alanları gibi şeyler. Ayrıca, değişikliklerin geçmişini ve bunları kimin ne zaman yaptığını ve bu depodan kötü değişiklikleri geri yükleyebilmenizi de gerekebilir. Bir web sitesine gelmeden önce bunu nasıl yapmak istediğinizi düşünün, bir güncellemeye bir nereye yan tümcesi koymayı unuttuğunuz ve tüm tabloyu güncellediğiniz sorunu nasıl çözeceğinizi sorun.

Asla veritabanının üretim sürümünden daha yeni bir sürümünde geliştirmeyin. Asla, asla, asla doğrudan bir üretim veritabanına karşı geliştirme yapmayın.

Veritabanı yöneticiniz yoksa, birisinin yedek aldığından ve bunları nasıl geri yükleyeceğini bildiğinden ve geri yüklemeyi test ettiğinden emin olun.

Veritabanı kodu koddur, tıpkı kodunuzun geri kalanı gibi kaynak kontrolünde tutmamak için hiçbir mazeret yoktur.

Evrimsel Veritabanı Tasarımı. http://martinfowler.com/articles/evodb.html

Bu çevik metodolojiler veritabanı değişim sürecini yönetilebilir, öngörülebilir ve test edilebilir hale getirir.

Geliştiriciler, sürüm kontrolü, sürekli entegrasyon ve otomatik test açısından bir üretim veritabanını yeniden düzenlemek için ne gerektiğini bilmelidir.

Evrimsel Veritabanı Tasarımı sürecinin idari yönleri vardır, örneğin, bu kod tabanının tüm veritabanlarında bir ömür süresinden sonra bir sütun bırakılmalıdır.

En azından, Veritabanı Yeniden Düzenleme kavramının ve yöntemlerinin var olduğunu bilin. http://www.agiledata.org/essays/databaseRefactoringCatalog.html

Sınıflandırma ve süreç açıklaması, bu yeniden düzenleme işlemleri için de araçların uygulanmasını mümkün kılar.

İlişkisel veritabanlarıyla ilgili deneyimimden, her geliştirici bilmelidir:

- Farklı veri türleri :

Doğru iş için doğru türü kullanmak DB tasarımınızı daha sağlam, sorgularınızı daha hızlı ve hayatınızı kolaylaştıracaktır.

- 1xM ve MxM hakkında bilgi edinin :

Bu ilişkisel veritabanları için ekmek ve tereyağı. Bir-çok ve çok-çok ilişkilerini anlamanız ve gerektiğinde başvurmanız gerekir.

- " ÖPÜCÜK " ilkesi DB için de geçerlidir :

Sadelik her zaman en iyi sonucu verir. DB'nin nasıl çalıştığını incelediyseniz, bakım ve hız sorunlarına yol açacak gereksiz karmaşıklığı önleyeceksiniz.

- Endeksler :

Ne olduklarını biliyorsan yeterli değil. Onları ne zaman kullanacağınızı ve ne zaman kullanmamanızı anlamanız gerekir.

Ayrıca:

• Boole cebri senin arkadaşın
• Resimler: Onları DB'de saklamayın. Neden diye sorma.
• SELECT ile SİL'i test et

Herkesin, hem DBA'lar hem de geliştirici / tasarımcı / mimarlar, bir iş alanını nasıl düzgün bir şekilde modelleyeceğini ve bu iş alanı modelini hem normalleştirilmiş bir veritabanı mantıksal modeline, optimize edilmiş bir fiziksel modele hem de bir her biri farklı nedenlerle (farklı olabilir) uygun nesne yönelimli sınıf modeli ve birbirlerinden ne zaman, neden ve nasıl farklı olduklarını (veya olması gerektiğini) anlar.

Güçlü temel SQL becerileri söyleyebilirim. Şimdiye kadar veritabanları hakkında biraz bilgi sahibi olan ancak her zaman oldukça basit bir sorguyu formüle etme konusunda ipuçları isteyen birçok geliştirici gördüm. Sorgular her zaman kolay ve basit değildir. İyi normalleştirilmiş bir veritabanını sorgularken birden çok birleşim (iç, sol vb.) Kullanmanız gerekir.

Walter M.'nin cevabına aşağıdaki yorum hakkında:

"Çok iyi yazılmış! Ve tarihsel bakış açısı o zamanlar veritabanı çalışması yapmayan insanlar için harika (yani ben)".

Tarihsel perspektif belli bir anlamda kesinlikle çok önemlidir. "Tarihi unutanlar, onu tekrarlamaya mahkumdur." Geçmişin hiyerarşik hatalarını yineleyen Cfr XML, geçmişin ağ hatalarını tekrarlayan grafik veritabanları, OO sistemleri hiyerarşik modeli kullanıcılar üzerinde zorlarken, beyninin onda biri bile olan herkes hiyerarşik modelin genel için uygun olmadığını bilmelidir. gerçek dünyanın amaç gösterimi, vb.

Sorunun kendisi için:

Her veritabanı geliştiricisi "İlişkisel" in "SQL" e eşit olmadığını bilmelidir. Daha sonra DBMS satıcıları tarafından neden bu kadar berbat bir şekilde hayal kırıklığına uğradıklarını ve komik satıcıları emmeye devam etmek istiyorlarsa neden aynı satıcılara daha iyi şeyler (örneğin gerçekten ilişkisel olan DBMS'ler) bulmaları gerektiğini söylediler. böylesi boktan yazılımlar için müşterilerinin parasını ödemeleri).

Ve her veritabanı geliştiricisi ilişkisel cebir hakkında her şeyi bilmelidir. Sonra artık bu aptal "İşimi nasıl yapacağımı bilmiyorum ve başka birisinin benim için yapmasını istiyorum" soruları artık Stack Overflow üzerinde göndermek zorunda tek bir geliştirici kaldı olmaz.

Sanırım birçok teknik detay burada ele alındı ​​ve bunlara eklemek istemiyorum. Söylemek istediğim tek şey teknikten daha sosyal, bir uygulama geliştiricisi olarak "en iyi bilmek DBA" tuzağına düşmeyin.

Sorgu ile performans sorunları yaşıyorsanız, sorunun sahipliğini de alın. Kendi araştırmanızı yapın ve DBA'ların neler olduğunu ve çözümlerinin sorunu nasıl ele aldığını açıklamasını isteyin.

Araştırmayı yaptıktan sonra da kendi önerilerinizle gelin. Yani, veritabanı sorunlarını DBA'lara bırakmak yerine soruna işbirliğine dayalı bir çözüm bulmaya çalışıyorum.

Basit saygı.

• Sadece bir depo değil
• Muhtemelen satıcıdan veya DBA'lardan daha iyi bilmiyorsunuz
• Sana bağıran üst düzey yöneticilerle sabah 3'te desteklemeyeceksin

Denormalizasyonu şeytan değil olası bir melek olarak düşünün ve ayrıca NoSQL veritabanlarını ilişkisel veritabanlarına alternatif olarak düşünün .

Ayrıca, veritabanlarını tasarlamasanız bile, Varlık İlişkisi modelinin her geliştirici için mutlaka bilinmesi gerektiğini düşünüyorum. Veritabanınızın ne hakkında olduğunu tam olarak anlamanıza izin verecektir.

Asla yanlış metin kodlamasına sahip veri eklemeyin.

Veritabanınız birden fazla kodlamayla kirlendiğinde, yapabileceğiniz en iyi yöntem sezgisel tarama ve el emeği kombinasyonudur.

Sözdizimi ve kullandıkları kavramsal seçeneklerin yanı sıra (birleştirmeler, tetikleyiciler ve saklı yordamlar gibi), bir veritabanı kullanan her geliştirici için kritik olacak bir şey şudur:

Motorunuzun spesifik olarak yazdığınız sorguyu nasıl gerçekleştireceğini bilin.

Bunun çok önemli olduğunu düşündüğüm sebep sadece üretim istikrarı. Kodunuzun nasıl çalıştığını bilmelisiniz, böylece uzun bir işlevin tamamlanmasını beklerken iş parçanızdaki tüm yürütmeyi durdurmuyorsunuz, neden sorgunuzun veritabanını, programınızı ve hatta belki de nasıl etkileyeceğini bilmek istemiyorsunuz? sunucu?

Bu aslında Ar-Ge ekibime noktalı virgül ya da benzerinden daha fazla çarpan bir şey. Varsayım, sorguların hızlı bir şekilde yürütüleceğidir, çünkü geliştirme sistemlerinde tablolarda sadece birkaç bin satır ile çalışır. Üretim veritabanı aynı boyutta olsa bile, çok daha fazla kullanılması muhtemeldir ve bu nedenle aynı anda birden fazla kullanıcının ona erişmesi veya başka bir sorguda yanlış gitmesi gibi başka kısıtlamalardan muzdarip olması, böylece gecikme bu sorgunun sonucu.

Birleşmelerin bir sorgunun performansını nasıl etkilediği gibi basit şeyler bile üretimde paha biçilmezdir. Kavramsal olarak işleri kolaylaştıran birçok veritabanı motorunun birçok özelliği vardır, ancak açıkça düşünülmediği takdirde performansta gotchas getirebilir.

Veritabanı motoru yürütme sürecinizi bilin ve planlayın.

Veritabanlarını çok kullanan (günlük veya neredeyse her gün sorgu yazma / sürdürme) yolun ortasında bir profesyonel geliştirici için, beklentinin diğer alanlarla aynı olması gerektiğini düşünüyorum: Üniversitede bir tane yazdınız .

Her C ++ geek kolejde bir dize sınıfı yazdı. Her grafik meraklısı üniversitede bir ışın izleyici yazdı. Her web meraklısı üniversitede etkileşimli web siteleri (genellikle "web çerçeveleri" olmadan önce) yazdı. Her donanım nerd (ve hatta yazılım nerdleri) üniversitede bir CPU yaptı. Her doktor, sadece kan basıncımı alıp bana bugün kolesterolümün çok yüksek olduğunu söylese bile, üniversitedeki tüm bir kadavrayı parçaladı. Veritabanları neden farklı olabilir?

Ne yazık ki, bugün, bir nedenden dolayı farklı görünüyorlar. İnsanlar .NET programcılarının C'de dizelerin nasıl çalıştığını bilmesini , ancak RDBMS'nizin iç kısımlarını bilmesini ister sizi çok fazla endişelendirmemelidir .

Sadece onlar hakkında okumaktan ve hatta yukarıdan aşağıya doğru çalışmaktan aynı düzeyde bir anlayış elde etmek neredeyse imkansızdır. Ancak en alttan başlar ve her parçayı anlarsanız, veritabanınız için özellikleri anlamak nispeten kolaydır. Bir sürü veritabanı meraklısının göründüğü şeyler bile, ilişkisel olmayan bir veritabanının ne zaman kullanılacağı gibi.

Belki de bu biraz katıdır, özellikle de üniversitede bilgisayar bilimi eğitimi almadıysanız. Bunu biraz tonlayacağım: Bugün birini tamamen, sıfırdan yazabilirsiniz . PostgreSQL sorgu optimize edicisinin nasıl çalıştığını bilmiyorsanız umursamıyorum, ancak kendiniz bir tane yazmak için yeterli biliyorsanız, muhtemelen yaptıklarıdan çok farklı olmayacaktır. Ve biliyorsunuz, basit bir tane yazmak gerçekten zor değil.

Benzersiz olmayan bir dizindeki sütunların sırası önemlidir.

İlk sütun, içeriğinde en fazla değişkenliğe sahip (yani kardinalite) sütun olmalıdır.

Bu, SQL Server'ın çalışma zamanında dizini kullanma konusunda yararlı istatistikler oluşturma yeteneğine yardımcı olmaktır.

Veritabanını programlamak için kullandığınız araçları anlayın !!!

Kodumun neden gizemli bir şekilde başarısız olduğunu anlamaya çalışırken çok fazla zaman harcadım.

Örneğin, .NET kullanıyorsanız, System.Data.SqlClientad alanındaki nesneleri düzgün bir şekilde nasıl kullanacağınızı bilmeniz gerekir . Nasıl yöneteceğinizi bilmeniz gerekirSqlConnectionAçıldıklarından, kapatıldıklarından ve gerektiğinde düzgün bir şekilde atıldıklarından emin olmak nesnelerinizi gerekir.

A kullandığınızda SqlDataReader, cihazınızdan ayrı olarak kapatılması gerektiğini bilmeniz gerekir SqlConnection. Veritabanına isabet sayısını en aza indirmek için uygun olduğunda bağlantıların nasıl açık tutulacağını anlamanız gerekir (çünkü bunlar hesaplama süresi açısından nispeten pahalıdır).

• Temel SQL becerileri.
• Dizin.
• DATE / TIME / TIMESTAMP'in farklı enkarnasyonları ile ilgilenin.
• Kullandığınız platform için JDBC sürücü belgeleri.
• İkili veri türleri ( CLOB , BLOB , vb.)

Bazı projeler için ve Nesneye Dayalı model daha iyidir.

Diğer projeler için bir İlişkisel model daha iyidir.

Empedans uyumsuzluğu sorunu ve yaygın eksiklikleri veya ORM'leri bilmek.

RDBMS Uyumluluğu

Uygulamanın birden fazla RDBMS'de çalıştırılması gerekip gerekmediğine bakın. Evetse, aşağıdakileri yapmak gerekebilir:

• RDBMS SQL uzantılarından kaçının
• tetikleyicileri ve mağaza prosedürlerini ortadan kaldırın
• katı SQL standartlarına uyun
• alan veri türlerini dönüştürme
• işlem yalıtım düzeylerini değiştirme

Aksi takdirde, bu sorular ayrı ayrı ele alınmalı ve uygulamanın farklı versiyonları (veya konfigürasyonları) geliştirilecektir.

SQL sorgusu tarafından döndürülen satırların sırasına bağlı kalmayın.

http://www.reddit.com/r/programming/comments/azdd7/programmers_sit_your_butt_down_i_need_to_have_a/