ugrás a tartalomhoz

Mysql szerkezet

iddqd · 2015. Ápr. 2. (Cs), 17.35
Sziasztok, segítségre lenne szükségem.

Rendszer: PHP / Codeigniter + Mysql

A jelenlegi meglévő szerkezet:
Adva vannak elemek, kategóriák szerint csoportosítva - 10 különböző - és így listázva az adott oldalon. Ezek közül van olyan kategória, ami további alkategóriákra oszlik. Az alkategóriáknak több csoportjuk van és 1 elem több csoportba is tartozhat. Jelenleg az összes alkategória és hozzá tartozó elem 1 táblában van tárolva. Pl.: Szállások kat. : típusa ( Hotel *** ) + jellege ( wellness ). Többféle típus és jelleg van, 1 szállás rendelkezik 1 típussal és akár több jelleggel. Ez mind 1 táblában van, mint alkategória tábla: alkategoria_neve | elem_id.

Feladat: Szeretnék szűrhetővé tenni alkategóriák alapján a lekérdezett listát.
Értelemszerűen több típus és jelleg lehet egyszerre a feltétel, így azt gondolom ezzel a felállással ez nem megoldható.

Az én megoldásom az lenne eddig:
Mivel a különböző kategóriák különböző alkategóriákkal rendelkeznek, vagy egyel sem, így az hogy kibővítem a táblát több oszloppal ( szállás típusa, jellege, stb ) szerintem nem jó megoldás, mivel sok üres cella maradna.

Amire gondoltam az az, hogy minden alkategóriának létrehozok egy külön táblát ( ez jelenleg kb 6 db ) pl: szállás típusa tábla: típus | elem
Így megoldható, hogy megkapjam a keresett alkategóriák halmazát ( hotel** + hotel*** / wellness ) és nem lesznek redundáns tábláim se. Könnyen bővíthető.
Viszont egy komplett lekérdezésben így akár lehet 6 JOIN is!

Ez mennyire lenne problémás?
Mi a véleményetek erről a megoldásról? Van más lehetőség is amire nem gondolok?

Előre is köszönök minden tanácsot és tippet!

Üdv!
‹ MS SQL trn MySQL-be [MySQL] Oldalletöltések és csoportosítás ›
 ■
1

azonos tartalom típusok

Pepita · 2015. Ápr. 2. (Cs), 19.32
A megoldás aránylag egyszerű.
Azonos tartalom típusok egy tábla.
Ha a kategória és alkategória azonos információt hordoz, akkor ez egy tábla, csak egy szülő id mező is kell.
Tulajdonság az elemtől külön, elem id, név, érték.
Így egy elemnek bármennyi akármilyen tulajdonság lehet.

Azt hiszem 3 táblába be is fért. :)

Ha mutatsz jelenlegi adatbázis tervet, könnyebb segíteni.

Nem keret rendszer függő, ez szimpla adatbázis tervezés.


Szerk. A csoport ki maradt, de annak szerepe nem is tiszta nekem a leírás alapján.
4

Bocs ha nem volt teljesen

iddqd · 2015. Ápr. 3. (P), 13.33
Bocs ha nem volt teljesen érthető. A környezetet csak azért írtam, hogy teljes legyen a kép.

A probléma egyrészt az, hogy ez egy meglévő rendszer, csak át kellene alakítanom.
A táblák fel vannak töltve adatokkal, amit szintén át kell vinni valamilyen módon, ha átrendezem a struktúrát.

A jelenlegi helyzet egyszerűsítve:

kliens_adat tábla:
ID | Kategória | Név | stb...
-------------------------------
1 | szállás | Hotel1
2 | szállás | Hotel2
3 | étel_ital | Büfé1
4 | étel_ital | kávézó1


kliens_alkategória tábla:
ID | Alkategória_neve | Kliens_ID
------------------------------------
1 | hotel** | 1
2 | wellness_hotel | 1
3 | hotel*** | 2
4 | wellness_hotel | 2
5 | étterem | 3
6 | kávézó | 4

A konkrét probléma ( többek között.. ), hogy így nem lekérdezhető pl:
a csak 2 csillagos - wellness hotel!

11 különféle kategória van és jelenleg 4 féle, kategória specifikus, alkategória "csoport".
Ezalatt azt értem pl: szállásoknak lehet típusa - hotel**, hotel***, ... és lehet jellege - wellness, golf, akármi. Étteremnek - jellege: kínai, magyar, stb

A legjobb megoldás lehetne, ahogy mondtad, hogy alap közös adatok megmaradnának kliens_data táblában és az egyéni kategória specifikus adatok pedig 1 extra tábla,
vagy esetleg külön alkategória táblák pl szállás_jelleg , szállás_típus stb
Van valami "viszonylag" egyszerű módja, hogy a meglévő adatokat átvigyem az új struktúrába?
5

import script

Pepita · 2015. Ápr. 3. (P), 19.12
Egyszer megírod, egyszer fut, kész az import.
Egyébként így is le lehet kérdezni a ** wellness t.
6

Hogyan kérdezzem le?

iddqd · 2015. Ápr. 4. (Szo), 16.29
WHERE IN ( 'hotel**', 'wellness_hotel' ) vissza adja az összes hotel** és összes wellness -t
7

Kicsit több...

Pepita · 2015. Ápr. 5. (V), 18.09

Select * from kliens
where id in (
Select kliens_id from kategória k1, kategória k2
where k1.név = 'hotel**'
And k2.név = 'wellness'
And k1.kliens_id = k2.kliens_id
)
Nem szép, de szerintem működik. (Nem tesztelt.)
Szóval ezért jobb megfelelő adatbázis szerkezetet használni.
A jelenlegi nem tudja a kategória szülő - gyerek kapcsolatot sem.

Olyat nem érdemes csinálni, hogy egy tartalom típus példányának neve a tábla, és annyi tábla, ahány példány. Azt nem tudod jól kezelni.
2

integer + bitmask

szabo.b.gabor · 2015. Ápr. 2. (Cs), 20.10
hát bevallom nem teljesen értem, de talán mégis (: meg végülis nem is számít.

ha viszonylag fix és véges elemszámról beszélünk, akkor egész érdekes dolgokat lehet kihozni egy integer mezőből

mondjuk azt, hogy négy bájtos egy integer (32bit), neked van 6 alkategóriád, akkor egy kategóriára jut 5 bit, abban el tudsz tárolni 31+1 (ami a nulla) féle értéket.

szemléltessük inkább 4bit-es csoportokkal

0000 0110

ez annyit jelent, hogy az 1-es kategóriában a 6-os alcsoportba tartozik

1001 0000
ez annyit tesz, hogy a 2-es kategóriában 9-es alcsoportba tartozik

de lehet ez összetett is
1100 0101
1-es kategória 5-ös alcsoport, kettes kategória 12-es alcsoport

aztán már csak a bitwise operátorokkal kell megbírkózni, de nem vészes az. mysql szinten is van.

érzésre, szerintem elég gyors kellene, hogy legyen, de ha valaki tud az ellenkezőjéről az szóljon.

a kategóriákat meg felépíted php kódban konstansokkal! olyan mint az error_reporting beállítása tkp. majdnem.
3

érdekes

Pepita · 2015. Ápr. 2. (Cs), 20.53
Ez azért eléggé érdekes teória... :)
Nem rossz, de gondolom a kategóriáknak neve, leírása is van + nem tudni a mélységet.
Ezeket a szöveges adatokat szintén érdemes db- ben tárolni. Innen nézve már meg is van az új tábla -> felesleges a bit mask.
Az adatbázis tervezés egyik legnagyobb sarokpontja a "mi való ide, mi kell külön táblába".