Strength is irrelevant.
Resistance is futile.
We wish to improve ourselves.

1. no ok, nawet to rozumiem, ale i tak nie jestem pewien jak przykladowo powinna wygladac , kubazzz 23/12/08 05:44
   taka baza danych.
   w takim razie mozna byc zrobic tabele
   USERS
   wszyscy uzytkownicy
   KOMENTARZE
   wszystkie komentarze, wybierane na podstawie id uzytkownika
   OCENY
   wszystkie oceny wszystkich komentarzy brane na podstawie id komentarza
   
   ale zakladajac, ze uzytkownikow jest 100, kazdy napisze 20 komentarzy, a do kazdego komentarza zostanie wystawionych 5 ocen to mamy
   tabele USERS - 100 rekordow
   tabele KOMENTARZE - 2000 rekordow
   tabele OCENY - 10 000 rekordow
   
   Nie za duzo?
   Nie bedzie problemow z wydajnoscia przy przeszukiwaniu takiej tabeli ocen np?
   [bo szczerze to jestem troche lama w temacie]

   SM-S908

   1. ROTFL , Norton 23/12/08 07:25
      Jak Ci powiem, że ciągle rozbudowuję aplikację łączącą w niektórych przypadkach 3 tabele, gdzie jedna ma 12mln rekordów, druga 9 a trzecia 3,5mln i nie ma problemu z wydajnością to Cię uspokoi?
      
      I nie nazywaj pola poprostu id. Why?
      Bo w 3 tabelach będziesz miał pole o tej samej nazwie. Później będziesz to rozbudowywał i ci się zacznie kiełbasić.,
      
      users
      id_uzytkownika, user_imie, user_nazwisko
      
      komentarze
      id_koment, id_uzytkownika, tresc_komentarza
      
      oceny
      id_oceny, id_komentarza, id_uzytkownika, ocena
      
      itd.
      
      Oczywiście im klucze będą krótsiejsze tym lepiej.

      Zmień swój podpis na Boardzie
      maks 100 znaków, 3 linie,
      zabroniony spam oraz reklama

      1. musze sie przyczepic , waski 23/12/08 08:57
         Przykladowe polsko - angielskie (user_imie) nazwy kolumn to mega wiocha :p Calosc powinna byc po angielsku!
         
         Rozumiem sytuacje, gdzie trzeba dodac do istniejacej tabeli (ktora ma wszystkie nazwy po polsku) dodatkowe kolumny - wtedy dla zachowania tzw "spojnosci syfu" nalezaloby nowe kolumny rowniez nazwac po polsku... Ale kubazzz chce tworzyc nowa baze, wiec niech zrobi to porzadnie :)

         SNAFU
         Situation Normal, All Fucked Up

         1. a nazwy , Deus ex machine 23/12/08 09:41
            tabel users i komentarze? Pisza albo polskie albo angielskie nazwy, nie rob siaczki - chociaz jak zaczynasz to i tak bedziesz sie uczyl na bledach .)
            Aha i nie uzywaj DUZYCH LITER w nazwach tabel, pozniej jak przelozysz baze na linucha to bedzie roznica dla mysql czy nazwa z duzej czy malej przy MyISAM.

            "Uti non Abuti"

      2. masz moze namiary , Deus ex machine 23/12/08 09:52
         na jakas dobra lekturke o wydajnosci MySQL? Musialbym troszke podkrecic wydajnosciowo nasze bazy bo tez w miliony leca ilosci wierszy, a samych baz w dziesiatki.

         "Uti non Abuti"

      3. ale to jeszcze (o wydajności piszę) zależy od tego, jaką bazę się wybiera , bwana 23/12/08 10:58
         MyISAM i ten, no, ten drugi znany motor znany z MySQL-a, nie pamiętam nazwy, już wiem, InnoDB, pod względem wydajności (i rzecz jasna, funkcjonalności) się różnią. A np. indeksowanie pełnotekstowe w MySQL 5.2 to wiocha w porównaniu z Postgresem. Zawsze można użyć Śfinksa niby, ale...to już rozwiązanie zewnętrzne. Ważne, żeby wiedzieć co należy wybrać dla własnych potrzeb, nie?

         "you don't need your smile when I cut
         your throat"

         1. no a jeszcze inny 'problem' , kubazzz 23/12/08 13:24
            mamy listę użytkowników.
            Każdy z tych użytkowników może zrobić sobie kontakt z innym użytkownikiem [nasza-klasa], nie ma jakiś specjalnych ograniczeń co do ilości.
            To w jaki sposób zapisać to w bazach, bo tutaj zwykła relacja już nie wystarcza. Gdzieś trzeba przypisać wiele różnych ID_ZNAJOMEGO.
            
            a co do wydajności - ja mam na myśli typowo praktyczne zastosowanie w ramach strony internetowej, z hostingiem na serwerze. po prostu nie mam doświadczenia w tym i nie chciałbym, żeby przez moją niewiedzę marnowane były zasoby serwera.
            
            
            @bwana - co wybrać w takim razie?:) aolbo inaczej - czy myisam jest ok?

            SM-S908

            1. jaki problem? , Grocal 23/12/08 13:38
               CREATE TABLE IF NOT EXISTS `grocal_users_friends` (
               `ID_USER1` int(11) NOT NULL,
               `ID_USER2` int(11) NOT NULL,
               UNIQUE KEY `ID_USER1` (`ID_USER1`,`ID_USER2`)
               ) ENGINE=MyISAM DEFAULT CHARSET=utf8;

               Na pewno, na razie, w ogóle...
               Naprawdę, naprzeciwko, stąd...
               Ortografia nie gryzie!

               1. no czyli wtedy już trzeba zrobić osobną tabelę dla każdego użytkownika , kubazzz 23/12/08 14:00
                  o ten problem mi chodziło;)

                  SM-S908

                  1. nie trzeba... , rulezDC 23/12/08 15:18
                     z uzytkownikami masz przypadek wiele do wielu
                     robisz sobie tabele posrednia, w ktorej zapisujesz wszystkie przypadki polaczen uzytkownikow i tyle

                     koniec koniec koniec

                     1. cos takiego? , kubazzz 23/12/08 15:36
                        1 kubazzz grocal
                        2 kubazzz bwana
                        3 bwana grocal
                        4 grocal rulezdc
                        
                        kurde, tylko wtedy wg ktorej kolumny wybierac/segregowac,
                        
                        zeby nie przpypisywac grocalowi kubazzza kiedy kubazzzowi przypisany jest grocal.

                        SM-S908

                        1. dla czystosci mozna... , Grocal 23/12/08 16:19
                           ...przyjac zasade, ze do pierwszej kolumny dajesz ID mniejsze.

                           Na pewno, na razie, w ogóle...
                           Naprawdę, naprzeciwko, stąd...
                           Ortografia nie gryzie!

                           1. no dobra, ale jak to przeszukać teraz , kubazzz 23/12/08 19:12
                              jeśli chcę znależć wszystkich przyjaciół grocala, to muszę obie kolumny przeszukać bo grocal może być i w pierwszej i w drugiej, w zależności od tego czy jego przyjaciel miał wyższe czy niższe ID.

                              SM-S908

                              1. zasada, o której pisze Grocal jest po to, żeby nie duplikować funkcjonalnie związku , bwana 23/12/08 20:26
                                 między dwiema osobami, czyli dwoma wierszami tabeli. Jeżeli masz tabelę osób i intersekcję (id_osoby_1, id_osoby_2) do niej samej to musisz zapewnić sobie to, że unikniesz następujących błędów logicznych w danych:
                                 
                                 znajomi
                                 ----------------
                                 kubazzz, kubazzz
                                 
                                 
                                 znajomi
                                 ----------------
                                 kubazzz, bwana
                                 bwana, kubazzz
                                 
                                 To co trzeba zrobić, to zapewnić to, o czym pisał Grocal, oraz to, że nie następuje próba sparowania dwóch identycznych osób. na koniec wymóg unikalności na parę kolumn (id_osoby_1, id_osoby_2) i intersekcja jest poprawnie zdefiniowana.
                                 
                                 znajomych istotnie będziesz musiał szukać używając obu kolumn i zastrzegając w zapytaniu, że osoby1.id_osoby <> osoby2.id_osoby, żeby błędnie nie wykazać, że każdy jest własnym znajomym.

                                 "you don't need your smile when I cut
                                 your throat"

Pozdro...

SM-S908

"you don't need your smile when I cut
your throat"

1. dzięki za ten opis, takich rzeczy potrzebuję. o ilę rozumiem to teraz lepiej zrobić tak , kubazzz 23/12/08 23:02
   że jeśli mam użytkowników, każdy może wybrać czy jest polakiem, murzynem i katolikiem
   
   to ja planowałem zrobić tak
   USERS
   user_id user_name user_polak user_murzyn user_katolik user_województwo
   1 - kubazzz - 1 - 0 - 1 - malopolskie
   2 - Obama - 0 - 1 - 1 - foreign
   itd
   
   a powinienem zrobić
   USERS
   user_id user_name
   
   POLAKI
   polak_id user_id
   
   MURZYNY
   murzyn_id user_id
   
   KATOLIKI
   katolik_ud user_id
   
   ale co wtedy z województwem..
   kurde muszę się z tym przespać chyba, czaję ideę, ale żebym nie namieszał za dużo...

   SM-S908

   1. no, na opak zrozumiałeś:-D , bwana 23/12/08 23:25
      dobrze chciałeś zrobić:-D
      
      osoby
      -----------------
      id_osoby, polak, katolik, murzyn, id_wojewodztwa
      
      wojewodztwa
      ------------------
      id_wojewodztwa, nazwa
      
      ^^^ ten schemat jest ogólnie poprawny.

      "you don't need your smile when I cut
      your throat"

   2. jak masz jakies atrybuty , Deus ex machine 24/12/08 00:19
      bitowe (T/N,0/1) to pogrupuj je logicznie i zrob dla nich cale pole. Bo znajc zycie pozniej bedziesz chcial dodac kolejny atrybut i bedziesz tak sobie dopidywal kolejne kolumny. A tak jedna kolumna na jakas logiczna grupe i tylko dopisujesz kolejne bity, pamietajac o dokladnym opisie kolumny, zeby sie nie pogubic.

      "Uti non Abuti"

      1. tylko czy potem wybieranie na podstawie tych atrybutów będzie proste? , kubazzz 24/12/08 00:40
         chce znaleźć wszystkich murzynów, albo polaków albo katolików..
         
         
         A w ogóle to koncepcja jest trochę bardziej rozbudowana bo:
         polak, murzyn, katolik to są opcje true/false.
         ALE!
         Jeśli jest polakiem, to są dodatkowe atrybuty [już opisowe niech będą]
         - ród
         - region pochodzenia
         - tytuł szlachecki
         
         Jeśli jest murzynem, to:
         - odcień czerni
         - kształt twarzoczaski
         - region pochodzenia
         
         Jeśli katolikiem to:
         - data chrztu
         - parafia
         - częstotliwość spowiedzi
         
         Czy nie lepiej wtedy zrobić tak:
         
         USERS
         id_osoby | id_katolika | id_murzyna | id_polaka
         
         MURZYNY
         id_murzyna | odcien | twarzoczaska | region
         
         POLAKI
         id_polaka | region | tytul | ród
         
         KATOLIKI
         id_katolika | parafia | datachrztu | spowiedz
         
         
         wtedy jeśli nei jest katolikiem to wpisuję w USERS w id_katolika wartość 0/NULL
         
         
         Dobrze kombinuję?

         SM-S908

         1. to podstawowy dylemat przy przenoszeniu modelu obiektowego do bazy relacyjnej , bwana 24/12/08 01:24
            czy wsadzić wszystkie cechy atomowe do jednego wora, czy dzielić na muziny, polaki i katole, czy też może zrobić część wspólną "człowieki" i 3 przystawki z dodatkami (muziny, polaki i katole). Ze względu na wiele technicznych aspektów jestem za pierwszym sposobem, o ile liczba "mutacji" jest zamknięta i niewielka. Samo wyszukiwanie najprościej także zapisać w pierwszym przypadku, chociaż być może wyszukiwanie na podstawie frazy bitowej (czyli to, co opisał Deus) może być np. wydajniejsze przy konkretnych silnikach bazodanowych a i indeksowanie cech tak zapisanych może być korzystniejsze (aż się prosi o indeks bitmapowy). Nie wiem, czy argument o dodawaniu kolumn jest zasadny, czy nie - zależy to od konkretnej bazy (rozumiem, że to MySQL, który pewnie przynajmniej 255 kolumn dopuszcza) oraz od frameworku. Jeżeli framework się wywala po dodaniu kolumny do tabeli i wymaga szeregu poprawek, to lepiej jechać Deusem. Jeżeli framework przyjmie to ze spokojem, lepiej jechać bwaną;-D

            "you don't need your smile when I cut
            your throat"

            1. no ja jestem jednak za kolumnami, wszystko bedzie od zera i prosciej , kubazzz 24/12/08 01:32
               operowac na kolumnach.
               Mysql + php.
               
               Ale czy ten wariant co napisalem pozniej, dodatkowe pola dla murzynow, katoli i innych takich.
               Bo to sa niewspolne pola dla tych kategorii.

               SM-S908

               1. jeśli chcesz zrobić jedną wspólną tabelę dla wszystkich "wariacji na temat", tu kilka , bwana 24/12/08 12:18
                  praktycznych porad:
                  
                  stwórz sobie kolumnę z krótkim deskryptorem typu mutacji, nazwij np. typ_obiektu. Określ sobie krótkie nazwy typów, np. M, K, P. Potem dodaj do tabeli kolumny:
                  
                  M_Twarzoczaszka, M_Odcien, M_Region, K_Parafia, K_Datachrztu, ...
                  
                  Dzięki temu łatwiej będzie Ci obsługiwać różne przypadki w kodzie programu. Zadbaj też o to, by inne (te standardowe, niemutanckie) kolumny nie miały nazw zaczynających się od M_, P_, K_, żeby nie wprowadzać konfuzji. Tfu, nie robić zamieszania:-D

                  "you don't need your smile when I cut
                  your throat"

            2. a co do liczby mutacji , kubazzz 24/12/08 01:48
               niewielka, 10 maksymalnie, ale dla kazdej takiej opcji jest osobny zestaw kilku-kilkunastu cech [zalezy od opcji, twarzoczaszka, parafia itd]
               nawet jesli by to bylo rozwojowe to nie ma problemow z implementacja i na pewno nie zrobi sie z 10 opcji kilkaset.

               SM-S908

               1. pytanie na ile , Deus ex machine 24/12/08 15:16
                  wpisow liczysz taka tablice z uzyszkodnikami -
                  tysiac, setki tysiecy, pare milionow?

                  "Uti non Abuti"

2. Hehe i wtedy duza baza zaczyna potrzebowac masy pamieci i sprzetu. , ptoki 24/12/08 16:22
   To co opisales zgadza se w teorii i duzej czesci praktyki.
   
   Jednak jesli masz duza baze i wiele tabelek w takich postaciach normalnych to ze wzrostem skomplikowania aplikacji pojawiaja sie wielokrotne podzapytania, fikusne lub obszerne joiny oraz glupi programisci :) Troche pomagaja indexy w ilosciach okolo 1,5x ilosc danych a duzo pomaga odpowiednio wczesne przycinanie zakresu wyszukiwania czyli zamiast najpierw ciac po active=0 a potem operator_id=gienek, najpierw ciac po najwezszym zakresie wtedy najmniej nadmiarowych danych bedzie wciagniete do cache. I uprzedzam uwagi: Nie zawsze optymalizator jest w stanie takie sprawy wylapac a duze bazki updatuja statystyki nawet pare dni...
   
   I wtedy przychodzi do pracy pani Krysia ktora co 10 minut odpala raport roczny :)
   
   Bazki sa fajne, tyle rzeczy moze pojsc zle :)
   1. i właśnie dlatego... , bwana 28/12/08 09:16
      cyt. "w przypadku ogólnym" oraz cyt. "W praktyce bywa różnie, ale najczęściej zgodnie z teorią. ";-)
      
      Natomiast zaskoczyło mnie szacowanie "indeksy w ilościach około 1,5x ilość danych". Indeksy mają sens w następującej sytuacji:
      
      - indeks ma zastosowanie, czyli obejmuje kolumnę na którą wrażliwy jest plan wykonania zapytania (czyli kolumna służąca do złączenia tabel, kolumna z wartością wybieraną w klauzuli where, kolumna wg której następuje grupowanie, kolumna stanowiąca unikat w partycji funkcji analitycznej itp);
      - wykorzystanie indeksu ma sens, czyli otwarcie indeksu i załadowanie go do pamięci trwa na tyle krócej od zrobienia full scanu po tabeli, że warto utrzymywać indeks; selektywność kolumny ma tu ogromne znaczenie, dobór rodzaju indeksu do tej selektywności również.
      
      Co do optymalizatora i odświeżania statystyk, to cóż - duża baza swoje prawa ma;-D Fakt, że w zastosowaniach praktycznych zetknąłem się raczej z niewielkimi bazami (powiedzmy kilkaset milionów rekordów na tabelę maksymalnie) ale o dość wydumanej strukturze (jak ktoś zna Oracle EBS to wie, o co biega) - i faktycznie, są sytuacje w których dobrze zaplanowana denormalizacja daje określone zyski. Ale pamiętajmy - to ma być denormalizacja (czyli świadome "popsucie" znormalizowanej bazy) a nie defekt skutkiem bałaganiarstwa.
      
      Pani Krysia to oczywiście zabijacz bazy, ale z drugiej strony raportowanie online staje się coraz bardziej passe.

      "you don't need your smile when I cut
      your throat"

      1. Co do indexow to taka jest ostatnio moda , ptoki 28/12/08 12:09
         Nie jestem na bierzaco ale z tego co wiem to ilosc indexow w stosunku do danych we wspolczesnych bazach/aplikacjach coraz bardziej rosnie.
         Kiedys norma bylo 5-10-20% indexow w bazie, dzis normalne jest ze zajmuja 30-50% w szczegolnych przypadkach nawet wiecej.
         
         Bierze sie to z filozofii oprogramowania gdzie szuka sie po wszystkim (czas to pieniadz, jak klient nie pamieta nip-u to podaje imie nazwisko i numer buta i tez go znajdziemy bo jakby szukal nip-u, regonu, numeru klienta i co tam jeszcze mu nadano to by zeszlo dluugo) oprocz tego aplikacje webowe wymagaja krotkich czasow wyszukiwania i stad bierze sie taka monstrualna ilosc indexow. Po prostu na wszystko nakladany jest index. i o ile dla varchar-ow index jest mniejszy od danych to dla date czy integer juz zazwyczaj index jest wiekszy od samych danych....
         
         A co do raportowania to oczywiscie ze rozsadniejszym jest generowanie raportow zawczasu i ich zapisywanie lub zapisywanie zagregowanych danych na kolejne dni ale dla niektorych spraw tak sie nie daje. np. Aby na bierzaco rozliczac ludzi z pracy. Tutaj trzeba szurac po bazie kilka razy na dzien dla kazdego pracownika aby wiedziec ile dzis zrobili.