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

[darko]

(OT?) Ges tak czytam ten artykuł, do którego wkleiłeś link i częściowo potwierdza on to, co napisałem wcześniej, częściowo wzbogaca moją wiedzę (i za to dzięki):

Why You Shouldn't Use SET

The MySQL SET datatype is not commonly used for a few reasons; First, using the MySQL SET datatype limits you to 64 elements. While you could get around this by using multiple SETs, this still represents a loss of versatility. Second, you cannot include commas in your set elements, as the comma is an element separator.Third, using a set means your data is not normalized. In our above example, we are tracking a person's interests for a hypothetical dating site. In a normalized schema, there should be three tables: one for the person, one for all possible interests, and one that links a person to their particular interests. Fourth, an INDEX on a set datatype is going to refer to the set as a whole and will not be used for searching individual elements (this may or may not be a problem for certain applications).

Sam autor artykułu przyznaje, że zastosowanie setów nie jest drogą do normalizacji bazy danych. To tak jakbyś luźno wiązał ze sobą grupy do 64 rekordów w bazie. Według mnie - to się właśnie później zemści. Brak relacji, ograniczone możliwości wyszukiwania, czy to ma w czymś pomóc w przyszłości, czy takie podejście jest dalekowzroczne? Nie przekonałeś mnie. Twoja propozycja rozwiązania jest dobra w przypadku niewielkich, a nawet małych zbiorów rekordów, po za tym nie jest to rozwiązanie uniwersalne i narzuca pewne istotne ograniczenia (i wg. mnie tworzy też utrudnienia związane z wyszukiwaniem).

Dla mnie budowanie relacji na podstawie kluczy obcych to podstawowe zagadnienie związane z relacyjnymi bazami danych. Klucze służą do opisywania relacji pomiędzy tabelami i szczerze przyznaję, że nie chce mi się wierzyć, że zbiory setów są - przy dużej ilości rekordów - dużo bardziej wydajniejsze (a może są, ale na krótką metę, później zrobi się z bazy jeden wielki kocioł z bigosem).

Oczywiście trzeba Ci oddać, że generalnie operacje bitowe są przeprowadzanie szybciej niż wyciąganie kluczy obcych i tu się zgadzamy, ale nie proponowałbym takiego rozwiązania na dłuższą metę, a już na pewno nie określałbym go jako bardziej dalekowzrocznego niż relacje na FK.

exseerius - jeśli jesteś pewien, że ilość opcji, które ma do wyboru Twój user nie przekroczy 64, nie będziesz miał olbrzymiej bazy userów i nie potrzebujesz wyszukiwać opcji wyboru według różnych warunków, to śmiało rozważ zastosowanie proponowane przez Ges. W przeciwnym razie proponuję tworzenie prostych relacji pomiędzy tabelami i dalszą normalizację bazy (w zależności od rodzaju i ilości opcji wybieranych przez użytkowników). Oczywiście relacje zawarte w moim poście można jeszcze lepiej (wydajniej) określić, to była tylko propozycja, szkic.

Pozdrawiam.