Unikanie nadmiarowości danych Opcje

[who?]

Witam,
Problem generalnie stary jak bazy danych w związku z czym sposobów na radzenie sobie z nadmiarowością również nie brakuje. Jednakże ostatnio doszedłem do wniosku, że o ile eliminowanie nadmiarowości w teorii wygląda na sprawę dość łatwą (a jeśli nie łatwą to przynajmniej jasno opisaną) o tyle w praktyce nie jest już tak różowo.

Rozważmy taki prosty z "życia wzięty" przypadek. Mamy bazę danych, w której istnieją trzy tabele: klienci, towary i faktury. Tabela faktury ma przechowywać wszystkie faktury wystawione dla danych klientów na dane towary. Oczywiście sprawa wygląda na wręcz banalną. Książkowe rozwiązanie tego problemu to utworzenie w tabeli faktury kluczy obcych tabeli klientow i tabeli towarów (plus oczywiście dodatkowe pola charakteryzujące daną faturę jak numer, data wystawienia itd.). Dzięki takiemu rozwiązaniu unikamy wspomnianej nadmiarowości ponieważ nigdzie nie powielamy danych. W praktyce jednak takie rozwiązanie średnio nas zadowala ponieważ jeśli wystawimy dla danego użytkownika kilka faktur, a później zedytujemy jego dane, to dane te również zmienią się na fakturach wystawionych przed edycją danych klienta (taka operacja jest niedpopuszczalna).

I tutaj zaczynają się schody - jak rozwiązać ten problem unikając nadmiarowości, a jednocześnie nie komplikując zbytnio bazy, a tym samym aplikacji? Oczywiście najprościej było by stworzyć ogromną tabelę faktury, która zawiera pola tabeli klienci i tabeli towary i przy dodawaniu nowej faktury kopiować wszystkie dane z tych tabel. Takie jednak tworzenie "super tabel" kłuci się generalnie z ideą relacyjności (nie mówiąc już nawet o nadmiarowości) dlatego wolałbym tego unikać. Z drugiej jednak strony tak się zastanawiam czy jest sens starać się za wszelką cenę eliminować tego typu nadmiarowość kosztem komplikacji systemu, w bazach gdzie będzie góra kilka tysięcy rekordów? Jakie jest wasze zdanie na ten temat i jak wy sobie radzicie z tym problemem?

Pozdrawiam,
who?

[batman]

Po co i aktualizacja wszystkich pol. Po to sa relacje zeby je wykorzystywac. Mechanizmy baz danych sa do tego celu stworzone a nie poto zeby operowac na jedenj tabeli.

W podanym przykładzie niedopuszczalne jest edytowanie danych w zapłaconych fakturach. A tworzenie dodatkowych tabel na historię będzie duplikować dane.

Po co i aktualizacja wszystkich pol. Po to sa relacje zeby je wykorzystywac. Mechanizmy baz danych sa do tego celu stworzone a nie poto zeby operowac na jedenj tabeli.

Całkowicie się z Tobą zadzam, ale nie ma sensu trzymać się dokładnie teoretycznych rozważań, tylko po to, by się ich trzymać (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) Jeśli coś ma działać bardziej wydajnie, warto to zastosować. Nie twierdzę, że w każdej tabeli powielać wszystkei dane. Chodzi mi o to, że jeśli używasz jakiegoś pola często, to nie ma sensu ciągłe łącznie kilku tabel. Zamiast tego masz wszystko w jednym miejscu. A do aktualizacji tych danych - po to są triggery.