Mam problem, jak rozwiązać daną sprawę:

Zapisywać values oddzielone separatorem?

--- id1 --- | --- id2 --- | --- values ------------
---- 1 ---- | ---- 1 ---- | --- 4,5,2,4,6,6 -------
---- 2 ---- | ---- 1 ---- | --- 4,5,2,4,6 ---------
---- 2 ---- | ---- 2 ---- | --- 4,5,2,4,6,7,2 -----


czy może oddzielnie zapisywać każde value?

--- id1 --- | --- id2 --- | --- order_value --- | -- value --
---- 1 ---- | ---- 1 ---- | --------- 1 ---------- | -- 4 -------
---- 1 ---- | ---- 1 ---- | --------- 2 ---------- | -- 5 -------
---- 1 ---- | ---- 1 ---- | --------- 3 ---------- | -- 2 -------


Dodam, że tych VALUE mogą być setki tysięcy, a nawet miliony.

Wydaje się, że optymalniejszym będzie sposób 1? Czy może jednak 2?
Wyświetlane będą np wszystkie values gdzie id1 = coś i id2 = coś. A także będą sumowane, dzielone, mnożone, więc będzie na nich dużo operacji. Dodatkowo, liczona może być ilość powtórzeń tej samej wartości value dla danego id. Muszą być w odpowiedniej kolejności. Danych values dla danego id będzie maksymalnie 10.

Więc może jednak ten drugi sposób i ogromna ilość tych rekordów, nie będzie miała na nic wpływu? Dane te będą dość często wyświetlane. Ale też dość dużo ich dodawanych jednocześnie, myślę że około 500.

Nie mam pojęcia jak to rozegrać, jeśli potrzeba jakichś informacji jeszcze, to proszę pytać.

Zdecydowanie 2.
O 1 zapomnij, że istnieje.
Chyba że wybierzesz inną bazę np. postgreSQL, wtedy jeszcze dochodzi int[]

pierwsze rozwiązanie ma sens pod jednym warunkiem nie będziesz wykonywał ŻADNYCH operacji na tym polu poza select

inaczej przeprojektuj tabele do relacji wiele_do_wielu

jest to klasyczny antywzorzec, i jako taki jest też opisany.
jesli potrzebujesz utrzymać hierarchię w danych - zainteresuj się strukturami do ich przechowywania.
masz ich kilka, i być może drzewko IP będzie dla ciebie najwygodniejszym rozwiązaniem

udało Ci się podać drugi z klasycznych antywzorców dla sql'a, a to nie mały sukces
zainwestuj być może w jakaś książkę, jeśli planujesz dłuższą przygodę z bazami danych.


pozdrawiam,
J.

Okay 1. wywalamy.


No ale 2. przykład to właśnie wiele do wielu.

Jeden id może mieć wiele values, a także jedno values może mieć wiele id. Jak można to inaczej zapisać?

Tworzenie drzewa, nie jest mi potrzebne, bo i po co? Teoretycznie kolumnę order_values można wywalić i dać id z autoincrement do wyświetlania kolejności. Kolejność nie będzie nigdy zmieniana, jest tylko ważna przy wyświetlaniu.

"Książka inwestycją" to wg mnie największy oksymoron.

relacja w jednej tabeli a to ciekawe
http://pl.wikibooks.org/wiki/PHP/Relacje_i_indeksy

Nie, wkleję Ci 10000 tabel do których się odwołuję w id1 i id2, żebyś mógł podziwiać jakie ładne nazwy mają...
Bo nie ma to żadnego związku z problemem.

Problemem jest to, czy trzymać milion wartości values w oddzielnych rekordach, czy łączyć je po id niektórych kolumn (po których to będą wyświetlane), żeby zaoszczędzić miejsca. Ale mimo wszystko chyba nie warto oszczędzać tego miejsca, bo będą na nich wykonywane różne operacje. A z miliona zrobimy minimalnie 100tys rekordów, bo tych wartości values maxymalnie dla wspólnych id może być 10.

a kto ci każe tworzyć 10000 tabel ?
możesz to zrobić relacją jeden do wielu

tabela1
id1 | id2 | jakieś inne pola
----------------------------
1 | 1 | .....
2 | 1 | .....
2 | 2 | .....
____________________
tabela2
id1 | id2 | value
------------------
1|1|4
1|1|5
1|1|2
1|1|8
1|1|16
2|1|22
2|1|33
2|2|4
2|2|5
2|2|3


to odpowiada
id1|id2|values| jakieś inne pola
1|1|4,5,2,8,16|...
2|1|22,33|...
2|2|4,5,3|...


i gdzie te 10000 tabel dla 10000 opcji bo ja wodzę tylko dwie



edit:
oczywiście wersja z przecinkami jest prawidłowa jeśli dane w tej postaci są atomowe(a u Ciebie pewnie nie są)

Chryste Panie, to była hiperbola do bezsensownego posta wyżej. Te tabele są i jest ich tyle ile potrzeba. To nie jest problem wątku.

Na to że to pierwsze odpowiada temu drugiemu wpadłem w 1. poście jak widać, tylko zrobiłem to przykładowo na szybko na jednej tabeli. Moje pytanie brzmi: czy w przyszłości gdy będziemy mieli milion takich rekordów w danej tabeli, nie będzie to zbyt dużym obciążeniem, szczególnie przy wyszukiwaniu?

milon rekordow nie jest przeszkoda przy prawidlowo zaprojektowanej strukturze.

pozakładaj dobre indexy, pomyśl czy da się pozakładać partycje na tabeli.
explain, i profilowanie zapytań - wyłapanie wąskich gardeł, aktualnyi odpowiedni silnik db, dostosowanie platformy sprzętowej do projektu - i będzie dobrze. kilku-kilkunasto milionowe tabele nie są żadnym problemem.

j.