Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Projekt bazy danych
Forum PHP.pl > Forum > Bazy danych > MySQL
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 smile.gif
Jak wstawiać dane do tabeli |zestaw_komputerowy| aby tam były tylko klucze do tabel zewnętrznych ?

Wiem, wiem - zagmatwałem wink.gif Proszę o wyrozumiałość smile.gif
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
vokiel
Z tymi bazami po prawej i lewej to przesadziłeś wink.gif 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
wink.gif Te poboczne tabele to slowniki w ktorych beda zapisane poszczegolne nazwy programow, wersji itp. Pozwoli mi to uniknac (takie jest zalozenie wink.gif) wpadek typu: "adobe", "Adobe", lub "ADOBE", co w pozniejszej statystyce mogloby sie przelozyc na 3 rozne programy zamiast 3 stanowisk jednego programu wink.gif
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ć wink.gif

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 ....
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.