Problem z zaprojektowaniem bazy danych., Zapis wyborów uzytkowniaka do bazy danych mysql. Opcje

[exseerius]

Witam, mam problem, z optymalizacją.

Mam strone, gdzie loguja się uzytkownicy i w swoim profilu maja kilka opcji do wyboru (ok 15).

przykładowo:

ulubiony kolor:
[_] zielony
[_] niebieski
[_] czerwony itp.

do tej pory rozwiazałem problem tak, że w bazie danych mam kolumne kolory i tam zapis w postaci 1.0.0.1.1.1.1.0.1.0...
1 odpowiada włączonej opcji, 0 wyłaczonej

W sumie działa jak powinno, ale musze te dane obrabiać, explodem i jest problem z kolejnością, bo dane muszą zawsze wyswietlać się w kolejnosci jaka pierwotnie została podana w array zadeklarowanym w dokumencie. Druga sprawa to problem z wyszukiwaniem, bo stworzenie zapytania gdzie WHERE wygląda np tak.

WHERE kolor = 0.0.0.0.0.0.1.1.0.0.0.0 OR 1.1.1.1.1.0.0.0.0.0 itp jest trochę na około.

Czy jest mozliwość rozwiązania tego w inny sposób?

Wymysliłem dwa rozwiązania, ale nie wiem czy bedą one optymalne:

#1 dwie tabele, jedna z definicją kolorów

id | kolor
1 | niebieski
2 | zielony

druga wybory
id | user | wybor_1 | wybor_2 | wybor_3
1 | 1 | true | flase | true

php sprawdza opcje wyszukujac kluczy "WHERE wybor_"kolor.id - trochę lepsze rozwiązanie, ale chyba nadal jest to nie to co ma być, bo dopisanie kolejnego koloru dowyboru musze dopisać kolejną kolumne w "wyborach"

#2 drugie rozwiązanie siedzi u mnie tylko w głowie, bo nie wiem jak do końca to rozwiązać.
Mianowicie utworzenie tabeli np. wybory, gdzie jako nazwy kolumn będa opcje możliwe do wyboru (niektóre zawierają polskie znaki, znaki /\-=+).

np.

id | user | niebieski | zielony | czerwony | jasno-żółty
1 | 1 | true | true | false | true

i pytanie co jest lepsze w filtrowaniu danych. Jak wyświetlić na stronie tylko nagłówki kolumn z pominieciem id i user.


Ewentualnie jaki jeszcze inny sposób proponujecie na rozwiązanie tej zagwostki w taki sposób, aby łatwo było napisać pod to wyszukiwarkę.

Ten post edytował exseerius 2.11.2009, 14:01:18

[Ges]

Hmm. Jak będzie miał powyżej 64 elementów, to może wtedy niech zacznie się martwić o stosowanie innego rozwiązania. Moim zdaniem SET w opisanym przypadku jest idealnym rozwiązaniem i najprostszym.

Jak dojdzie "ileś tam danych" to myślę, że założy wtedy nowy topic (IMG:style_emoticons/default/smile.gif) W tym wypadku wg opisu chodziło o zapisanie zestawu BOOLEANÓW i ich kombinacji. Co jest z definicji SETem w SQL.

Co do robienia kolejnych tablic i robienia kolejnych JOIN, to jest dość krótkowzroczne myślenie wg mnie. Każdy JOIN (w Twoim rozwiązaniu potrójny) jest mega kosztowną operacją i w przypadku gdy dojdzie do tych tabel około 100k wierszy userów taki JOIN może zabić bazę i będzie czekał porenaście sekund na odpowiedź. Jak będzie miał więcej opcji niż teraz, to ja bym skusił się nawet o założenie kolejnej kolumny SETów które pomieści kolejne 64 booleany, a JOINy omijałbym szerokim łukiem. Ale to może moje zboczenie myślenia o optymalizacji każdego rozwiązania, a nie robienia wszystkiego na pierwszy wymyślony sposób (IMG:style_emoticons/default/smile.gif)

Poza tym zamiast 1 INSERTa w Twoim rozwiązaniu jest ich tyle ile opcji (sic !). Kolejne samobójstwo (IMG:style_emoticons/default/smile.gif)
No i UPDATE poprzez ustawienie wszystkiego na 0 i potem mase INSERTÓW ? Naprawdę nie widzisz w takim rowiązaniu przerostu ? (IMG:style_emoticons/default/smile.gif)

Oczywiście dobór rozwiązania zależy od jego twórcy i to on powinnien ocenić co dla niego będzie korzystniejsze. Ja bym tylko polecał dobór jak najprostszego i najbardziej dopasowanego rozwiązania do jego problemu, a nie robienie czegoś na wyrost.