Postacie normalne

Odpowiedz Nowy wątek
2011-08-10 12:55
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?

Pozostało 580 znaków

2011-08-10 13:51
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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
edytowany 1x, ostatnio: somekind, 2011-08-10 13:51

Pozostało 580 znaków

2011-08-10 15:11
0

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

NIE. Nauczyć się sql.

Nie chodzi mi to że nie znam sqla(choć żadnym masterm nie jestem), tylko czasami kusi aby sobie zapamiętać gdzieś dane które są zależne od innych przez co jest do nich łatwy i szybki dostęp - i czy warto to zrobić, czy to tylko złudne ułatwienie. - moskitek 2011-08-10 15:23

Pozostało 580 znaków

2011-08-10 15:26
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.

edytowany 1x, ostatnio: moskitek, 2011-08-10 15:31

Pozostało 580 znaków

2011-08-10 22:13
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.

chyba, że trafi na optymalizator, który "wie lepiej". Ale i na to są metody. - Koziołek 2011-08-11 09:37

Pozostało 580 znaków

2011-08-10 23:28
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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2011-08-10 23:39
0

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

edytowany 1x, ostatnio: moskitek, 2011-08-10 23:39

Pozostało 580 znaków

2011-08-11 08:17
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.

edytowany 1x, ostatnio: Sarrus, 2011-08-11 08:17

Pozostało 580 znaków

2011-08-11 09:46
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.

Pozostało 580 znaków

2011-08-11 12:03
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 :)

Pozostało 580 znaków

2011-08-11 14:33
0

Pamiętaj, że żaden ORM nie jest tak wydajny jak raw sql, z tego też powodu tam gdzie potrzebna jest jak najwyższa wydajność rezygnuje się z ORM. Ostatnio tworzyłem w Django aplikację analityczną, rezygnacja z Django-wego ORM na rzecz żywych zapytań SQL przyniosła mi kilkudziesięciokrotny wzrost wydajności. Oczywiście zyskując na wydajności straciłem na wygodzie w utrzymaniu tego kodu, coś za coś.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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