[spike200]

#programowanie #pytanie #mysql

Na stronie mam dużo itemów, które chcę, by miały dodatkową tabelę wyświetloną na stronie. Tabela ta będzie mogła mieć dużo pól. Wyglądałaby tak:

# | rank1 | rank2 | [...] | rank10
1 | 30 | 100 | | 500
2 | 25 | 90 | | 400
3 | 20 | 80 | | 300
4 | 10 | 60 | | 100
5 | 5 | 30 | | 80
[...]
40 | 2 | 10 | | 30

Ilość wierszy oraz kolumn byłaby zmienna.

Każdy item miałby taką tabelkę. Tych itemów mogłoby być 100, a ich tabele wyświetlane byłyby pojedynczo, po jednej na stronę.

Jak dobrze to zapisać w bazie? Najprościej zrobić osobną tabelę, gdzie w relacji byłby rank, relacja z itemem i pole z rank oraz wartość. Tylko tego byłoby bardzo dużo.

Mój plan jest taki, by każdy item miał jedną dodatkową kolumnę text po prostu z jsonem tej tabeli.

Czy to dobre rozwiązanie? Macie jakieś sugestie?

[s.....a]

Tylko tego byłoby bardzo dużo.

@spike200: zdefiniuj 'bardzo dużo'. Dziesiątki milionów lub więcej?

Generalnie klasyczna relacja one to many - dwie tablice Items(itemId(PK), ...) i ItemAttributes(attributeId(PK), itemId(Foreign key), name, value, ...)

Json w tabeli też zadziała, jeżeli nie potrzebujesz (i raczej nie będziesz potrzebował) wyszukiwać po wartości atrybutow

[spike200]

@sakfa: Jeśli item ma taką tabelę jaką przedstawiłem, to byłoby 40 x 10 wierszy na item. 40 miejsc na 10 rank. Czyli 400 wierszy na item. Itemów 100, to 40000 wierwszy w takiej tabeli z relacjami. Ilość kolumn jest dynamiczna i byłaby relacją, ilość wierszy też jest dynamiczna, ale bez relacji.

[januzi]

@spike200: to trzymaj dane w dwóch tabelach, jedna na itemy, druga na wartość rang i inne dane meta

[spike200]

@januzi: Hmm, no ale to nadal 40000 wierszy wtedy, zamiast jednego jsona na item, który nie jest jakiś duży, no nie?

No bo rangi mam osobno, jest ich 10 lub więcej.
Itemy mam osobno, jest ich 100 lub więcej.

Teraz jeśli chcieć zapisać to w bazie, to tabela wyglądałaby tak:

rankid (relacja) | itemid (relacja) | value

Więc na jeden item byłoby nadal 400 wierwszy, bo 10 relacji rank

[s.....a]

@spike200: trochę nie doceniasz mocy obliczeniowej komputera. 40 000 to tyle co nic, mógłbyś to przechowywać w pamięci i przeszukiwać liniowo i nie zauważyłbyś różnicy.

Generalnie json jest OK, ale wcale nie musi być bardziej wydajny (parsowanie jsona też kosztuje) i będzie paskudny w utrzymaniu (wyszukiwanie atrybutów, dodawanie nowych, usuwanie starych, itp. - to wszystko będzie odrobinę bardziej skomplikowane)

Tak czy siak - nie przejmuj się wydajnością dopóki nie będziesz miał

[spike200]

@sakfa: No może niedoceniam, wydaje mi się to dosyć dużo, jeśli miałyby być dwie relacje na 40000 elementów. Sam nie wiem, ciężko mi znaleźć jakieś informacje o tym w necie. A sparsować json, to w sumie jeden foreach, bez żadnych relacji. Tylko gorzej to utrzymać. Ale z drugiej strony zmienić później jsona na relacje to prościzna, tak samo w drugą stronie.

Json wydaje mi się prostszy do zrobienia, szczególnie, że te

[bekawpracy]

@spike200: najbardziej optymalna byłaby tu tabela typu parent-child