Witam!
Robie dużą baze danych, będzie w niej bardzo dużo informacji dotyczących konkretnego człowieka. (Aplikacja do przeprowadzenia rekrutacji np na uczelnie wyższą) Dane rozdzieliłem na kategorie: wojsko, dane osobowe, dane adresowe itd. Wymyśliłem sobie ze będzie to wyglądać tak jak na dołączonym obrazku.

Model bazy danych

Oceńcie czy będzie to efektywne, lub ewentualnie jakieś wskazówki to będe wdzięczny.
Każdy rodzaj danych jes połączony relacją 1:1 z tabelą kandydat. W ten sposób będe mógł łatwo dostać sie do potrzebnych danych wykorzystując tylko id kandydata.

Prosze o ocene i wskazówki. To tylko początek bazy(brakuje jeszcze danych o przebytej edukacji kandydata, wybieranych kierunkach studiów, itd. Te dane zamierzam wstawić także w relacji 1:1 do tabeli kandydat)

Moje uwagi:

- zdecydowanie zbyt dużo tutaj relacji jeden do jednego - patrząc na w tym momencie widzę, że bardzo ciężko będzie ci osiągnąć pewne funkcjonalności - generalnie zawartość tabeli dane_wojskowe, kandydat, dane_osobowe powinieneś połączyć w jedną tabelę
- źle zaprojektowane są tabele adresów: to wszystko możesz wrzucić do jednej tabeli + dodatkowo wykorzystując dodatkową tabelę "typ_adresow" relacji jeden do wielu (jeden po stronie typu, wiele po stronie adresy) przypiszesz określonemu adresowi jego typ czyli tymczasowy, korespondencyjny
- przy tego typu bazie danych zastanowiłbym sie czy nie wprowadzić dodatkowych tabel: miasta, województwa i ich klucze główne przypisać do adresów (dzięki temu w bardzo łatwy sposób będziesz mógł wygenerować statystyki dotyczące pochodzenia kandydatów). Więcej: można pokusić się o przypisanie miasta do województwa - wówczas jeszcze pełniejszy obraz będzie można wyciągnąć.
- brak nazw relacji
- po co sztuczny klucz w dane_wojskowe? zrób wielopolowy klucz podstawowy z wykorzystaniem id kandydata oraz id wku - w końcu kandydat może należeć tylko do jednej wku
- brak konsekwencji na projekcie w typach pól: stosujesz raz VARCHAR(X) a raz VARCHAR
- brak konsekwencji w nazwach pół: czasami stosujesz nr_telefonu, a czasami skracasz i piszesz nr_kom - z projektu w miarę możliwości powinno jasno wynikać o co w polu chodzi
- tabela wku pole adres - nie twórz pól wielowartościowych!
- dałbym również nazwy indeksom
- osobiście stosuję w nazwach pół jakieś przedrostki
- na pole numeru telefonu komórki dałbym trochę więcej znaków bo przy masce wprowadzania +48 xxx xxx xxx - trochę braknie

To tyle. Pozdrawiam.

Dzięki kolego za cenne wskazówki, ale będe pytał dalej:)
zgadzam się. relacja 1:1 faktycznie nic tutaj nie daje. Ale jednak nadal chciałbym rozdzielić tabele "kandydat" od tabeli "dane_kandydata" z racji tego że w "kandydat" przechowuje dane potrzebne do logowania i potem do mailowania do kandydata. to dobry pomysł?
święta racja! Poprawione. przy okazji skorzystałem z tabli "adres" do podania adresu wku.
już wcześniej o tym myślałem. to pomoże przy generowaniu raportów
tego nie za bardzo rozumiem, ale rozwiązałem po swojemu. chyba nie najgorzej?
jakie są tego korzyści i jak potem z tego skorzystać? nigdy tego nie robiłem więc jak stosować nazewnicto?
przypadek, poprawie

Poprawiony projekt
Proszę o dalsze wskazówki i jeszcze raz dziękuje za te już otrzymane

Nie widzę projektu poprawionego

Uwagi do poprawionego projektu:

- jest zdecydowanie lepiej

- dalej uważam, że nie ma sensu rozbijać tego na dwie tabele


Inne:
- data urodzenia: dałbym typ date
- w tabeli dane_kandydata - masz klucze obce nieistniejących tabel
- dalej aktualna uwaga: - na pole numeru telefonu komórki dałbym trochę więcej znaków bo przy masce wprowadzania +48 xxx xxx xxx - trochę braknie, a także zauważam brak konsekwencji: w jednym polu masz na numer 10, w drugim 16, w trzecim (wku) 50


PS. wrzuć projekty na forum, żeby inni również widzieli.

Wskazówki okazały sie pomocne:)
Skoro tak mówisz to tak zrobie:)
hmm nie za bardzo rozumiem. ja to widze tak, w "dane kandydata" są trzy klucze obce od tabeli "adres" (id_adresu_stalego, id_adresu_tymczasowego, id_adresu_korespondencyjnego) odpowiadają kolumnie id_adresu z tabeli "adres". coś czuje że nie jest to najlepiej zrobione.
co do reszty sie zgadza, ale było późno i nie myślałem chyba już(w sumie po co mi godzina minuta i sekunda w dacie urodzenia:))

Jeszcze raz zapytam o:

jakie są tego korzyści i jak potem z tego skorzystać? nigdy tego nie robiłem więc jak stosować nazewnicto?

Trzecia odsłona projektu

dobry projekt.

no to daje narazie wirtualnego plusika
biore się za reszte bazy bo to narazie chyba 1/3 całości (co oznacza że nadal bede męczył)
do każdego kandydata musze dodać informacje o jego edukacji (szkoła, matura, wyniki matury, olimipady itd..) plan był taki że dodam tabele "dane_edukacyjne" i połącze 1:1 z "kandydat"... teraz juz nie mam pomysłu, dodatkowo kierunek(kierunek, specjalność, wydział) na jaki kandydat aplikuje.

Dobrze będzie jak zrobie tabele: "wydział", "kieruneki", "specjalnosc" z relacjami 1:n i identyfikator specjalności połącze do "dane_kandydata" ?
Podobnie można zrobić ze szkołą, no ale o wynikach matur, olipiad to juz nie mam pojęcia.

Jakaś podpowiedź?

tak: działaj i pokaż efekty.

wrzucam część o wyborze kierunku studiów. Tabela "tryb_studiow" określa tryb studioów(6 możliwości). reszta chyba wiadomo.
tryb_studiow i specjalonsc połączone są relacją wiele do wielu, nigdy z niej nie korzystałem... dobrze to?

Nadal nie mam pomysłu jak przedstawić dane o już odbytej edukacji. Podpowiedzcie troche



Edycja:

Jednak inaczej troche to zrobiłem

To co mam jest tutaj: Projekt bazy

Proszę o pomoc przy dodaniu tabel dotyczących wyników matury kandydata. ja niestety nie mam pomysłu. szczególy w poscie
wyniki matury w bazie

A ja mam parę pytań/uwag.

1. Czy pola daty nie lepiej przerobić na integer i wrzucać tam datę w formie liczby - np. przez mktime() z PHP?
2. Czy warto przykładać się do ograniczania długości pól? Np. id_narodowosci i pare innych pół na pewno nie potrzebują pełnej długości inta. Jest sens aż tak żyłować? Ktoś ma doświadczenie jaki ma to wpły na bazę np. z milionem rekordów?
3. Czy nie lepiej - wydajniej - operować na samych liczbach w polach gdzie można je użyć? Np. płeć, stan cywilny i parę innych pól zastąpić liczbami? 1 bajt spokojnie wystarczy chyba na takie dane? Operacje na liczbach są też chyba szybsze.

Ziarnko do ziarnka i zbierze się miarka Te uwagi/pytania przedstawiam tutaj z ciekawości, może macie jakieś doświadczenia w tym temacie.

Odkopałeś wątek sprzed pół roku...

Zależy co chcesz osiągnąć... jeśli chodzi ci o daty typu 1975-01-01 (pola typu DATE) to zajmują one 4 bajty, więc tyle samo co timestamp z mktime(), a przy polu DATE masz date w formacie łatwym do odczytania i możesz zapisać daty z stylu 1567 rok, które przy timestamp wykraczały by poza zakres integera.

http://dev.mysql.com/doc/refman/5.0/en/sto...quirements.html


Cośtam zawsze to da, ale przy bazie która, jak sądze, w wymienionym przypadku będzie miała conajwyżej w granicach 200000 rekordów po paru latach użytkowania sens takich oszczędności jest raczej znikomy.

Z tego co patrze na schemacie to wymienione przez ciebie pola są typu ENUM, czyli są zapisywane jako 1 bajtowa liczba. Wewnętrznie MySQL tłumaczy podane w zapytaniu wartości (np. 'kawaler', 'żonaty' itd.) na odpowiadające im wartości pola: 1,2 itd.
Dodatkową zaletą pola ENUM jest to że za 2 lata jak ktoś inny przyjdzie żeby cośtam zmienić/poprawić to nie będzie sie głowił, czy liczba 1 w tabeli oznacza 'kawaler' czy też 'żonaty', a może jeszcze coś innego.