Arka fon

İlk sınıf CS öğrencisiyim ve babamın küçük işletmeleri için yarı zamanlı çalışıyorum. Gerçek dünya uygulama geliştirme konusunda deneyimim yok. Python'da senaryolar yazdım, C'de bazı dersler yazdım, ama böyle bir şey yok.

Babamın küçük bir eğitim işi var ve şu anda tüm sınıflar harici bir web uygulaması aracılığıyla planlanıyor, kaydediliyor ve takip ediliyor. Bir dışa aktarma / "raporlar" özelliği var, ancak çok genel ve belirli raporlara ihtiyacımız var. Sorguları çalıştırmak için gerçek veritabanına erişimimiz yok. Benden özel bir raporlama sistemi kurmam istendi.

Benim fikrim jenerik CSV ihracat oluşturmak ve (muhtemelen Python ile) onları her gece ofiste barındırılan bir MySQL veritabanı içine almak, nerede gerekli belirli sorguları çalıştırabilirsiniz. Veritabanlarında deneyimim yok ama temelleri anlıyorum. Veritabanı oluşturma ve normal formlar hakkında biraz okudum.

Yakında uluslararası müşterilere sahip olmaya başlayabiliriz, bu yüzden eğer olursa / veritabanının patlamamasını istiyorum. Şu anda müşteri olarak farklı bölümlere sahip birkaç büyük şirketimiz var (örn. ACME ana şirketi, ACME sağlık bölümü, ACME vücut bakımı bölümü)

Ortaya koyduğum şema şudur:

1. Müşteri açısından:
   • Müşteriler ana tablodur
   • Müşteriler çalıştıkları bölümle bağlantılıdır
     • Departmanlar bir ülkeye dağılabilir: Londra'da İK, Swansea'da Pazarlama vb.
     • Bölümler bir şirketin bölümüyle bağlantılıdır
   • Bölümler ana şirkete bağlıdır
2. Sınıflar açısından:
   • Oturumlar ana tablodur
     • Her oturuma bir öğretmen bağlanır
     • Her oturuma bir statusid verilir. Ör 0 - Tamamlandı, 1 - İptal Edildi
     • Oturumlar isteğe bağlı boyutta "paketler" halinde gruplanır
   • Her paketler bir istemciye atanır

Şemayı bir kağıda "daha çok karalanmış gibi" tasarladım ve 3. forma normalleştirmeye çalıştım. Daha sonra MySQL Workbench'e bağladım ve hepsini benim için güzelleştirdi:
( Tam boyutlu grafik için buraya tıklayın )

_{(kaynak: maian.org )}

Çalıştıracağım örnek sorgular

• Hala kredisi olan müşteriler etkin değil (gelecekte planlanan bir sınıfı olmayanlar)
• Müşteri / departman / bölüm başına katılım oranı nedir (her oturumdaki durum kimliği ile ölçülür)
• Bir öğretmen bir ayda kaç ders aldı
• Katılım oranı düşük olan müşterileri işaretleyin
• Bölümlerine katılanların katılım oranlarına sahip İK departmanları için özel raporlar

Soru (lar)

• Bu aşırı mı yoksa doğru yola mı çıkıyorum?
• Çoğu sorgu için birden fazla tabloya katılma ihtiyacı büyük bir performans isabeti ile sonuçlanacak mı?
• Muhtemelen ortak bir sorgu olacak gibi istemcilere bir 'lastsession' sütun ekledim. Bu iyi bir fikir mi yoksa veritabanını kesinlikle normalleştirmeli miyim?

Zaman ayırdığınız için teşekkürler

Sorularınıza daha fazla cevap:

1) Bu tür bir soruna ilk kez yaklaşan biri için hemen hemen hedeftesiniz. Bence bu soruya başkalarından gelen işaretçiler şimdiye kadar bunu kapsıyor. Aferin!

2 & 3) Alacağınız performans büyük ölçüde, özel sorgularınız / prosedürleriniz için doğru dizinlere ve daha da önemlisi kayıt hacmine sahip olmaya ve optimize etmeye bağlı olacaktır. Ana tablolarınızda bir milyondan fazla kayıttan bahsetmediğiniz sürece, performansın makul bir donanımda bir sorun olmayacağı konusunda yeterince genel bir tasarıma sahip olmaya devam ediyorsunuz.

Bununla birlikte, bu soru 3'ünüzle ilgilidir, sahip olduğunuz başlangıç ​​ile burada normalleştirme ortodoksisine performans veya hiper hassasiyet konusunda aşırı endişelenmemelisiniz. Bu, oluşturduğunuz, performans veya normalleştirmenin önemi açısından çok farklı bir profile sahip olan, işleme dayalı bir uygulama arka ucu değil, oluşturduğunuz bir raporlama sunucusudur. Canlı kayıt ve zamanlama uygulamasını destekleyen bir veritabanı, veri döndürmek için saniye süren sorgulara dikkat etmelidir. Rapor sunucusu işlevinin karmaşık ve uzun sorgular için daha fazla toleransı yoktur, aynı zamanda performansı artırma stratejileri de çok farklıdır.

Örneğin, işleme dayalı bir uygulama ortamında performans geliştirme seçenekleriniz, saklı yordamlarınızı ve tablo yapılarınızı nnci dereceye kadar yeniden düzenlemeyi veya az miktarda yaygın olarak talep edilen veriler için bir önbellek stratejisi geliştirmeyi içerebilir. Bir raporlama ortamında bunu kesinlikle yapabilirsiniz, ancak zamanlanmış bir işlemin önceden yapılandırılmış raporları çalıştırdığı ve depoladığı ve kullanıcılarınızın db katmanınız üzerinde hiçbir stres olmadan anlık görüntü verilerine eriştiği bir anlık görüntü mekanizması sunarak performans üzerinde daha da büyük bir etkisi olabilir. istek başına.

Tüm bunlar, oluşturduğunuz db'nin rolü göz önüne alındığında, hangi tasarım ilkelerinin ve hilelerin kullandığınızı farklılaştırabileceğini gösteren uzun soluklu bir rant. Umarım bu yardımcı olur.

Doğru fikre sahipsiniz. Ancak bunu temizleyebilir ve eşleme (* var) tablolarından bazılarını kaldırabilirsiniz.

Yapabileceğinizler Departments tablosunda CityId ve DivisionId ekleyin.

Bunun yanında her şeyin yolunda olduğunu düşünüyorum ...

Yapacağım tek değişiklik:
1- VARCHAR'ınızı NVARCHAR olarak değiştirin, eğer uluslararası olacaksanız, unicode isteyebilirsiniz.

2- Mümkünse int kimliklerinizi GUID (benzersiz tanımlayıcı) olarak değiştirin (bu sadece benim kişisel tercihim olabilir). Sonunda birden çok ortamınızın (dev / test / aşama / prod) olduğu noktaya geldiğinizi varsayarsak, verileri birinden diğerine taşımak isteyebilirsiniz. GUID Ids bunu önemli ölçüde kolaylaştırır.

3- Şirketiniz için üç katman -> Bölüm -> Bölüm yapısı yeterli olmayabilir. Şimdi, bu aşırı mühendislik olabilir, ancak bu hiyerarşiyi n derinlik düzeyini destekleyebileceğiniz şekilde genelleştirebilirsiniz. Bu, bazı sorgularınızı daha karmaşık hale getirecektir, bu nedenle ödünleşmeye değmeyebilir. Ayrıca, daha fazla katmana sahip olan herhangi bir müşteri bu modele kolayca "doldurulabilir" olabilir.

4- Ayrıca İstemci Tablosunda VARCHAR olan ve Durumlar tablosuna bağlantısı olmayan bir Durumunuz da vardır. Müşteri Durumunun neyi temsil ettiği konusunda biraz daha netlik bekliyorum.

Hayýr. Görünüţe göre iyi bir detayda tasarlýyorsunuz.

Ülkeler ve Şirketlerin tasarımınızdaki Şehirler ve Bölgeler gibi gerçekten aynı varlık olduğunu düşünüyorum. Ülkeler ve Şehirler tablolarından (ve Cities_Has_Departments) kurtulur ve gerekirse Şirketler tablosuna (veya yalnızca Özel Sektör / Kamu Sektöründen daha fazla seçenek varsa bir CompanyType sütunu) bir boole bayrağı IsPublicSector eklerim.

Ayrıca, Departmanlar tablosunu kullanımınızda bir hata olduğunu düşünüyorum. Departmanlar tablosu, her müşteri bölümünün sahip olabileceği çeşitli departmanlara referans olarak hizmet ediyor gibi görünüyor. Eğer öyleyse, DepartmentTypes olarak adlandırılmalıdır. Ancak müşterileriniz (sanırım katılımcılar) bir TYPE departmanına ait değil, bir şirketteki gerçek bir departman örneğine aitler. Şu anda olduğu gibi, belirli bir müşterinin bir yerlerde bir İK departmanına ait olduğunu bileceksiniz, hangisinin değil!

Başka bir deyişle, Müşteriler Divisions_Has_Departments olarak adlandırdığınız tabloya bağlanmalıdır (ancak yalnızca Departmanlar olarak adlandırırım). Bu durumda, veritabanında standart başvuru bütünlüğünü kullanmak istiyorsanız, Şehirler'i yukarıda tartışıldığı gibi Bölümlere daraltmalısınız.

Bu arada, zaten CSV'ler oluşturuyorsanız ve bunları bir mySQL veritabanına yüklemek istiyorsanız, LOAD DATA LOCAL INFILE en iyi arkadaşınızdır: http://dev.mysql.com/doc/refman/5.1/ tr / load-data.html . Mysqlimport da göz atmaya değer ve temelde yük veri dosyası etrafında güzel bir paket olan bir komut satırı aracıdır.

Çoğu şey zaten söylendi, ancak bir şey ekleyebileceğimi hissediyorum: genç geliştiricilerin performans konusunda biraz fazla endişelenmeleri oldukça yaygın ve tablolara katılma ile ilgili sorunuz bu yöne gidiyor gibi görünüyor. Bu, ' Erken Optimizasyon ' adı verilen bir yazılım geliştirme anti-modelidir . Bu refleksi aklınızdan çıkarmaya çalışın :)

Bir şey daha var: Gerçekten 'şehirler' ve 'ülkeler' tablolarına ihtiyacınız olduğuna inanıyor musunuz? Departmanlar tablosunda 'şehir' ve 'ülke' sütununa sahip olmak kullanım durumlarınız için yeterli olmaz mı? Örneğin, uygulamanızın şehirlere göre bölümleri ve ülkelere göre şehirleri listelemesi gerekiyor mu?

İş Zekası / Raporlama uzmanı ve strateji / planlama yöneticisi rolüne dayanan yorumları takip etmek:

1. Larry'nin yukarıdaki yönüne katılıyorum. IMHO, Çok fazla mühendislik değil, bazı şeyler biraz yersiz görünüyor. Basit tutmak için, müşteriyi doğrudan bir Şirket Kimliği, Departman Tanımı, Departman Tanımı, Departman Türü Kimliği, Bölüm Tipi Kimliği'ne etiketleyeceğim. Uzun vadeli tutarlılık için arama tablolarına ve dahili raporlama / analiz alanlarına referans olarak Bölüm Türü Kimliği ve Bölüm Türü Kimliği'ni kullanın.

2. Paketler tablosu "Kredi" sütununu içerir, bu aslında Müşteri taban tablosuna bağlı olmamalı, bu yüzden eğer birçok paket varsa gelecekteki sınıflar için ne kadar kredi borcu kaldığını görebilirsiniz? Uygulama, kireçle ilgilenebilir ve Müşteri tablosunda merkezi olarak saklayabilir.

3. Şirket bilgileri, açık adres / telefon / vb.Dahil olmak üzere daha birçok alanı kullanabilir. bilgi. Ben de D & B "DUNs" sütunları (Site / Şube / Ultimate) uzun vadeli eklemek için hazır olurdu, Dun ve Bradstreet (D&B) büyük bir şirket kataloğu var ve daha sonra yolda onların bilgileri çok yararlı bulacaksınız raporlama / analiz için. Bu, bahsettiğiniz çoklu bölüm sorunuyla ilgilenecek ve alt / bölüm / dallar / vb. İçin hiyerarşilerini toplamanıza izin verecektir. büyük kolordu.

4. Önceden paketlenmiş "raporlama" yazılımıyla daha hızlı ve çok daha az baş ağrısına neden olabilecek büyük bir geliştirme girişimi için kendinizi kurtarabilecek kaç kayıtla çalışacağınızı söylemezsiniz. Büyük bir veritabanı (<65000) satırla uğraşmıyorsanız, MS-Access, OpenOffice (Base) veya ilgili rapor / uygulama geliştirici çözümlerinin işe yaramadığından emin olun. Oracle'ın ücretsiz APEX yazılımını biraz kendim kullanıyorum, Oracle XE ücretsiz veritabanı ile birlikte geliyor, sadece kendi sitelerinden indir.

5. Raporlama bilgileri: büyük veritabanları için, genellikle iki veritabanı örneğiniz vardır a) her ayrıntılı kaydı kaydetmek için işlem veritabanı. b) ayrı bir makinede yer alan raporlama veritabanı (veri mart / veri ambarı). Daha fazla bilgi için Google'da hem Star Schema'da hem de Snowflake Schema'da arama yapın.

Saygılarımızla.

Sadece çoklu tablolara katılmanın bir performans isabeti yaratacağı endişesini gidermek istiyorum. Normalleşmekten korkmayın çünkü katılmanız gerekir. İlişkisel veri tabanlarında birleşimler normaldir ve beklenir ve bunları iyi idare edecek şekilde tasarlanmıştır. PK / FK ilişkilerini ayarlamanız gerekecektir (veri bütünlüğü için, bu tasarımda dikkate alınması önemlidir), ancak birçok veritabanında FK'ler otomatik olarak dizine eklenmez. Birleşimlerde kullanılacakları için, FKS'yi endeksleyerek başlamak isteyeceksiniz. PK'ler genellikle benzersiz olmaları gerektiğinden yaratılışla ilgili bir indeks alırlar. Veri ambarı tasarımının birleştirme sayısını azalttığı doğrudur, ancak bir raporda milyonlarca kayıt erişilinceye kadar genellikle veri depolama noktasına ulaşmaz. O zaman bile neredeyse tüm veri ambarları, verileri gerçek zamanlı olarak toplamak için bir işlem veritabanı ile başlar ve daha sonra veriler bir programda (gecelik veya aylık veya işin ihtiyacı ne olursa olsun) depoya taşınır. Rapor performansını iyileştirmek için daha sonra bir veri ambarı tasarlamanız gerekse bile bu iyi bir başlangıçtır.

Tasarımınızın ilk sınıf CS öğrencisi için etkileyici olduğunu söylemeliyim.

Fazla tasarlanmamış, bu şekilde soruna yaklaşacağım. Katılmak iyidir, çok fazla performans isabeti olmayacaktır (veritabanının normalleştirilmediği sürece önerilmemektedir!). Durumlar için, tabloyu optimize etmek için bunun yerine bir numaralandırma veri türü kullanıp kullanamayacağınıza bakın.

Eğitim / okul alanında çalıştım ve "oturumlar" dediğiniz şey (belirli bir kursun örnekleri) ile kursun kendisi arasında genellikle M: ​​1 bir ilişki olduğunu işaret ettiğimi düşündüm. Başka bir deyişle, kataloğunuz kursu sunar ("İspanyolca 101" ya da her neyse), ancak bir dönem boyunca iki farklı örneği olabilir (Smith tarafından öğretilen Tu-Th, Jones tarafından öğretilen Wed-Fri).

Bunun dışında iyi bir başlangıç ​​gibi görünüyor. Bahse girerim, müşteri alan adının ("istemcilere" giden grafikler) modellemiş olduğunuzdan daha karmaşık olduğunu görürsünüz, ancak size rehberlik edecek gerçek verileriniz oluncaya kadar bununla fazla uğraşmayın.

Aklıma birkaç şey geldi:

1. Tablolar raporlamaya yönelik görünüyordu, ama gerçekten iş çalıştırmıyor. Bir müşteri kaydolduğunda, aslında bir oturum listesine katılan müşteri için bir sipariş verileceğini ve bu siparişin bir şirketteki birden fazla çalışan için olabileceğini düşünüyorum. Bir "sipariş" tablosu gerçekten sisteminizin merkezinde olacak gibi görünüyor ve veri yakalama ve nihai raporlama. (İşletmeyi çalıştırmak için kullandığınız kağıt belgeleri, mantıksal eşleşme olup olmadığını görmek için veritabanı tasarımınızla karşılaştırın.)

2. Şirketler genellikle bölümlere sahip değildir. Çalışanlar bazen bölümleri / bölümleri değiştirir, hatta seansın ortasında bile. Şirketler bazen bölümler / bölümler ekler / siler / yeniden adlandırır. Tablolarınızın gerçek zamanlı olarak değiştirilebilecek içeriğinin sonraki raporlamayı / gruplandırmayı zorlaştırmadığından emin olun. Çok fazla tabloya bu kadar çok iletişim verisi bölündüğünde, raporlarınızı anlamlı ve kapsayıcı tutmak için çok katı veri girişi doğrulaması uygulamanız gerekebilir. Örneğin, yeni bir müşteri eklendiğinde, şirketinin / bölümünün / departmanının / şehrinin iş arkadaşlarıyla aynı değerlerle eşleştiğinden emin olun.

3. "Paketler" kavramı hiç belli değil.

4. Bunun küçük bir işletme olduğunu belirttiğiniz için, mevcut makinelerin hızı ve kapasitesi göz önüne alındığında performansın bir sorun olup olmayacağı şaşırtıcı olacaktır.