Veritabanını tasarlamak programcıların işi midir?

Son altı yıldır programcıyım. Kariyerim boyunca birçok web uygulaması üzerinde çalıştım.

Çoğu zaman, bir veritabanına ihtiyaç duyulduğunda, bize (programcılar) verildi ya da üzerinde çalışmak için bazı eski veritabanlarımız vardı. Değilse, o kadar da zor olmayan kendi başımıza veritabanı oluşturmak ve tasarlamak zorundaydık.

Ancak, programcılar olarak, verilerin çok önemli olduğu ve karmaşık bir veri modeliyle dağınık gereksinimlerin olduğu yeni bir uygulama oluşturmamız gerektiğinde tüm veritabanını sıfırdan oluşturmamız gerekiyor mu?

Bir uzman tarafından yapılması uygulamanın ve şirketin çıkarına değil mi?

Ben veritabanı tasarımı kaçmak için çalışmıyorum, ama doğru almak için çok önemli bir şey.

Her şeyden önce, proje yöneticisi size söylerse sizin işiniz. Küçük şirketlerin genellikle tam zamanlı DB uzmanları yoktur. Zaten geliştiriciler ve DB uzmanları arasında net bir ayrım yoktur (ve olmamalıdır) - herhangi bir iyi geliştirici DB'ler hakkında önemli bilgiye sahip olacaktır ve iyi bir DBA en azından DB'nin dilinde saklı prosedürler için nasıl kodlanacağını bilecektir. .

DB tasarımı bir uygulamanın oldukça merkezi bir parçası olmakla birlikte, diğer kodların çoğunun bağlı olacağı diğer merkezi parçalardan daha "doğru" olmak artık önemli değildir.

Ve tıpkı kod gibi, bir hafta boyunca oturmak ve çok düşünmek ve daha sonra asla değişmesi gerekmeyen mükemmel tasarımı yazmak için bazı süper uzmanlar edinmeniz bir yanılsamadır. DB tasarımı uygulama geliştirildikçe değişebilir ve değişecektir.

Bu nedenle, DB'nin bir programcı tarafından tasarlanması (DB'leri iyi anlayan) gerçekten yararlıdır, çünkü o zaman her iki tarafı da bilen birisine sahipsiniz. Bu, sadece DB'leri anlayan ve geliştirme çalışmalarının geri kalanıyla hiçbir ilgisi olmayan biri tarafından yapılmasından kesinlikle daha iyidir.

Programcıların veritabanını oluşturması yaygındır. Çok yaygın. Ne yazık ki birçok programcı DB konusunda deneyim sahibi değildir. Büyük verilere, veri marjı kavramlarına, yıldız şemalarına vb. Karşı nasıl bildirimde bulunacaklarını anlamıyorlar.

Bir adam her şeyi uzman düzeyinde yapma becerisine sahipse, çok iyi bir ürün yapar. Tek kişilik bir ordu, 10 kişilik bir ekibin zamanın bir kısmında 1000 kat kalite ile yapabildiklerini yapabilir. Abartı değil.

Programcının ne yaptığını bildiği varsayılarak, programcının bunu yapması en az ilgi çekicidir (daha az insan). Tabii ki binlerce başarısızlık da var.

Bu ilginç bir soru - çoğu iyi geliştiricinin ilişkisel bir veritabanını nasıl doğru bir şekilde yapılandıracağını, yani normalize edilmiş bir şema üretebilmeleri ve - deneyime ve ortak kalıplara dayalı olarak - makul hale getirebilmeleri gerektiğini anlaması gereken güçlü bir argüman var. verilerin nasıl yapılandırılacağına dair kararlar (benim için çoğunlukla kendiliğinden belirgindir, ancak herkesin bu şekilde görmediğini biliyorum).

Ayrıca, önce düşük düzeyli bir veri modeli oluşturmaya yönelik aynı düşüncenin makul bir şema oluşturacağını veya en azından bir ipucu vereceğini öne süren Varlık Çerçevesi Koduna bakarsanız.

Yani hayır, özellikle bir veritabanı şeması tasarlamak için bir veritabanı uzmanına ihtiyacınız olduğunu düşünmüyorum - en azından küçük ve orta boyutlu veritabanları için (üzerinde çalıştığım şeyler).

Mesele, iyi (veya en azından yeterli) bir şema tasarlamanın tüm öykü olmamasıdır - özellikle veritabanının ölçeklenmesi gerekiyorsa değil. Bana öyle geliyor ki, bir DBA tarafından getirilen "katma değer" temel şema hakkı - dizinler, depolama yapılandırması, veritabanının bakımı (dosya boyutlarının kontrol altında tutulması, dizinlerin yeniden oluşturulması, vb.) Dışındaki şeyleri daha akıllı hale getirmektir. kullanıcılar ve roller vb.

İyi bir programcı farklı bir beceri portföyü getirmelidir - bir [seçim dili ekleyiniz] kodlayıcıdan daha fazlası olmalı ve ben bu portföydeki veritabanlarının anlaşılmasını da dahil etmeliyim.

Makul bir ilişkisel veritabanı tasarlama yeteneğinin aslında genç olmayan programcılar için bir zorunluluk olduğunu düşünüyorum.

Bununla birlikte, özellikle büyük uygulamalar için, veritabanını ilk kez "doğru" (şema, indeksleme vb.) Almak çok önemlidir. Şirketin yetenekli bir DBA'ya erişimi varsa, bu görev plakalarına düşmelidir; genel olarak daha nitelikli olurlar. Potansiyel olarak gözden geçirme / tartışma, müşteri tarafında veritabanına erişecek ve onunla birlikte çalışacak baş geliştirici ile yapılmalıdır, böylece sürpriz olmaz. DBA yoksa, programcı veritabanını tasarlar.

Burada iki soru görüyorum:

• Veritabanı geliştiricileri iş mantığını modellemeli mi?
• Veritabanında nasıl veri kaldığını bilmeli miyim?

İş mantığı

• İş mantığı bir veritabanında yaşamıyor. Sisteminizdeki diğer katmanlardan bağımsız olması gereken kavramsal bir modeldir.

• Her zaman bir veritabanını başka bir veritabanıyla değiştirebilir veya potansiyel performans sorunlarını gidermek için NoSQL çözümleri kullanmaya bile karar verebilirsiniz.

• Veritabanı geliştiricileri modelleme sürecinde yer alabilirler, ancak normalde bu, sorunlu bir etki alanını tam olarak bilen kişiler tarafından yapılır. Kuruluşumuzda bu, sunucu tarafı geliştiriciler tarafından yapılır.

• Birçoğu, veritabanının uygulamanızın temeli olduğunu düşünüyor. Kötü bir temel oluşturun ve sistem düşecek. Buna katılmıyorum. Veritabanını her zaman değiştirilebilecek bir depolama ortamı olarak görüyorum.

Kalıcı Veriler

• Verileri SQL ve NoSQL çözümleri de dahil olmak üzere farklı depolama ortamlarına nasıl kalıcı tutacağınızı bilmelisiniz.

• Gerekli uzmanlık düzeyi üzerinde çalıştığınız sistemin boyutuna göre değişir.

• Küçük şirketler, büyük şirketlerin normalde performans, ölçeklenebilirlik ve güvenlikle ilgili gereksinimleri ele almak için uzmanları işe aldığında bu bilgiye sahip olmanızı bekler.

Özetle:

• Etki alanı modeli, veritabanınızın değil, sisteminizin temelidir.

• Küçük bir şirket için nispeten küçük bir projede çalışıyorsanız, muhtemelen veritabanını kendiniz tasarlamalısınız.

• Bir işletme sisteminde büyük bir şirket için çalışıyorsanız, alan adı uzmanlarına iş vermek muhtemelen daha mantıklıdır.