Wydajność obu rozwiązań, seralize vs kilka tabel Opcje

[adrix88]

Witam. Piszę pewną aplikacje, jest to panel zarządzania usługami i zastanawiam się jakie rozwiązanie będzie lepsze i wydajniejsze

Mam tabelę z zakupionymi usługami np:

Tabela USŁUGI:
id / nazwa / var1 / var2 / var3 /var4 / var5 / itd. (w sumie około 60 pól)

i do tej usługi można aktywować sobie dodatki i właśnie zastanawiam się jak będzie wydajniej rozwiązać przypisywanie tych dodatków do tabeli. Zastanawiam się nad dwoma rozwiązaniami:

===================

Rozwiązanie 1.
Dodać do tabeli usługi nowe pole text w którym byłaby przechowywana tablica potraktowana funkcją serialize i ta tablica przechowywałaby listę aktywnych dodatków (byłyby to jedynie 2 dane, id usługi i id dodatku). Przy odczytywaniu listy dodatków będzie odczytywana tablica poprzez unserialize.

Rozwiązanie 2.
Dodać drugą tabelę DODATKI i w niej przechowywać informacje o aktywnych dodatkach dla danej usługi.

===================

Generalnie bardziej podoba mi się rozwiązanie pierwsze, bo nie muszę wtedy tworzyć skomplikowanych zapytań, czy pętli w pętli żeby wyciągnąć listę aktywnych dodatków, ale zastanawiam się jak tu będzie z wydajnością i obciążeniem. Ponieważ tabela USŁUGI zawiera aktualnie około 60 pól i do tego średnia liczba rekordów dla tej tabeli to ~4000, więc trochę już tych danych jest. Dodatkowo dodam że ta tabela jest używana praktycznie przy każdej operacji. Kolejną sprawą jest to że nie wiem jak jest z wydajnością funkcji seralize i unseralize, bo jakbym ich użył to by były dosyć często używane. Generalnie to pytanie jest takie, lepiej skorzystać z skomplikowanych zapytań na 2 tabelach lub pętli w pętli, czy też może lepsze będzie proste zapytanie odczytujące dane z tabeli i wyciągające tablice poprzez unseralize.

Ten post edytował adrix88 23.06.2011, 14:48:56

[tehaha]

Najlepiej rozwiązanie 2:
1. przechowując zserializowaną tablicę blokujesz możliwość wykorzystania tych wartości w zapytaniu, a to nawet jeśli teraz nie potrzebne to w przyszłości może się zdarzyć, więc lepiej od początku zrobić to tak jak trzeba
2. 4k rekordów to bardzo mało

nie wiem jaką dokładnie masz sytuacje, ale powinieneś mieć w tej sytuacji 3 tabele:
1. Usługi
2. Dodatki
3. Powiązanie ID usługi z ID dodatku

[adrix88]

Źle się wyraziłem w pierwszym poście. No właśnie jest tak:
1. Usługi
2. Dodatki

i właśnie chodzi mi w tym wątku o przechowywanie tego powiązania ID usługi i ID dodatku. Wygodniej mi byłoby odczytywać tablicę poprzez seralize, ale boje się że ucierpi na tym wydajność, bo nie wiem co będzie szybsze.

====

No jest 4K rekordów i może nie jest to dużo, ale w każdym rekordzie jest około 60 pól wypełnionych danymi.

[tehaha]

tablica wcale nie będzie łatwiejsza tak Ci się tylko wydaje bo pewnie nie jesteś za bardzo zapoznany z JOIN w mysql, dane w formacie serializa() są kompletnie nie poręczne i nic z nimi łatwo nie zrobisz, na prawdę dołożenie dodatkowej tabelki na powiązanie tego to nie jest duży problem i ułatwi Ci to życie, zwłaszcza jak masz sporo danych to raczej chcesz uniknąć sytuacji gdzie za kilka miesięcy trzeba będzie przerabiać strukturę bazy danych i dodatkowo pisać skrypty na przenoszenie danych.

P.s. ostatnio był właśnie temat z serii "użyłem tablicy zserializowanej bo myślałem, że będzie łatwiej a teraz jest problem" Temat: php mysqlSortowanie wynikow wg pol zapisanych jako serialize

[adrix88]

Może i masz rację. Tylko czy zapytania z JOINami nie będą aby wolne przy tak sporych tabelach? Nie będzie to znacznie wolniejsze od prostego zapytania + seralize? Bo kiedyś bawiłem się zapytaniami z JOINami i nie wiem czy nieumiejętnie je stosowałem, ale zapytanie wykonywało się o ponad 500% dłużej niż zwykłe zapytanie bez JOIN'a.

Możesz podać przykład jakbyś ułożył zapytanie w tym przypadku? To bym sobie je przeanalizował.

[tehaha]

prędzej bym się martwił o wydajność tej Twojej pierwszej metody, Tobie się wydaje, że co, że silnik bazy to był tworzony do obsługi 3 tabelek po 5 kolumn? Miałem serwisy gdzie w skrajnych przypadkach musiałem tworzyć nawet 18 JOIN'ów w jednym zapytaniu, mam też serwis gdzie w jednej tabeli w ciągu godziny przybywa 30k rekordów, więc Twoje lęki są całkowicie nie na miejscu. Jeżeli piszesz że zapytanie z JOIN działa 5 razy wolniej to wklej na to odpowiednie potwierdzenie bo takie dane z powietrza niczego nie dowodzą. Wklej oba kody jakie testowałeś, pokaż jak je testowałeś i struktury tabel to sprawdzimy czy faktycznie tak jest. Tutaj masz jak używać JOIN http://dev.mysql.com/doc/refman/5.0/en/join.html