İlk önce Veritabanına Karşı İlk Kod

Çalıştığım yazılımı tasarladığımda ve oluşturduğumda, tipik olarak önce arka uç SQL tablolarını tasarlayıp yaratıyorum ve sonra gerçek programlamaya geçiyorum. Şu anda üzerinde çalışmakta olduğum proje beni şaşırtıyor. Bu muhtemelen iyi ve sağlam gereksinimlerin bulunmamasından kaynaklanıyor, ancak maalesef bu sefer yapabileceğim çok az şey var. Bu bir "sadece git başaralım" şeklinde bir durumdur .. ama dalıyorum.

İş akışımı kafasına çevirmeyi düşünüyorum ve ilk önce UI ve veri modeli sınıflarını oluşturmayı umuyorum, bu çalışmanın benim için veritabanı şemasının neye benzeyeceğini netleştireceğini umuyorum. Bu iyi bir fikir mi? UI ile sonuçlanacağım ve hala db'yi nasıl yapılandıracağım hakkında hiçbir fikrim olmadığı için gerginim.

Merak eden varsa, arka uç olarak SQL Server ve ön uç uygulama olarak MS Access kullanıyorum. (Erişim benim seçimim de değil ... bu yüzden lütfen ondan nefret etme.)

İlk olarak neyin geldiği, süreç veya bu işlem tarafından kullanılan veriler? Bunun bir tür "tavuk veya yumurta" sorusu olduğunu biliyorum, ancak yazılım durumunda, sürecin bu olduğuna inanıyorum.

Örneğin, yalnızca bellek içi kalıcılığa sahip (veya uygulaması kolay olan herhangi bir şey) olan tek bir kullanım vakasını uygulayarak veri modelinizi adım adım oluşturabilirsiniz. Temel varlıkları ana hatlarıyla belirtmek için yeterli kullanım şekli uyguladığınızı hissettiğinizde, bellek içi kalıcılığını gerçek bir veritabanı ile değiştirebilir ve daha sonra bir seferde bir kullanım durumunda olan şemayı iyileştirmeye devam edebilirsiniz.

Bu, odağı veritabanından alır ve problemin özüne taşır: iş kuralları. İş kurallarını uygulamaya başlarsanız, sonunda işletme tarafından hangi verilere gerçekten ihtiyaç duyulduğunu (bu arada Doğal Seçime çok benzeyen bir işlemle) bulacaksınız. Veritabanını modelleyerek başlıyorsanız, bu verinin gerçekten gerekli olup olmadığına (veya bu biçimde veya normalleştirme düzeyinde, vb.) Geri bildirim vermeden, ya da şema (işletme zaten çalışıyorsa, ağır geçiş prosedürleri gerektirebilir) veya uyumsuz veri modelini oluşturmak için iş kurallarında "geçici çözümler" uygulamanız gerekir.

TL; DR: Veritabanı işletmeye bağlı olarak belirlenir - bunlar tarafından tanımlanır. Onunla çalışan bir işleminiz olmadıkça verilere ihtiyacınız olmaz (bir rapor da bir işlemdir). Öncelikle süreci uygulayın, hangi verilere ihtiyaç duyduğunu bulacaksınız. İlk önce verileri modelleyin ve ilk modellendiğinde kaç tane varsayımın yanlış olduğunu saymanız mümkün olabilir.

Konunun biraz dışında ama çok önemli: Açıkladığım iş akışı, "İşe yarayabilecek en basit şey", test odaklı geliştirme ve mimarlığınızı ayrıntılardan ayırmaya odaklanma gibi çok önemli uygulamalarla birlikte kullanılır. istediğin gibi ol (ipucu: veritabanı). Sonuncusu hakkında, bu konuşma fikri oldukça iyi özetliyor.

Bir kök neden analizi, bu sorunun yöntemlerden biri olmadığını, ancak bir belirtimin bulunmadığını öne sürüyor. Bir olmadan ilk önce ne yazdığınızın önemi yoktur - yine de onu atacaksınız.

Kendinize bir iyilik yapın ve bazı temel sistem analizleri yapın - bazı kullanıcıları çeşitli düzeylerde tanımlayın, hızlı ve kirli bir anket yapın, ardından makinenizi kapatın, biraz kahve ve kurabiye / çörek alın (ya da tekerlekleri yağlayan her neyse) yürüyün. masalarını, ne yaptıklarını ve açık görünse bile işlerini yapmak için bilmeleri / kaydetmeleri gerekenleri sorun - hala sor. Ne kadar önemli oldukları konusunda endişelenmeyin, eğer çok meşgullerse, başka bir zaman geri gelmek veya onlarla bırakmak için bir düzenleme yapın.

Bunu yaptıktan sonra, size en iyi sonuçları vereceğini düşündüğünüz neyse onu oluşturmaya başlayabilmeli ve şartnamenin geri kalanını beklemelisiniz.

Benim deneyimim şu şekilde:

• Çalıştığım çoğu projede önce veritabanını tasarladık.
• Genellikle, elektronik tablolarda, eski veritabanlarında, kağıt vb. Veriler zaten mevcuttur. Bu veriler, tutmanız gereken tablolar hakkında ipuçları verir.
• Çoğu zaman bir işlem zaten kullanılıyor, ancak manuel olarak veya otomatik olmayan, birlikte çalışmayan ve / veya standartlara uymayan birkaç ayrı araç kullanıyor.
• Yarı olgun bir veritabanı modeline sahip olduğunuzda, bu veritabanını okuyan ve yazan prototip formları, pencereler vb. Tasarlamaya başlayabilirsiniz.
• Siz devam ettikçe, başlangıçta düşünülmeyen şeylere uyum sağlamak için bazı değişiklikler yapılması gerekecektir.

Ayrıca unutmayın:

• Artık bir tek uygulama <-> tek veritabanı dünyası değil. Belki de uygulamanız birden fazla veritabanından veri okumak veya yazmak zorunda kalacaktır veya çözümünüz aynı veritabanını kullanan birden fazla uygulamayı içerecektir.

Sonuç: İlk önce veri tabanını tasarlamanızı tavsiye ederim.

Veritabanını ilk olarak söyleyecektim çünkü büyük projelerle ilgili çok fazla tecrübem var ve paralel olarak çalışan birçok geliştiriciniz varsa gerçekten sağlam bir veri modeline ihtiyacınız var.

Ama sonra biraz daha fazla düşündüm ve daha başarılı olan büyük projelerde gerçekte yaptığımız şeyin "ilk şartlar" olduğunu anladım.

İyi tanımlanmış bir dizi iş gereksinimi, iyi bir dizi işlevsel gereksinime yol açar. İyi bir işlevsel gereksinimleriniz varsa, veri modeli ve modül özellikleri çok fazla çaba harcamadan yerine geçer.

Bu çok akıcı / belirsiz göründüğü için ilk önce GUI'yi yapardım - bu, paydaşlardan yanıt, destek, zaman ve geri bildirim almanız için ihtiyacınız olana benziyor, değil mi? Mükemmel normalleştirilmiş masalarınız ve yabancı anahtar kısıtlamalarınız ve geçişli silmeleriniz umrunda değil. Ama çok parlak renkler ile serin bir GUI - işte en üst seviye!

İlk arka uç "veritabanı" için son derece basit bir şey kullanın, belki de sadece bir dosyaya kaydedilmiş anahtarlar / değerler. MS Access'e aşina değilim, bu yüzden "en hafif" arka uç ne olacağını bilmiyorum. (Bir hesap makinesi tablosu?) Hızlı ve kirli ne varsa, onu atmayı planlayın.

Yapabiliyorsanız, bir prototip olduğunu açıkça belirtmek için GUI'de komik bir görünüm kullanın . Hepsi başarısız olursa, dizin kartlarını kullanın.

Şimdi, belki de paydaşlarınız DB uzmanlarıdır - bu bazen bende böyle oldu! - bu durumda, bazı DB tasarımları yapın.

Gereksinimler açık olmadığı için, ihtiyaç duyacağınız temel unsurlar ile çok basit bir veri modeliyle başlayabilirsiniz, belki sadece temel tabloları ve PK'ları başlatmak için. Verilerin geri kalanı, ikili ya da XML ile seri hale gelir ve BLOB ile başlamak üzere veritabanında depolanır. Bu, tamamen ilişkisel bir model olmadan kullanıcı arayüzünü ve işletme katmanını (orta seviye) geliştirmeye izin vermelidir, ancak gerektiğinde kaydetme ve alma ve basit anahtar aramaları yapmaya devam edemezsiniz.

Örnek olarak, belki bir kişiliğiniz vardır, bu yüzden bir kimliğe sahip bir kimliğiniz vardır. Özniteliklerin geri kalanı bilinmemektedir, bu yüzden sadece PK Kişi Kimliği olan bir Kişi tablosu ve tüm kişi verilerini içeren Blob'u depolayacak başka bir sütunla başlayın.

Gereksinimler katılaşınca, Blobs'unuzu alın ve gereken tüm tabloları ve sütunları çıkartın ve modeli ilişkisel hale getirin. Öyleyse, bir BLOB'dan veri erişim katmanındaki ilişkisel seviyeye olan direncin değiştirilmesi meselesi. Ancak diğer her şey, işletme kuralları kullanıcı arayüzü vb. Not, bu projeye biraz zaman kazandırır, ancak işler daha sıkı hale gelinceye kadar ilişkisel modeli değiştirmeden gerekenleri eklemek ve bırakmak için tam bir esneklik sağlar.

Bir BLOB'u sorgulayamadığınız için arama gecikebilir, böylece model stabilize olur, aranması gereken verileri ilişkisel sütunlarda depolamaya başlayın.

Temel olarak tablo modeliyle başlar ve proje ilerledikçe ilişkisel bir modele geçersiniz.

Veya, herhangi bir işe başlamadan önce gereklilikleri yerine getirin, böylece başlangıçta ilişkisel bir model geliştirilebilir.

Genel olarak kod veriden sonra gelir çünkü kod veriyi değiştirir.

Gereksinimler net değilse, gereksinimleri yorumlamanızın bir veri modelini oluşturabilirsiniz. En iyisi, belki bazı gereklilikleri yazıp işvereninize göndermektir, daha sonra ateş edecekleri bir şey vardır. Ya da önce bir gui oluşturun, bu en iyi işveren türüne bağlıdır :)