Postacie normalne

0

Mam takie pytanie. W skrócie 3 postać normalna zakłada że dane nie są od siebie zależne poza kluczem. Prowadzi to do konieczności złączeń.
Stąd pytanie czy warto zrezygnować z tej własności na rzecz szybszego szukania lub jego ułatwienia?

0
moskitek napisał(a)

Stąd pytanie czy warto zrezygnować z tej własności na rzecz szybszego szukania lub jego ułatwienia?

W sensie czy warto zrezygnować z trzeciej postaci normalnej ze względów wydajnościowych? W pewnych sytuacjach, gdy potrzebujemy szybkiego wyszukiwania danych, to tak. Na tym mniej więcej opierają się np. hurtownie danych.

0

czy warto zrezygnować z tej własności na rzecz ... ułatwienia

NIE. Nauczyć się sql.

0

to tak troche jak odp na inne pytanie (aktualnie piętro niżej):
Mysql Optymalizacja zapytań

ale też mówiąc o ułatwieniu - mając dość złożoną logikę biznesową czytanie długich zapytań, w których są "pokrętne" warunki (analizowanie/szukanie w nich błędów/pielęgnacja) jest mało przyjemna w porównaniu z sytuacją kiedy mam te dane w jako jeden atrybut.

1

Rób po bożemu, bo inaczej spotka Cię sroga kara, ucz się i rób jak bozia przykazuje. Wprawny programista SQL nie ma absolutnie żadnego kłopotu z ogarnięciem zapytań w których są INNER czy OUTER JOIN-y do 10 tabel, GROUP BY po 10 polach, a to wszystko jest złączone z kolejnymi 10 tabelami w podzapytaniu. Na dodatek serwerek SQL (nie cluster, nie cloud tylko serwerek) spokojnie to ciągnie, wystarczy wiedzieć co się robi. Pamiętaj, że SQL to język który znakomicie pokazuje poziom wiedzy programisty, ponieważ wszystko tam jest istotne łącznie z kolejnością tabel w złączeniu, kolejnością pól w indeksie, kolejnością pól w WHERE itd. Dobry programista jest w stanie tak zaprojektować tabele i zapytania, że chodzi to 1000 razy szybciej (DOSŁOWNIE!!!) niż gdyby to samo robił przeciętny klepacz stronek PHP, który nie wgłębiał się nigdy w arkana RDBMS.

1
moskitek napisał(a)

ale też mówiąc o ułatwieniu - mając dość złożoną logikę biznesową czytanie długich zapytań, w których są "pokrętne" warunki (analizowanie/szukanie w nich błędów/pielęgnacja) jest mało przyjemna w porównaniu z sytuacją kiedy mam te dane w jako jeden atrybut.

Odpowiednie formatowanie kodu, schemat bazy wydrukowany gdzieś przed oczami i czytanie kodu SQL nie jest problemem. Poza tym, to ma dobrze i wydajnie działać, a nie być przyjemne.

0

ok dzięki za odpowiedzi, ostatnio zacząłem mieć trochę wątpliwości i chciałem się upewnić.

0

Czasem stosuje się w pewnych wypadkach tzw płaski zapis, który jest "obok" danych zapisanych w 3 postaci normalnej. Dane takie są w specjalnej tabeli, bądź nawet jako string w pojedynczym polu. Rozwiązanie takie nie jest zbyt eleganckie, ale pomaga wydajnościowo w przypadku bardzo złożonej i rozpasanej bazie.

0

Odpowiedź brzmi "I tak i nie". Z jednej strony warto ułatwiać sobie życie pisząc proste zapytania. Z drugiej to co pisze AdamPL, czyli RDBMS poradzą sobie z 3PN jeżeli tylko programista wie co robi. Po środku pomiędzy tymi dwoma elementami mamy taki wynalazek jak widoki. Pozwalają one z jednej strony na uproszczenie zapytania ponieważ odpytujesz widok, a z drugiej przesłaniają rzeczywisty wygląd tabeli.

Jeżeli masz wybrać np. pracowników z pensją > 100 zamieszkałych w pcimiu, którzy robią na 3 rampie u pana Włodka, to wygodniej jest pytać widok "KOMPLETNE_DANE_PRACOWNIKA" niż rzeźbić join po 5 czy 6 tabelach. Recz w tym, że takie widoki muszą być przemyślane to znaczy, że trzeba wiedzieć do czego będą używane oraz warto postarać się napisać je najwydajniej jak się da założyć odpowiednie indeksy i zadbać o odpowiednią kolejność parametrów.

0

korzystając z ormów (np Hibernate) upraszczanie zapisu aby później za pomocą propertyResolverów sobie łatwo czytać dane jest bardzo kuszące.
O widokach nie pomyślałem :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0