Masz dobry pomysł. Można go jednak wyczyścić i usunąć niektóre tabele mapowania (has*).

Możesz to zrobić w tabeli departamenty, dodać CityId i DivisionId.

Poza tym, myślę, że wszystko jest w porządku...

Jedyne zmiany jakie bym wprowadził to:
1-Zmień swój VARCHAR na NVARCHAR, jeśli możesz być Międzynarodowy, możesz chcieć unicode.

2-Zmień swój int id na GUIDs (uniqueidentifier) jeśli to możliwe (może to być tylko moje osobiste preferencje). Zakładając, że w końcu dojdziesz do punktu, w którym masz wiele środowisk (dev/test/staging/prod), możesz chcieć przenieść dane z jednego do drugiego. Posiadanie identyfikatorów GUID znacznie to ułatwia.

3-trzy warstwy dla Twojej firmy -> dział -> struktura Działu może nie wystarczyć. To może być zbyt inżynierskie, ale możesz uogólnić tę hierarchię tak, że możesz wspierać n-poziomy głębokości. Spowoduje to, że niektóre z Twoich zapytań będą bardziej złożone, więc może to nie być warte kompromisu. Co więcej, może być tak, że każdy klient, który ma więcej warstw, może być łatwo "zapchany" do tego modelu.

4-masz również Status w tabeli klienta, który jest VARCHAREM i nie ma linku do statusów stolik. Oczekuję większej jasności co do statusu klienta.

Nie. Wygląda na to, że projektujesz na dobrym poziomie szczegółowości.

Myślę, że kraje i firmy są naprawdę tym samym podmiotem w Twoim projekcie, podobnie jak Miasta i podziały. Chciałbym pozbyć się tabel krajów i miast (i Cities_Has_Departments) i, jeśli to konieczne, dodać flagę boolean ispublicsector do tabeli firm (lub kolumna CompanyType, jeśli jest więcej opcji niż tylko sektor prywatny / Sektor publiczny).

Ponadto, myślę, że jest błąd w używaniu tabela wydziałów. Wygląda na to, że tabela działów służy jako odniesienie do różnych rodzajów działów, które może mieć każdy dział klienta. Jeśli tak, to powinien być nazywany Departmenttypy. Ale twoi klienci (którzy są, zakładam, uczestnikami) nie należą do typu działu, należą do rzeczywistej instancji działu w firmie. W obecnym stanie będziesz wiedział, że dany klient należy gdzieś do działu HR, ale nie do którego!

Innymi słowy, klienci powinni być połączone z tabelą, którą nazywasz Divisions_Has_Departments (ale którą nazwałbym po prostu departamentami). Jeśli tak jest, musisz zwijać miasta na podziały, jak omówiono powyżej, jeśli chcesz użyć standardowej integralności referencyjnej w bazie danych.

Przy okazji, warto zauważyć, że jeśli już generujesz CSV i chcesz załadować je do bazy danych mySQL, LOAD DATA LOCAL INFILE jest twoim najlepszym przyjacielem: http://dev.mysql.com/doc/refman/5.1/en/load-data.html . Mysqlimport jest również warte przyjrzenia się i jest narzędziem wiersza poleceń, które jest w zasadzie ładnym opakowaniem wokół pliku ładowania danych.

Większość rzeczy już zostało powiedziane, ale czuję, że mogę dodać jedną rzecz: jest to dość powszechne dla młodszych programistów martwić się o wydajność trochę zbyt dużo z góry, a twoje pytanie o dołączanie tabel wydaje się iść w tym kierunku. Jest to anty-wzorzec rozwoju oprogramowania o nazwie " przedwczesna Optymalizacja ". Spróbuj wypędzić ten odruch z umysłu:)

Jeszcze jedno: czy uważasz, że naprawdę potrzebujesz tabel "miasta" i "kraje"? Nie mając kolumna "miasto" i "kraj" w tabeli departamentów wystarczy dla Twoich przypadków użycia? Np. czy Twoja aplikacja musi wyświetlać działy według miasta i miast według kraju?

Następujące komentarze oparte na roli Business Intelligence / Reporting specialist I strategy / planning manager:

1. Zgadzam się z kierunkiem Larry ' ego powyżej. IMHO, to nie jest aż tak przesadzone, niektóre rzeczy po prostu wyglądają trochę nie na miejscu. Aby to uprościć, oznaczałbym klienta bezpośrednio do identyfikatora firmy, opisu działu, opisu działu, identyfikatora typu działu, identyfikatora typu działu. Użyj identyfikatora typu Działu i identyfikatora typu działu jako odniesień do tabel wyszukiwania i wewnętrzne pola raportowania/analizy dla długoterminowej spójności.

2. Tabela pakietów zawiera kolumnę "Credit", czy to nie powinno być powiązane z tabelą bazy klientów, więc jeśli mają wiele pakietów, możesz zobaczyć, ile kredytów pozostało na przyszłe klasy? Aplikacja może dbać o calc i przechowywać go centralnie w tabeli klienta.

3. Informacje o firmie mogą korzystać z wielu innych pól, w tym oczywistego adresu / telefonu / itp. informacje. Byłbym również przygotowany do dodania W D & B "DUNs" columns (Site/Branch/Ultimate) long term, Dun and Bradstreet (D&B) ma ogromny katalog firm, a później znajdziesz ich informacje są bardzo pomocne w raportowaniu/analizie. To zajmie się kwestią wielu podziałów, o której wspomniałeś, i pozwoli Ci zwijać ich hierarchię dla poddziałów/oddziałów / itp. korpusu.

4. Nie wspominasz, ile płyt będziesz pracować, co może oznaczać przygotowanie się do dużego rozwoju inicjatywa, która mogła być wykonana szybciej i znacznie mniej bólów głowy z zapakowanym oprogramowaniem "raportującym". Jeśli nie masz do czynienia z dużą bazą danych (

5. FYI-Reporting insight: w przypadku dużych baz danych zazwyczaj masz dwie bazy danych instancje a) baza danych transakcji do rejestrowania każdego szczegółowego rekordu. b) baza raportowa (data mart/hurtownia danych) umieszczona na oddzielnej maszynie. Więcej informacji szukaj google zarówno schemat gwiazdy i Snowflake schematu.

Pozdrawiam.

Chcę odnieść się tylko do obaw, że dołączenie do mutiple tables spowoduje hit wydajności. Nie bój się normalizować, bo będziesz musiał to zrobić. Połączenia są normalne i oczekiwane w relacyjnych bazach danych i są zaprojektowane tak, aby dobrze sobie z nimi radzić. Będziesz musiał ustawić relacje PK/FK (dla integralności danych, jest to ważne do rozważenia przy projektowaniu), ale w wielu bazach danych FK nie są automatycznie indeksowane. Ponieważ będą one używane w połączeniach, na pewno będziesz chciał zacząć indeksując FKS. PKs zazwyczaj dostaje indeks na tworzenie, ponieważ muszą być unikalne. To prawda, że projekt datawarehouse zmniejsza liczbę połączeń, ale zazwyczaj nie dociera się do punktu hurtowni danych, dopóki nie ma milionów rekordów potrzebnych do uzyskania dostępu w jednym raporcie. Nawet wtedy prawie wszystkie hurtownie danych zaczynają od bazy transakcyjnej, aby zbierać dane w czasie rzeczywistym, a następnie dane są przenoszone do magazynu zgodnie z harmonogramem (co noc lub co miesiąc lub niezależnie od potrzeb biznesowych jest). Jest to więc dobry początek, nawet jeśli trzeba później zaprojektować hurtownię danych, aby poprawić wydajność raportu.

Muszę powiedzieć, że twój projekt jest imponujący jak na studenta pierwszego roku CS.

Nie jest przerobiony, tak bym podszedł do problemu. Dołączenie jest w porządku ,nie będzie dużego hitu wydajności (jest to całkowicie konieczne, chyba że de-normalizacji bazy danych, co nie jest zalecane!). W przypadku statusów sprawdź, czy możesz użyć zamiast tego typu danych enum, aby zoptymalizować tę tabelę.

Pracowałem w dziedzinie szkolenia / szkoły i pomyślałem, że chciałbym zwrócić uwagę, że istnieje ogólnie relacja M: 1 między tym, co nazywasz "sesjami" (instancjami danego kursu) a samym kursem. Innymi słowy, twój katalog oferuje kurs ("Hiszpański 101" lub cokolwiek innego), ale możesz mieć dwa różne przypadki tego w jednym semestrze (TU-TH prowadzone przez Smitha, Śr-Pt prowadzone przez Jonesa).

Poza tym, wygląda to na dobry początek. Założę się, że przekonasz się, że klient domena (wykresy prowadzące do "klientów") jest bardziej złożona niż modelowałeś, ale nie przesadzaj z tym, dopóki nie masz prawdziwych danych, które Cię poprowadzą.

Kilka rzeczy przyszło mi do głowy:

1. Tabele wydawały się nastawione na raportowanie, ale tak naprawdę nie prowadziły biznesu. Myślę, że kiedy klient się zarejestruje, zasadniczo składa się zamówienie na klienta uczestniczącego w liście sesji, a to zamówienie może dotyczyć wielu pracowników w jednej firmie. Wydaje się, że tabela "zamówienia" naprawdę będzie w centrum systemu i napędza przechwytywanie danych i ewentualne raportowanie. (Porównaj dokumenty papierowe, które zostały używając do uruchomienia firmy z projektem bazy danych, aby sprawdzić, czy istnieje logiczne dopasowanie.)

2. Firmy często nie mają podziałów. Pracownicy czasami zmieniają działy/działy, może nawet w połowie sesji. Firmy czasami dodają/usuwają / zmieniają nazwy działów / działów. Upewnij się, że możliwa zmiana zawartości tabel w czasie rzeczywistym nie utrudnia późniejszego raportowania/grupowania. Przy tak dużym podziale danych kontaktowych na tak wiele tabel, być może będziesz musiał wyegzekwować bardzo rygorystyczne Walidacja wprowadzania danych, aby Twoje raporty były zrozumiałe i kompletne. Na przykład, gdy nowy klient jest dodawany, upewniając się, że jego firma / dział/dział / miasto pasują do tych samych wartości, co jego współpracownicy.

3. Koncepcja "paczek" nie jest jasna.

4. Ponieważ wskazujesz, że jest to mała firma, byłoby zaskakujące, gdyby wydajność była problemem, biorąc pod uwagę szybkość i pojemność obecnych maszyn.

Åšwietna robota!

Nie, Nie przesadzasz z inżynierią, świetnie sobie radzisz. Pamiętam mój pierwszy projekt, była to strona internetowa, którą zgodziłem się zbudować, mimo że nie wiedziałem nic o programowaniu. Jednak ja go zbudowałem. W każdym razie, oto kilka przydatnych wskazówek podczas budowania pierwszego projektu bazy danych;

• Zachowaj maÅ‚e tabele(nie marnuj niepotrzebnie miejsca).

• Nie pytaj o wiÄ™cej informacji, niż potrzebujesz.

• JeÅ›li używasz ORMs, uważaj typowych puÅ‚apek, takich jak problem N+1.

• Trzymaj siÄ™ z dala od kÅ‚opotliwych operatorów(np. ' % Smith%').

• Inteligentnie Zaprojektuj swoje indeksy i upewnij siÄ™, że obejmujÄ… one wiÄ™kszość zastosowaÅ„ (tutaj jest przyzwoity, jeÅ›li Å›wiatÅ‚o, leczenie indeksów).

• PamiÄ™taj, że zapytania oparte na zestawach sÄ… zwykle o wiele lepsze pod wzglÄ™dem wydajność niż iteracja poprzez dane.

• Wiedzieć, kiedy denormalizować dane pod kÄ…tem wydajnoÅ›ci powody.

• Ból, co można buforować (ekonomicznie), aby zÅ‚agodzić DB.

Istnieje jednak również wiele narzędzi, które mogą Ci pomóc. Na przykład używam SQLDbm , który uważam za najbardziej skuteczny.

Sqldbm oferuje łatwy i wygodny sposób zaprojektowania bazy danych w dowolnym miejscu w dowolnej przeglądarce, bez potrzeby stosowania dodatkowego silnika bazy danych lub narzędzi do modelowania baz danych lub aplikacji. Użyj SQLDBM do projektowania i zarządzania zarówno dużymi, jak i małymi bazy danych i modele danych w locie. Wszystko to przy jednoczesnym uwzględnieniu wszelkich potrzebnych reguł i obiektów bazy danych, takich jak klucze bazy danych, Schematy, indeksy, ograniczenia kolumn i relacje.