Projekt bazy danych Opcje

[kolaborek]

Witajcie.

Mam zamiar zaprojektować sobie bazę danych do przechowywania informacji o posiadanym sprzęcie komputerowym i oprogramowaniu.
Nie potrafię jednak pojąć jak ma przebiegać proces wstawiania danych do bazy.
Dokładniej, chodzi mi o sytuację kiedy mamy trzy tabele:
|oprogramowanie| |sprzęt| |zestaw_komputerowy|

W tabeli |zestaw_komputerowy| mają być tylko klucze do tabel |oprogramowanie| i |sprzęt|.
Teraz sedno sprawy
Jak wstawiać dane do tabeli |zestaw_komputerowy| aby tam były tylko klucze do tabel zewnętrznych ?

Wiem, wiem - zagmatwałem Proszę o wyrozumiałość

[vokiel]

Na pierwszy ogień przychodzą 2 pomysły.

1. oprogramowanie: id, nazwa, inne pola... | sprzęt: id, inne pola | zestaw_komputerowy: id, ids_opgramowania, ids_sprzetu
Do zestawu wstawiasz po przecinku id programów i podzespołów, czyli np:
1 | 1,3,4 | 4,12,15
2 | 3,4,5 | 4,6,8

2. Robisz dodatkową tabelę (lub dwie) gdzie łączysz oddzielnie id zestawu i id sprzętu lub id oprogramowania. Tabela oprogramowanie i sprzęt zostaje, zestaw_komputerowy: id, numer_zestawu, inne pola.. zestaw_komputerowy_oprogramowanie: id_zestawu, id_oprogramowania, zestaw_komputerowy_sprzęt: id_zestawu, id_sprzętu, czyli np:
1 | 1
2 | 3
1 | 2

[yoshinobi]

Czyli według mojego rozumowania (na podstawie pierwszego pomysłu vokiel'a) schemat relacyjny powinien wyglądać mniej więcej tak:

[vokiel]

W pierwszym przypadku nie ma relacji. W przypadku relacji podajesz tylko jedno id, czyli byś nie mógł wypisać ich po przecinku. W drugim przypadku można to oprzeć na relacjach, ale trzeba tą dodatkową tabelę.

[kolaborek]

Zrobiłem wstępny projekt bazy jak na załączniku poniżej. Ciekawi mnie, czy jest ona w pełni zgodna z tym co vokiel pisałeś powyżej ?
baza

Ten post edytował kolaborek 21.04.2011, 13:53:37

[vokiel]

Z tymi bazami po prawej i lewej to przesadziłeś Te wszystkie jednokolumnowe tabele powinny być po prostu kolumnami tabel urządzenia/licencje. Poza tym ok. Teraz tylko napisać ładne zapytania z JOIN'ami i będzie git.

[kolaborek]

Te poboczne tabele to slowniki w ktorych beda zapisane poszczegolne nazwy programow, wersji itp. Pozwoli mi to uniknac (takie jest zalozenie ) wpadek typu: "adobe", "Adobe", lub "ADOBE", co w pozniejszej statystyce mogloby sie przelozyc na 3 rozne programy zamiast 3 stanowisk jednego programu
Czy takie zalozenie ma sens?

[vokiel]

Moim zdaniem narzut dodatkowych 10-ciu tabel będzie dużo wyższy niż zysk ze zmniejszenia redundancji. Przykładowo w urządzeniach będziesz miał procesory, to ilu producentów wymienisz? Pewnie dwóch AMD i Intel. Dla reszty podzespołów też ich dużo nie będzie, bo ciągle przewijają się ci sami. Wpadki typu "adobe", "Adobe" rozwiązujesz dodając dane do bazy poprzez unifikację nazewnictwa - wszystko sprowadzasz albo do ucfirst lub lowercase czy uppercase.

Tak samo z licencjami, masz tabele wersja i podwersja. Co w nich będziesz przechowywał? 1.1 i 2.beta? Moim zdaniem już lepiej trzymać to po prostu jako wartość w tabeli licencje. W przypadku niewielkiej ilości wartości (np nazwa licencji) lepiej zrobić tym enum niż dodatkową tabelę.

Generalnie z normalizacją trzeba czasem przystopować, żeby nie przesadzić.

[kolaborek]

Prawdopodobnie sposób jaki opisałeś byłby szybszy. Ja jednak wolałbym zostać przy takiej bazie jaką zaprojektowałem. Dla mnie jest ona czytelniejsza (podobny układ miałem wcześniej w excelu) i łatwiej mi będzie na niej operować. Myślę też, że przy rekordach idących w tysiące, różnica czasowa w wykonywaniu zapytań między tym co Ty napisałeś, a ja stworzyłem, nie będzie taka znowu wielka... No chyba, że się mylę, wtedy trzeba będzie coś pozmieniać

Teraz jestem na etapie Tworzenia widoków na których będę operował.
Po wykonaniu widoku otrzymuję takie informacje z polecenia explain.


Uploaded with ImageShack.us
Czy wynik działania tego widoku jest optymalny? - bo nie jestem pewien ....

Ten post edytował kolaborek 26.04.2011, 08:58:54