Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Pytanie o nadmiarowość danych
Forum PHP.pl > Forum > Bazy danych > MySQL
Zielonkawy18
Witam

Ogólnie w bazie danych mam dwie tabele ( więcej, ale chcę nakreślić dane ). Mam tabele

Magazyny ( która zawiera wszystkie dane identyfikujące ten magazyn )

Mam także Tabele Faktury ( na której widnieją niektóre dane z tabeli Magazyny <- dane te przekopiowywane są z tabeli Magazyny ), czy jest tutaj redundancja? Jest to dopuszczalne? Moim zdaniem redundancja jest, ale za cholerę nie da się tego inaczej zrealizować...
mmmmmmm
1. Jest to redundancja (jeśli zostały przekopiowane z innej tabeli)
2. Jeśli to nie jest projekt akademicki, to jest to dopuszczalne - często wręcz ułatwia życie.
Zielonkawy18
Jeszcze pytanie odnośnie takich zamkniętych połączeń, czy jest to poprawne?

http://www.tinypic.pl/2adclsit57rr

Jeden magazyn może mieć wiele produktów,
Magazyn zatrudnia wiele pracowników
Jeden pracownik może wystawić wiele faktur
itd itd

To jest tylko przykład, chodzi mi tylko czy należy unikać tak zamkniętych kół.
bpskiba
Nie ma powodu aby unikać takich połączeń.
Zielonkawy18
A czy można dawać klucze obce do złożonego klucza podstawowego?
mmmmmmm
Cytat(Zielonkawy18 @ 4.05.2013, 14:25:18 ) *
A czy można dawać klucze obce do złożonego klucza podstawowego?

Sprawdź. smile.gif
Zielonkawy18
Ja wiem, że można smile.gif

Chodzi mi o to jak to wygląda ze strony poprawności.

Np. Moją tabelą najważniejszą w bazie danych to MAGAZYNY ( tylko do odczytu )I np.

Jeden magazyn może obsłużyć wiele klientów ( klienci mają FK z magazynu i te FK + ID_K to primary key ). Troche to licho wygląda dalej bowiem:

np Klienci mogą złożyć wiele zamówień , tutaj automatycznie tabela Zamówienia ma już FK1, FK2 z tabeli klienci ( bo klienci mają złożony klucz główny ) i znowusz biore jeden FK do złożenia z ID_ZAMOWIENIA.

Skoro jest mi to potrzebne to stosować to i tyle?? Bo cały czas mam na uwadzę spójność bazy.
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.