Uygulama kodu yazılmadan önce veritabanını tasarlamalısınız?

Veritabanını tasarlamanın en kolay ve en etkili yolu nedir? Benim açımdan, bir uygulamanın veri deposu tasarımı için birkaç seçenek var:

1. Herhangi bir uygulama kodunu yazmadan önce veritabanını en iyi şekilde tasarlayın . Bu size çalışmak için temel bir veri yapısına sahip olmanın avantajını sağlar. Bunun dezavantajı, benim görüşüme göre, uygulama geliştirme döngüsü boyunca verilerin ne / nerede / nasıl değiştiğini etkileyen uygulama spesifikasyonları olarak birçok değişikliğe sahip olacağınızdır .
2. Uygulama meyve vermeye gelince veritabanını tasarlayın . Uygulamayı yazarken bazı veritabanı nesnelerine ihtiyaç duyduğunuzda, veritabanını uygulamaya (kronolojik olarak) paralel olarak geliştirirsiniz. Avantajları, gördüğüm gibi veritabanı yapısında daha az değişiklik yapılması. Dezavantajı, uygulama kodu ile veritabanı geliştirme arasındaki zaman ve geliştirme çabasının ayrılması olacaktır.

Tecrübelerinize göre, en verimli ve verimli yöntem ne buluyorsunuz?

Diğer cevaplara ek olarak ...

Kavramsal modelinizi önce yakalamak, kapsamı ve gereksinimleri tanımlamalıdır. Bundan mantıklı ve fiziksel veri modellerinizi türetebilirsiniz.

Bu çoğunlukla statik olduğunda, uygulamanızı karşı oluşturmak için sağlam bir veritabanınız olur. Bu ilk seçeneğinize aykırı.

İkinci noktan dağınık, sürdürülemez bir çamur topuyla sonuçlanacak . Veri modeli hiçbir zaman sabitlenmez: önceden tasarlamadıysanız, göndermeden önce düzeltmek için zamanınız olmaz. Birlikte bir şeyler kırmakla meşgul olacaksın.

Şema üzerinde küçük değişiklikler yapılması, tabloların birleştirilmesi veya bölünmesi, ilişkilerin değiştirilmesi vb. Gerçekleşecek, ancak yerel "adalarda" ve modeliniz + temel tasarımınız değişmeyecek.

Agile'nin bir türevini çalışmayan herhangi bir modern yazılım bölümünü bulmakta zorlanacaksınız. DBA’nın karşılaştırması karanlık çağlarda kaldı, @ RobPaller'in cevabının hala ortak bir yer içerdiğini düşünmek gibi.

Bir veritabanı şemasını değiştirmek hiçbir zaman kodu değiştirmek kadar kolay olmamıştı, bu nedenle veritabanı geliştirme ve bakımına çevik bir yaklaşım benimseme konusunda gönülsüzlük yaşandı. Şimdi, geliştiricilere benzer şekilde çalışacak araç ve tekniklere sahip olduğumuzdan, kesinlikle yapmalıyız. Sadece şemayı değiştirmek kolay olmadığı için yapamayacağın ve yapmaman gerektiği anlamına gelmez.

Veri tabanı tasarımına tesadüfi bir yaklaşımı (yorumlara bakın), sadece çevik bir geliştirme ekibinin fikrini daha yakından yansıtan bir yaklaşımı savunmuyorum. Çevik bir projenin parçasıysanız , gelecekte meydana gelebilecek ( veya olmayabilecek ) iş gereksinimlerine sahip olmayacaksınız , bu nedenle ne olabileceğinizi değil, ihtiyaç duyduğunuz şeyi tasarlayın.

Sanırım bu senin ikinci seçeneğinle oyumu koyuyor ve bu konuda kendimi soğukta beklediğimi sanıyorum!

Mantıksal veri modeliniz, uygulamanızın iş gereksinimlerini etkili bir şekilde yakalamalıdır. Fiziksel veritabanı tasarımınız, RDBMS'nizin verimliliğini en üst düzeye çıkarmak için DBA olarak ihtiyaç duyduğunuz gerekli değişiklikleri içeren birleşik mantıksal veri modeline dayanmalıdır.

Uygulamanızın yazılım geliştirme yaşam döngüsü boyunca temel veritabanı tasarımında sayısız değişiklik yapmanız gerektiğini tespit ediyorsanız, bu iki şeyin göstergesidir:

1. Kapsamın sürünmesi - Uygunsuz bir zamanda yeni gereksinimlerin ortaya çıkmasına izin veriyorsunuz.
2. Yetersiz İş Gereksinimleri - Veri modelleyicileriniz (veya sistem analistleri), gereksinimleri iş analistlerinden yeterince çevirmedi. Bu, uygulamanızın gereksinimlerini desteklemek için eksik veya hatalı bir veri modeliyle sonuçlandı.

Bir uygulama üretime geçtikten sonra, uygulamanın veya temeldeki iş süreçlerinin doğal evrimini desteklemek için geri dönüp veri modelinde yinelemeli değişiklikler yapmak zor değildir.

Bu yardımcı olur umarım.

Tümü işletmelerde kullanılan, web, Access ve C # gibi çeşitli ön uçlara sahip, orta-karmaşıklıkta veri tabanları tasarlama lüksüne sahibim.

Genellikle oturdum ve veri tabanı şemasını önceden hazırladım. Bu bana her zaman en mantıklı geldi. Ancak, değişiklik yapma, yeni tablolar ekleme ya da beni rahatsız eden ve düzeltmek için çok geç kaldığım yönlerle yaşamaya başlamadığım tek bir durum olmadı.

İlk önce tedavinin kodu yazmak olduğunu sanmıyorum. Ve sorunun "yetersiz iş gereksinimi" olduğunu ya da en azından tam olarak çözülebilecek bir sorun olduğunu sanmıyorum. Kullanıcılar neye ihtiyaçları olduğunu bilmiyor ve daha zor veya daha akıllı veya daha bilinçli olmalarını ya da sorularıma daha iyi cevap vermelerini sağlayacak güce sahip değilim. Ya da tartışırlar ve belirli bir şeyi yapmam emredildi.

Yaptığım sistemler genellikle daha önce kimsenin girmediği yeni alanlarda. Ekip olarak yaptığım işin on katı bir ekip olarak ödeme yapan üst düzey tasarım profesyonellerinden oluşan bir geliştirme ekibinin yapabileceği türden bir organizasyondan, kaynaklardan ya da araçlardan almıyorum. zamanın iki katı.

Yaptığım işte iyiyim. Ancak bunu, "gelişim yapmayan" bir ortamda yaptığım sadece bir tane var.

Bütün bunlar, iş kurallarını keşfetme konusunda daha iyi olacağımı söyledi. Ve bir tür üçüncü seçenek görüyorum:

Veritabanını tasarlamadan önce ve herhangi bir kod yazmadan önce, uygulamanın nasıl çalışacağını gösteren ham ekranlar çizin. Herhangi birinin font veya boyut veya boyutlar hakkında yorum yapmasını engellemek için elle çizilmiş olmaları gerekir - yalnızca işlev istersiniz.

Asetat ve kağıt parçalarıyla takas edebildiğiniz, bir kişi bilgisayar, ikisi teknik olmayan konu uzmanı kullanıcılar (ikisi yüksek sesle konuşurlar) ve biri not alan ve çizen kolaylaştırıcı olarak bir kişi olsun Kullanıcıları düşünce süreçleri ve kafa karışıklıkları hakkında bilgilendirmek Kullanıcılar "tıklar" ve kutulara sürükleyip yazarlar, "bilgisayar" ekranı günceller ve herkes tasarımı yaşar. Başka türlü öğrenemediğiniz şeyleri gelişim sürecine kadar öğreneceksiniz.

Belki de kendimle çelişiyorum - belki de daha iyi gereksinimlerin keşfidir. Ancak fikir, herhangi bir kod yazmadan önce uygulamayı tasarlamaktır. Bunu küçük çapta yapmaya başladım ve işe yarıyor! Ortamımdaki sorunlara rağmen, baştan daha iyi tasarlanmış veritabanını edinmeme yardımcı oluyor. Bir sütunun yeni bir ana tabloya taşınması gerektiğini öğrendim çünkü çoklu tipler var. İş listesinin, entegre sipariş sisteminden gelmeyen duran emirlere sahip olması gerektiğini öğrendim. Her türlü şeyi öğreniyorum!

Bence bu büyük bir kazanç.

Çoğu amaç için Seçenek 2'yi seçerdim: Veritabanını diğer bileşenlerle paralel olarak oluşturun. Mümkün olan her yerde, yinelemeli bir yaklaşım benimseyin ve her parçayı oluştururken uçtan uca işlevsellik sağlayın.

Bu, belli miktarda proje disiplini gerektirir. Kaliteyi korumak ve geçici ve tutarsız bir model ile sonuçlanmamak için veritabanını her değiştirdiğinizde, normalizasyonu sıkı bir şekilde (Boyce-Codd / Fifth Normal Form) uygulayın. İş kuralları ve görevli veritabanı kısıtlamaları ile mümkün olduğunca agresif olun. Şüphe durumunda, bir kısıtlamayı erken uygulamak daha iyidir - bunu daha sonra her zaman kaldırabilirsiniz. Teknik borçları en aza indirgemek için mimari bileşenleri uyguladığınız sırada akıllı olun. Tüm dev ekibinin satın aldığı iyi bir veritabanı tasarım kurallarına sahip olun.

Tüm bunlar elbette diğer iyi geliştirme mühendisliği uygulamalarıyla el ele gitmeli: sürekli entegrasyon, test otomasyonu ve kritik olarak veritabanı perspektifinden test verileri oluşturma. Test verilerinin gerçekçi boyutta veri oluşturulması, her yinelemede hatasız olarak yapılmalıdır.

Mimarlık dünyasında, "Form Follows Function" ibaresi oluşturuldu ve daha sonra yüksek binalar inşa edilirken uygulandı. Aynı DB altyapısı ve uygulama geliştirme için de uygulanmalıdır.

Burada bir masaya ve orada bir masaya ihtiyacınız olduğuna karar vererek bir uygulama yazdığınızı hayal edin. Uygulamanız bittiğinde, dizi olarak değerlendirilen çok sayıda tabloya sahipsiniz. Tüm masalara yan yana baktığımızda, masaların kesinlikle kafiye ya da sebeplere sahip olmadığı görülecektir.

Ne yazık ki, bazı geliştirici dükkanları memcached gibi bir şey alacak, verileri RAM'e yükleyecektir (böylece bir veri kanalı gibi davranacak) ve MySQL veya PostgreSQL gibi bir veritabanına basitçe bir veri depolama birimi gibi davranacaktır.

Bir veritabanı kullanma teşviki, doğru bir şekilde bakmak olmalıdır: RDBMS olarak. Evet, İlişkisel Veri Tabanı Yönetim Sistemi. Bir RDBMS kullandığınızda, hedefiniz yalnızca hedef depolama için değil, aynı zamanda erişim için tablolar oluşturmak olmalıdır. Tablolar arasındaki ilişkiler, görmek istediğiniz verilerden ve nasıl sunulduğundan sonra modellenmelidir. Bu, verilerin bilinen iş kuralları ile birlikte tutarlılığı ve bütünlüğüne dayanmalıdır. Bu iş kuralları uygulamanızda (Perl, Python, Ruby, Java vb.) Veya veritabanında kodlanabilir .

SONUÇ

Kesinlikle seçenek 1 ile gitmek istiyorum. Bu uygun planlama, veri modelleme ve devam eden veri analizi alır. Ancak, bu uzun vadede veritabanı değişikliklerini en aza indirmelidir.

Uygulama için gerçek bir kod olmadan önce yapılması gerekiyor , ancak uygulama tasarlanmadan önce yapılması gerektiğini düşünüyorum .

Tipik iş akışım, eğer yalnız çalışıyorsanız:

1. Uygulamanın ne yapması gerektiğini belirleme
2. Yeniden kullanılabilir bileşenler için görevlerden herhangi birinin bozulup kırılmadığını görmek için bakın.
3. Her görevin veri depolama alanıyla nasıl etkileşime girmesi gerektiğini belirleyin - veri hakkında ne tür sorular soracakları, ne sıklıkta yazacakları vs.
4. Veritabanını, sormamız gereken tüm soruları cevaplayabilmesi ve en sık yapılan işler için iyi performans gösterebilmesi için tasarlayın.
5. Uygulamayı yaz.

Sık sık bir ekibin parçası olarak çalıştığım ve coğrafi olarak dağınık olduğumuz (ve zaman dilimleri arasında) olduğum için, ilk başlama toplantısına çıkma eğilimindeyiz:

1. Uygulamanın ne yapması gerektiğini belirleyin.
2. Uygulamanın kendi kendine yeten bileşenlere bölüneceği iyi noktaların nerede olduğunu belirleyin.
3. Her bileşenin diğerleriyle nasıl etkileşime girmesi gerektiğini belirleyin.
4. Etkileşimlerin her biri için bir API üzerinde anlaşın.

Sonra eve geri dönüyoruz, bizim parçamızı yazıyoruz ve eğer bir bileşen kendi yerel deposuna ihtiyaç duyuyorsa, söz konusu parça için API API'yi modüllerinde tutarlı tuttuğu sürece. Ana veri depolama, kendi API'sine sahip bir modül olarak ele alınır ve insanların buna yazması beklenir. (DB hızının kritik olduğu durumlarda, API tablo tanımlarıdır ve değişiklikler yapılırsa, tüm modüller güncellenene kadar eski sürümü sunmak için görünümler veya başka bir mekanizma kullanırız)

Follwing kuralını aklımda tutuyorum: "sadece veri tabanından elde edeceğiniz bilgileri veri tabanından alabilirsiniz". Bu yüzden önce veritabanını koddan sonra tasarlarım.

Neden? Hangi metodoloji / dil / araç setini kullanırsam kullanın, bütün ilgili veriler iyi tasarlanmış ve DB içinde depolanmışsa onu alabilirim. C # / Delphi / FORTRAN / COBOL / Assembly / VBA veya Crystal Reports içinde olursa olsun; OO tasarlanmış veya olay / veri / ne olursa olsun yönlendirilen; çevik veya şelale. Veriler oradaysa, kullandığım araçlar veritabanına bağlanabiliyorsa onu alabilirim. Çeyrek dönem gelir siparişlerini SEÇEBİLİRsem satış raporlarını oluşturabilirim - Meclise byte byte yazmak zorunda olsam bile.

İlgili veriler orada değilse veya orada olsa bile (un) yapılandırılmış bir şekilde ihtiyacım olan bilgiyi alamıyorum - nasıl kodlanır?

Genellikle, bağlıdır;)

Örneğin, Python'da geliştirilen ve düz dosyalar kullanan küçük boyutlu bir çalışma prototipine sahip olduğumuzu ve kullanıcıların prototipin özelliklerinden memnun olduklarını varsayalım. . Bu durumda, ilk defa doğru yapmayı beklemek mantıklıdır - sorun küçük ve iyi tanımlanmıştır. Bu gibi durumlarda ön tasarımı yapılabilir.

Öte yandan, Çevik bir ortamda gereksinimleri keşfettiğimiz zaman, onları daha iyi anlamak için birkaç tekrarlamaya ihtiyacımız var. Bu gibi durumlarda, veritabanı uygulamanın geri kalanıyla birlikte gelişir. Genelde yaptığımız şey budur. Herhangi bir kesinti olmadan ve düşük riskli OLTP masalarını canlı olarak yeniden düzenleyebildiğimiz için, veritabanı yeniden yapılandırma olasılığı konusunda rahatız.