Witam,
zatsanawiam sie nad rozwiazaniem takiego problemu:
duzy serwis, kilkadziesiat tabel, w wielu dziesiatki tysiecy wierszy w niektorych tabelach. Do każdego z wierszy w tabeli "produkty" muszę dodac kilka znacznikow (np nowosc, przecena, bestseller itd)

PYTANIE:
Czy lepiej dodac kolumny do tej tabeli, czy zrobic osobną tabelę "znaczniki" o 2 kolumnach: id_produktu i typ_znacznika.

Któe rozwiazanie lepsze i dlaczego? Moje przemyslenia prowadza do tego, ze pierwsze pewnie jest szybsze, natomiast drugie bardziej elastyczne (np. gdy trzeba bedzie dodac nowy znacznik nei trzeba zmieniac struktury tabeli). Jednak każde zapytanie o produkt wiaze sie z joinem z nową tabelą "znaczniki", co z pewnoscia obciaza baze. Ale czy bardzo? Któro rozwiazanie lepiej zastosowac i dlaczego? Wazna jest stabilnosc i szybkosc dzialania.

pozdrawiam

NIe, nie dodawaj kolumn.
Albo zrób drugi sposób co podałeś, albo te znaczniki przechowuj w jednej kolumnie:
http://nospor.pl/opcje-dwuwartosciowe-przechowywanie.html

@nospor: Flagi bitowe (można to tak nazywać?) mimo iż na pewno estetyczniejsze i często wygodniejsze w obsłudze będą miały tutaj jedną wadę - MySQL nie będzie wykorzystywać indeksu dla tej kolumny co przy wyszukiwaniu może być dosyć kosztowe.

Dlatego też IMO w takim przypadku najlepiej dowalić kilka kolumn o wartościach 0 / 1 informujących o tym czy dana cecha / flaga jest aktywna - powinno to być wydajniejsze, ale będzie mniej elastyczne (jeżeli chodzi o rozbudowę) od zewnętrznej tabeli czy flag bitowych.

Ale w rozwiązaniu nospora są normalne indeksy. Co prawda mało sensowne ale są.

Flaga to flaga, nie ma powodu żeby to komplikować.
Od czegoś jest typ bit(1) 0, albo 1.
Jak zakodujesz to w jedno pole i masz powiedzmy 5 flag to teraz będziesz się głowił co tu zrobić żeby dostać select * from table where flaga_3 = 0

One sprawdzą się tylko i wyłącznie przy zapiyaniach typu

[SQL] pobierz, plaintext 
WHERE bitmask = 32
[SQL] pobierz, plaintext 

Ale przy czymś w rodzaju

[SQL] pobierz, plaintext 
WHERE bitmask & 32
[SQL] pobierz, plaintext 

Są bezużyteczne.

Ale przecież nikt nie mówił, że masz tego używać w ten sposób. Wydzielenie każdego bitu do oddzielnego pola umożliwia Ci wyszukiwanie elementów które mają ustawiony określony bit. To jest porównanie bitowe tylko zrealizowane w inny sposób.

Ale jak ma się rozwiązanie nospora do łatwości modyfikacji? Powiedzmy że liczba znaczników zmienia się, część staje niepotrzebna, dochodzą nowe. W normalnym rozwiązaniu usuwam/dodaję kolumny (które są niezależne od pozycji w tabeli). W rozwiązaniu nospora pozycja definiuje opcję (chyba że się mylę) - więc przebudowa jest raczej skomplikowana. Manipulacja kolumnami jest sensowniejszym rozwiązaniem.

Z tymi indeksami to aż sam sprawdzę.

A co ty masz za opcje ze je tak nagle dla wszystkich będziesz kasował?
Ale tak, masz rację. Jak określisz, że 2 to jakaś tam opcja, i nagle z niej zrezygnujesz, to masz dwie możliwości:
- 2 już nie będziesz wykorzystywał
- pod 2 wstawisz kolejną nową opcję

Jeśli zaś będziesz chciał dodać kolejną opcję, to jeśli miałeś 4 opcje (1,2,4,8) to kolejna opcja to będzie liczba 16, jeszcze kolejna 32.

Wydaje mi się, że jeśli już chcesz żonglować tymi opcjami i nie podobają ci się bity to lepiej zrób dodatkową tabelę jak pisałeś niż będziesz dodawał ciągle kolejne kolumny do tabeli.

@nospor dzieki za odp, rozwiazanie bardzo ciekawe i w kilku innych miejscach z niego skorzystam, nadal zastanawiam sie jednak nad korzysciami wykorzystania tego rozwiązania akurat w tym przypadku. Tutaj chyba jednak dodam kolejną tabelę, która będzie zawierać dodatkowe informacje - zapytania będą bardziej kosztowne, ale za baza pozostanie bardziej przejrzysta i elastyczna.

pozdrawiam

Podałem to rozwiązanie tylko i wyłącznie dlatego, że chciałeś użyć oddzielnych kolumn w tabeli. To była taka alternatywa dla tej opcji.
Jeśli jednak zamierzasz użyć oddzielnej tabeli, to wydaje mi się to lepsze dla tej sytuacji.