konto usunięte

Temat: relacje / indeksy

Projektuję bazę danych (MySQL). Chciałbym mieć komentarze do wszystkiego (tj. do galerii, do zdjęć, do artykułów) w jeden tabeli.
Czy indeksy w tabeli "komentarze" na kolumny komentarz_do, item_id wystarczą aby to sprawnie działało? Czy jest jakieś mądrzejsze rozwiązanie tego zagadnienia ? (np. kilka kluczy obcych (nullable) w tabeli komentarze)

W przypadku kasowania np. artykułu muszę chyba pisać trigera,
odpadają rozwiązania onDelete itp. jakie daje nam INNODB?

Czekam na sugestie poparte doświadczeniem ;)
Adam O.

Adam O. Bazy danych etc

Temat: relacje / indeksy

Komentarz nie poparty doświadczeniem (bo nigdy nie próbowałem wiązać takim dziwacznym pół-kluczem kilku tabel) - zrób sobie komentarze do każdej tabeli osobno, bez różnicy czy to będzie dodatkowa tabela dla każdej jednej tabeli bazowej, czy (bardziej prawdopodobne i sensowne) dodatkowa kolumna w każdej tabeli, a jak chcesz mieć to ładnie pogrupowane w jednym obiekcie - użyj widoku. Jak chcesz do tego korzystać z widoku żeby robić inserty - użyj triggerów instead of (jeżeli są takie w mysql, mało używałem tego silnika więc nie wiem).

Sposób w jaki to zaproponowałeś - nie twierdzę że nie zadziała. Pewnie Ci się uda to tak zaprojektować i oprogramować. I pewnie będzie działać. Ale to się prosi o problemy w przyszłości.

Z trzeciej strony - jeżeli olewasz przyszłość, zrób po swojemu, może przypadkiem wymyślisz nowy magiczny schemat;)
Grzegorz G.

Grzegorz G. Kierownik projektów,
Programista Oracle,
Administrator ba...

Temat: relacje / indeksy

Witam, dodałbym jeszcze pytanie jak dużo będzie tych danych? Budowanie indeksów dla tabel gdzie danych jest stosunkowo mało nie ma sensu (oczywiście trzeba też zdefiniować co to jest mało danych w tabeli dla danej bazy na danym serwerze?)
Indeks na tabeli wydłuża czas operacji DML (insert, update, delete), może pomóc przy wykonywaniu zapytań ale zapytania muszą być też odpowiednio skonstruowane , tak aby wykorzystywały indeksy.
Przy wykorzystaniu MySQL do budowy strony internetowej (przypuszczam takie zastosowanie), na której ilość danych nie będzie lawinowo rosła – nie będzie to np. bardzo popularne forum czy coś podobnego, moim zdaniem nie ma potrzeby budować indeksów. Poza tym w przypadku stwierdzenia małej wydajności bazy zawsze można zbudować indeks i sprawdzić czy coś on zmieni w szybkości działania.

konto usunięte

Temat: relacje / indeksy

Artykułów na tą chwilę jest spokojnie ponad 20k.

Pomysł z dziwacznym kluczem wziął się z rozszerzenia Doctrina,
gdzie właśnie w taki sposób jest to rozwiązane.

Fakt, rozbicie na kilka tabel z pewnością skróci czas aktualizacji indeksu na akcje insert (itd. itp.)
Adam O.:
Sposób w jaki to zaproponowałeś - nie twierdzę że nie zadziała. Pewnie Ci się uda to tak zaprojektować i oprogramować. I pewnie będzie działać. Ale to się prosi o problemy w przyszłości.
proszę rozwiń ew. problem w przyszłości.Łukasz Ciołek edytował(a) ten post dnia 17.10.11 o godzinie 15:47
Adam O.

Adam O. Bazy danych etc

Temat: relacje / indeksy

Adam O.:
Sposób w jaki to zaproponowałeś - nie twierdzę że nie zadziała. Pewnie Ci się uda to tak zaprojektować i oprogramować. I pewnie będzie działać. Ale to się prosi o problemy w przyszłości.
proszę rozwiń ew. problem w przyszłości.

Problem w przyszłości to taki, że, o ile to nie jest "jednorazówka" i "prowizorka", to ktoś kto to w przyszłości przejmie i będzie obsługiwał, będzie wyklinał pomysł z joinowaniem tabeli jednej z drugą w zależności od zawartości którejś z nich. Dynamiczny sql nigdy nie jest przyjemny w utrzymaniu.

konto usunięte

Temat: relacje / indeksy

szczerze to ja również sceptycznie patrzyłem na to rozwiązanie..
nie bez powodu rozwój poszedł w stronę InnoDB.
Ta mieszanka FK przypomina mi nieco czasy MyISAM.

niestety Doctrine2 nie ma chyba widoków. Przynajmniej ja nie mogę dotrzeć do tego w dokumentacji..

konto usunięte

Temat: relacje / indeksy

Ewentualnie... Kilka razy widziałem już w niektórych rozwiązaniach taki sposób, że każdy obiekt posiada unikalny identyfikator w obrębie całej bazy. Przy tym podejściu w tabelce z komentarzami wystarczy sam id, bez typu obiektu, a złączenia są naturalne. Nie używałem w praktyce, nie wiem jak to wyjdzie "w praniu". Potencjalna niedogodność to trudność wybrania np. wszystkich komentarzy dla wszystkich zdjęć (dodatkowe złączenie).

Problemy w przyszłości - jeśli okaże się, że komentarze zdjęć i komentarze artykułów zachowują się w trochę inny sposób, mają inne dodatkowe atrybuty, itp... zrobi się bajzel.

konto usunięte

Temat: relacje / indeksy

Wtedy na pomoc przychodzą widoki :)
Łukasz Pluta:
Ewentualnie... Kilka razy widziałem już w niektórych rozwiązaniach taki sposób, że każdy obiekt posiada unikalny identyfikator w obrębie całej bazy. Przy tym podejściu w tabelce z komentarzami wystarczy sam id, bez typu obiektu, a złączenia są naturalne. Nie używałem w praktyce, nie wiem jak to wyjdzie "w praniu". Potencjalna niedogodność to trudność wybrania np. wszystkich komentarzy dla wszystkich zdjęć (dodatkowe złączenie).

Problemy w przyszłości - jeśli okaże się, że komentarze zdjęć i komentarze artykułów zachowują się w trochę inny sposób, mają inne dodatkowe atrybuty, itp... zrobi się bajzel.
Jakub Fila

Jakub Fila Inżynieria / finanse
/ zarządzanie

Temat: relacje / indeksy

Sebastian Zaborowski:
Wtedy na pomoc przychodzą widoki :)

Jeśli danych będzie dużo, to najlepiej zmaterializowane. Niezmaterializowany widok to nadal tylko zapytanie, więc wszystkie join'y będą kosztować tyle samo.
Paweł Lipka

Paweł Lipka Student,
Politechnika
Warszawska

Temat: relacje / indeksy

Tyle że zmaterializowane widoki to już raczej ORACLE niż MySQL :/

konto usunięte

Temat: relacje / indeksy

A od czego własna głowa? Jak nie ma funkcjonalności to ja trzeba zrobić. Widok = tabela tymczasowa. Tworzyć sobie taką i już.

Następna dyskusja:

Jakie indeksy utworzyc dla ...




Wyślij zaproszenie do