Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Baza danych kilka pytań
Forum PHP.pl > Forum > Bazy danych > MySQL
Gribo
Witam mam taki schemat bazy danych :

  1. CREATE TABLE IF NOT EXISTS `directory` (
  2. `id_directory` int(11) NOT NULL,
  3. `url` varchar(45) DEFAULT NULL,
  4. PRIMARY KEY (`id_directory`)
  5. ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
  6.  
  7. CREATE TABLE IF NOT EXISTS `project` (
  8. `id_project` int(11) NOT NULL AUTO_INCREMENT,
  9. `id_user` int(11) NOT NULL,
  10. `id_database` int(11) NOT NULL,
  11. `name` varchar(255) DEFAULT NULL,
  12. `description` text,
  13. `site_url` varchar(100) DEFAULT NULL,
  14. `site_title` varchar(100) DEFAULT NULL,
  15. `site_description` text,
  16. `site_keywords` varchar(255) DEFAULT NULL,
  17. `site_keywords_value` int(11) DEFAULT NULL,
  18. `site_email` varchar(100) DEFAULT NULL,
  19. `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  20. PRIMARY KEY (`id_project`)
  21. ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
  22.  
  23.  
  24. CREATE TABLE IF NOT EXISTS `project_direcory` (
  25. `id_project` int(11) NOT NULL,
  26. `id_directory` int(11) NOT NULL,
  27. `status` varchar(45) DEFAULT NULL,
  28. PRIMARY KEY (`id_project`,`id_directory`)
  29. ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
  30.  
  31.  



Moje pytanie brzmi : zakładając że w tabeli directory bede miał około 7 tysięcy wierszy w tabeli project_direcory będzie mega dużo powiazań zaużmy że pojawi sie tylko 100 projektów a liczba wpisów w tabeli project_direcory będzie wynosiła 7000*100 = 700 000. Jak to inaczej mozna rozwiazać questionmark.gif

myślałem żeby w tabeli direcory wprowadzić np. nowe pole tekstowe status_success gdzie bym wpisywał po przecinku czy innym znaku id projektów. Ale jak po takiej polu później coś wyszukać questionmark.gif

w celu zobrazowania jak wyobrażam sobie taką tabele direcory po modyfikacji :
  1. CREATE TABLE IF NOT EXISTS `directory` (
  2. `id_directory` int(11) NOT NULL,
  3. `url` varchar(45) DEFAULT NULL,
  4. `staus_success` text,
  5. `staus_error` text,
  6. PRIMARY KEY (`id_directory`)
  7. ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
  8.  


i status_success wypełniał bym tak : 34,12,12,45,21,
gdzie liczy po przecinkach to id projektów;


Czy to dobry sposób na optymalizacje tej tabeli project_direcory questionmark.gif
jak wyszukiwać potem id w polu status_success questionmark.gifquestionmark.gif


Z góry dzięki za odp.
Wicepsik
Pierwszy sposób wydajniejszy.
Gribo
ale zakładając że bedzie tylko 100 projektów to 700 000 rekordów a co jak będzie 1000 czy 7 milionów to nie lekka przesada ?
phpion
Zdecydowanie rozwiązanie 1, żadne łączenie statusów przecinkami! Zmień typ pola statusu ze znakowego na TINYINT, a nie powinno być żadnych problemów z wydajnością (a i miejsca nieco zaoszczędzisz).

Pozostaje jeszcze kwestia klucza głównego w tabeli project_direcory. Czy na pewno składa się on z tych 2 kolumn? Wg mnie nie, powinien składać się ze wszystkich 3 kolumn (włącznie ze statusem). Jednak w takiej sytuacji para 1 projekt i 1 katalog (?) mogą przyjąć tylko 1 raz dany status. Jeśli dopuszczasz możliwość wystąpienia duplikatów to nie obejdzie się bez standardowej kolumny id z AUTO_INCREMENT jako klucz główny.
Gribo
nie ma możliwości wystąpienia duplikatów jeden projekt może mieć tylko jeden status danego katalogu. Z tym statusem rzeczywiście zmienię to na pole TINYINT, oczywiście założę tez Indeksy na wszystkie 3 kolumny.
phpion
Cytat(Gribo @ 1.11.2010, 00:10:09 ) *
oczywiście założę tez Indeksy na wszystkie 3 kolumny.

Oczywiście to będzie błąd. Dlaczego? Jeżeli klucz główny będzie składał się z trzech kolumn (id_project, id_directory, status) to nie ma sensu zakładać indeksu na kolumnę id_project. Wartości w kolumnie status pewnie nie będą zbytnio zróżnicowane (powiedzmy 10 różnych wartości) więc indeks na tej kolumnie również jest kwestią sporną. Zakładanie indeksów to wbrew pozorom nie taka prosta sprawa...
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.