Projekt bazy danych MySQL - prośba o opinie i porady

Question

Witam serdecznie. Zainspirowany radami Pana Mirosława postanowiłem zarejestrować się na tym zacnym forum, jako, że jestem całkowicie początkujący, nie dla zajawki a raczej dla zdobycia dodatkowej wiedzy od bardziej doświadczonych użytkowników, którzy zechcą się tą wiedzą podzielić.
Zacząłem dosyć niedawno uczyć się PHP/MySQL i podchodzę do pierwszego projektu, moim celem jest stworzenie harmonogramu dla firmy odpadowej.

Sprawa wygląda następująco: mam stworzoną przez kogoś, działającą (kulawo ale jednak działającą) bazę danych, chcę ją przeprojektować aby działała jak najbardziej optymalnie i okodować po swojemu. Ale kodowanie to temat na potem, na początek biorę na warsztat sam projekt bazy.

Obecna wersja bazy jest zrobiona na jednej tabeli i wygląda następująco:

Harmonogram

id	ulica	numer	rodzaj frakcji	data_odbioru
1	BAJKOWA	10	SUCHA	2016-02-01

W ten sposób jest dopisana każda ulica, każdy rodzaj frakcji i każda data co w sumie daje coś około 310tys. rekordów.

Mój pomysł na bazę to 3 tabele

adresy

id	ulica	numer
1	BAJKOWA	10

frakcje

id	typ_frakcji
1	frakcja sucha
2	frakcja zmieszana

daty odbioru

id_adresu=adresy.id	id_frakcji=frakcje.id	data odbioru
1	1	2016-02-01
1	1	2016-02-15

A teraz moje pytania:

- czy taka konstrukcja jaką sobie opracowałem jest w ogóle poprawna (sensowna)?

- czy taka konstrukcja będzie szybsza, lepiej zoptymalizowana niż pierwotna?

- jeśli coś jest źle to co zmienić?

- czy ma sens dodanie czwartej tabeli, w której będą same daty i połączenie kluczem obcym z tabelą daty odbioru? Na pewno zmniejszy to objętość bazy ale czy nie wpłynie negatywnie na szybkość?
Wyglądało by to tak:

daty

id	data
1	2016-03-01
2	2016-03-15
3	2016-04-01

daty odbioru po zmianie

id_adresu(adresy.id)	if_frakcji(frakcja.id)	id_daty(data.id)
1	1	1
1	1	5

Więcej grzechów nie pamiętam, proszę o pokutę, tfu, proszę tylko o naukę i wyrozumiałość :)

Answer 1

Warto poczytac na temat postaci normalnych baz danych (pierwsza postac normalna, druga itd). Motyw jest taki, aby baze danych rozbic na jak najwiecej tabel. Tak wiec twoj pomysl na rozbicie tej jednej obecnej tabeli jest jak najbardziej trafny. W tabeli frakcje przechowuj tylko nazwe, tzn sucha a nie frakcja sucha. Tabela data odbioru zostaw jak napisales, nie ma sensu rozbijac daty do osobnej tabeli, date akurat lepiej trzymac przy konkretnej wartosci w jednej tabeli. Na chwile obecna to tyle, jest ok :)

Answer 2

Mam kolejne pytania dotyczące mojej bazy:

Wiem jak wykonać zapytanie dla dowolnego adresu (co da mi terminarz na cały rok dla danej posesji) ale potrzebuję osiągnąć jakiś bardziej zaawansowany efekt. Potrzebuję zrobić box z listą ulic do wyboru (pole select lub rozszerzone pole select z możliwością wyboru kilku rekordów), po kliknięciu na wybranej ulicy ma się pokazać lista numerów konkretnej ulicy a dopiero po kliknięciu na wybranym numerze ostatecznie pokazuje się terminarz. I tutaj leżę bo po pierwsze nie wiem jak wykonać zapytanie do bazy 'adresy' , żeby wypisać nazwy ulic bez duplikatów (ze względu na konstrukcję tabeli każda ulica występuje x razy) a po drugie nie wiem jaką technologię użyć aby te dane wczytywały mi się w sposób dynamiczny.

Mistrzowie, doradzicie coś?