ugrás a tartalomhoz

mysql cellában asszociatív tömb tárolása

ErdosJ · 2007. Nov. 15. (Cs), 19.10
sziasztok
van egy tablam, itt minden egyes sorban egy-egy tobbdimenzios (asszociativ) tombot szeretnek tarolni.
egyelore ket megoldast talaltam:
1) a tomb indexeinek megfelelo nevu oszlopokat letrehozom. ezzel az a bajom, hogy a tombomnek rengeteg indexe lehet, sot, lehetseges, hogy egy sorban ezek kozul nem mindegyiket hasznalom ki.
2) egy nagy cellaban json adatokat tarolok. ez eddig mukodik. szerver oldalon php/perl segitsegevel feldolgozom, minden vilagos.
kerdesem: van mas modszer? mi a leghatekonyabb? mi a leggyorsabb? mit celszeru?
masik kerdesem: az normalis, hogy (jatekrol van szo) egy oldalletoltesnel akar harom, esetleg ot mysql lekerdezest is futtatok? ez hosszu tavon nem zsakutca?
valaszaitokat varom
ErdosJ
‹ TINYINT és társai Legközelebbi érték ›
 ■
1

Második kérdésre

csla · 2007. Nov. 15. (Cs), 19.48
Ha csak pl. a névnapot iratod ki 5 lekérdezésből, akkor nem normális... :)
Önmagában a lekérdezések számából nem lehet megmondani. Egyrészt érdemes időt szánni rá, hogy ha mindenképpen szükséges mindig a lekérdezés, akkor a lehetőség szerint optimalizált legyen a számuk és módjuk, másrészt viszont ha rövid távon (értsd: pl. egy látogatás elejétől a végéig) nem változik az adat, akkor praktikusabb csak az első megjelenítéskor lekérdezni, és cache-elni (akár egy session változóba).
4

Re: Második kérdésre

ErdosJ · 2007. Nov. 16. (P), 15.46
hjaja! nalam a felhasznalo adatain kivul minden adat valtozik.. azt erdemes sessionba elmenteni?
mondjuk, mennyivel lenne megis gyorsabb, ha a lekerdezeseket nem kulon mysql_query fuggvenyekkel hivom meg, hanem egyszerre, pontosvesszovel elvalasztva?
2

Serialization

kicsy · 2007. Nov. 15. (Cs), 21.22
A kettes megoldás irányába érdemes elindulni, de JSON használatánál egyszerűbb a serialize/unserialize kombó bevetése.
5

Re: Serialization

ErdosJ · 2007. Nov. 16. (P), 15.48
koszonom, a linket megnezegettem, es megtalaltam a perles megfelelojet is.
ez miert jobb, mint a json? szebb? (szamomra legalabbis nem atlathatobb..) gyorsabb?
3

Igazából ismerni kellene az adatszerkezetet.

s_volenszki · 2007. Nov. 15. (Cs), 21.34
Szia!

Szerintem jól átgondolva és optimalizálva nem biztos hogy nem lenne elég néhány tábla jó kapcsolatokkal és jó indexekkel! Amíg nem foglalkoztam komolyabban adatbázis tervezéssel és optimalizálással, sokszor én is azt hittem, hogy egy-egy feladat megoldásához világmegváltó attrakciók szükségesek, pedig a megoldás mindig benne volt az aktuális adottságosban (MySQL+php).

Van egy kedvenc könyvem, és egy bekezdés némi választ adhat a feltett kérdéseiddel kapcsolatban:

A mező (cella) fogalma relációs adatbázisban:

A mező az adatbázis legkisebb szerkezete. A mezők tárolják a tényleges adatot... A mezőkben tárolt adatokhoz azután hozzáférhetünk és számtalan módon megjeleníthetjük azokat... Nem szabad alábecsülni a mezők jelentőségét!

Egy jól megtervezett adatbázisban minden mező egy vagy több értéket tartalmaz, és a mező neve a tárolt értékre utal.

Egy rosszul megtervezett adatbázisban három további mezőtípussal találkozunk:

1. A többrészes mező (más néven összetett mező) több, egymástól független értéket tartalmaz.
2. Többértékű mező, több példányban tartalmazza ugyan azt az értéket.
3. A számított mező összefűzött szövegeket vagy matematikai műveletek eredménynét tárolja.

Szerintem ha jól megtervezed, biztos megoldódik ez a többdimenziós tömb tárolás probléma!

s_volenszki

ps.:

A könyv: Adatbázis tervezés
És egy teljesen ingyenes, grafikus adatbázis tervező progi: DBDesigner4
6

Re: reklam

ErdosJ · 2007. Nov. 16. (P), 15.51
koszonom, a dbdesignert mar probaltam (debianomon meg nem sikerult mukodesre birnom), a konyvnek majd utananezek.
egyelore az "SQL Teljesítményfokozás" van meg (konyvtari), bar azt hiszem, hogy elobb jobb lenne az alapokkal reszletesebben megismerkednem.
7

Sajna a DBDesigner...

s_volenszki · 2007. Nov. 16. (P), 16.12
Sajna a designer nekem is csak Kíndózon hajlandó operálni! Bár Ubuntura is felgyilkoltam, ezidáig problémamentesen működik. Mondjuk én csak a táblák és relációk tervezését végzem vele, meg max. sql kimenetet csináltatok (nem csatlakozok db-hez, meg nem importálok modelleket stb...).

s_volenszki
8

Anélkül, hogy ismerném a pontos fealdatot...

vbence · 2007. Nov. 16. (P), 17.29
...én két táblával dolgoznék. Először is biztosan vannak az egyedhez tartozó statikus adatok, amik mindig jelen vannak, ezek maradnának síma mezők. Ehhez jönne hozzá a dinamikus adatokhoz egy másik tábla:
CREATE TABLE `dina` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `hostid` int(11) unsigned NOT NULL DEFAULT '0',
  `name` enum('arany','gyemant','fegyver','akarmi') NOT NULL,
  `value` varchar(64) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `filter1` (`hostid`,`name`)
);
Ez akkor működik, ha előre tudod az összes lehetőséget a kulcsra. Előnye az, hogy nem stringként tárolódik, így gyorsabb/kisebb (a kulcs szintén, bár index esetén a sebességkülönbség kisebb). Ha nem ismert (dinamikusan is generálódhat, vagy fenn akarod tartani a feljelszthetőséget db módosítás nélkül), a "name" lehet string. A hostid az alap táblában található egyedre mutat, akinek a tulajdonságait szeretnénk kikeresni.

Indexként csak egy paraszti ész alapú indexet csináltam, a konkrét alkalmazáson múlik, milyen queryket fogsz futtatni, ehhez kell indexelni.
9

Re: Anélkül...

ErdosJ · 2007. Nov. 16. (P), 17.58
szia
koszonom a valaszodat, de egy dolgot nem ertek:
miert kell/erdemes tobb tablaval dolgozni? az mitol lesz gyorsabb/jobb? minnyire fenyegeti az atlathatosagot?
az a problemam, hogy a kulcsok nevei nincsenek elore meghatarozva, sot, menet kozben valtozhatnak is, igy hordozhatosag teren ez kilove..
viszont ez az enum dolog erdekes, megnezegetem.
10

Pont az 'enum'...

vbence · 2007. Nov. 16. (P), 18.44
ami azt feltételezi, hogy ismered a kulcsokat (mivel felsotoltad vagyis enumeráltad őket). Változó kulcsoknál csak a string játszik.

Ez csak azért két tábla, hogy a statikus adatokat tudd normálisan, mezőkként tárolni, ami sokkal gyorsabb, mintha azokat is ebben a hozzárendelő táblában trlolnánk.

Máshogy közelítve: miért használunk adatbázist, miért nem csak egy lineáris textfájlt? Mert az adatbázisban metaadatokat is tárolunk - információt az adatok struktúrájáról, amiket felhasznál a dbms, például rendez, szűr rájuk. Miért használunk mezőket, miért nem egy text mező van soronként, amibe beleconcatolunk mindent? Mert ez is plusz indormáció a DBMS számára. És így tovább. Az alaphelyzet az, hogy a modellünket minél jobban vetítsük le az adatbázis nyelvére.

Jelen esetben például kikérhetsz egyetlen információt több egyedről (mondjuk mindenkitől az 'arany' mezőt) anélkül, hogy be kellene parzolnod (unszerializálnod) - oké magyarul értelmezned - egy stringet. Vagy szűrhetsz például mindenkire akinek az aranya több mint 5000. Ezt biztosan nem tudod megcsinálni egy szerializált text mezővel.

Persze el lehet térni az ideális adatbázis-szerkezettől, például, ha neked midig minden adat kell (csak egyszerre lehet felhasználni őket). Ilyenkor jobb lesz a szerializált megoldás. (Persze kérdés a tömb visszaértelmezésének ideje).

Szerintem a lényeg: juss el az ideális adatbázis-szerkezetre. És csak ezután kezd el "rontani" az adatbázist.
11

És mondjuk így?

zzrek · 2007. Nov. 16. (P), 21.29
statikus adatok, amelyek biztosan megvannak egységenként:
ID, hp, ac

Egyedi adatok, amelyek vagy vannak, vagy nincsenek egységenként, külön táblában:
ID, tulajdonsagtipus , tulajdonsagertek

...vagyis a 2. táblában annyi sor tartozna az egységhez, ahány plusztulajdonsága van.
12

Re: És mon...

ErdosJ · 2007. Nov. 16. (P), 23.16
de igy a 2. tablaban minden harmadik adat folosleges lenne, nem?
14

nem értem

zzrek · 2007. Nov. 17. (Szo), 10.48
Nem értem mire gondolsz... Miért lenne minden 3. fölösleges? Csak akkor teszel bejegyzést a 2. táblába, ha el kell tárolnod valami pluszadatot az 1. táblában definiált egységhez. A 2. táblában a bejegyzés 3 minimálisan szükséges adatot tartalmaz: az egység azonosítóját, a pluszadat típusát (nevét, tokenét) és a pluszadat értékét.
15

Re: nem...

ErdosJ · 2007. Nov. 17. (Szo), 11.14
arra gondoltam, hogy igy, plusz egy tablaval 3/2 annyi informaciot kell tarolni, mint ha csak egy tablaval dolgoznek. miert egytablas modszernel nem kell az id-t kulon-kulon tarolni, szemben a kettablassal.
mas: valoszinuleg maradok a jsonos megoldasnal, az passzol jobban a projekt felepitesehez.
16

te tudod..

zzrek · 2007. Nov. 17. (Szo), 12.41
Te tudod, hogy melyik a jobb, ez csak egy tipp volt. A jsonos egyébként lehet rosszabb is méret szempontjából, ha a "mezőneveket" megadod vele. Az "én módszerem" akkor jó ha "táblásítani" akarsz és sok olyan tulajdonság van, amelyeket egyes azonosítókhoz csak ritkán akarsz rendelni (nekem úgy tűnt a kérdésfelvetésből, hogy ez okozza a problémát) Sok sikert (ha kész a játék, priviben dobj egy linket, ha publikus és reklámozni akarod, vagy a véleményemre vagy kíváncsi - szívesen megnézem)
17

több szempontból rosszabb

zila · 2007. Nov. 17. (Szo), 12.55
Eltekintve attól, hogy bebetonoz egy merev struktúrát amiben lehetetlen keresni, méretben sokkal rosszabb, hiszen a json-ben ott a sok zárójel és kettőspont, valamint minden érték string tehát a 65535 integer érték 5 byte szemben egy integerrel ami 2, dátum értékek detto. Áttekinthetőség nulla. Ha netán nem csak json-re kéne használni (hanem pl. egy riportban, 3rd party alkalmazással kéne felhasználni a tábla adatait) akkor ez nagyjából nem lesz kivitelezhető.
18

Te: több szempontból...

ErdosJ · 2007. Nov. 17. (Szo), 13.07
ezekben igazad van, es tenyleg elgondolkodtato, amit irsz.
sajna, a merev struktura bebetonozasa miatt nem jo nekem a sokcellas megoldas.

EDIT: baanyeek, tenyleg igazad van, celszerubb lesz atirnom.
23

privi

ErdosJ · 2007. Nov. 17. (Szo), 16.58
hogyan tudok "privit" kuldeni? ett azt irja ki, hogy nem fogadsz emaileket..
24

jé tényleg...

zzrek · 2007. Nov. 17. (Szo), 21.09
Most pipáltam valamit, most már jó?
21

"Fölösleges" adatok

vbence · 2007. Nov. 17. (Szo), 16.08
Ha mondjuk PHP-ben van a kód definiálhatod a mező-azonosítókat konstansban pl:
<?
define("FLD_ARANY", 1);
define("FLD_VARAZSPOR", 2);
define("FLD_AKARMI", 3);
Így nem kell string legyen a mező azonosítója, azaz kevesebb helyet foglal, kisebb az index is.

Más: Nem ismerem a programod felépítését, de egy online játéknál a vincsszter lesz a legolcsóbb hozzávaló. A JSON dekódolásához szükséges processzoridő pénzben sokszorosa annak, amennyibe pár plusz megabájt kerül a vinyón. Arról nem is beszélve, hogy a MYSQL egy optimalizált program a PHP pedig egy szkriptnyelv. Amit lehet tehát célszerű az elsőre bízni, ha egyszer adatkezelésről van szó.
22

Re: "Fölösleges" adatok...

ErdosJ · 2007. Nov. 17. (Szo), 16.18
szia
jo otlet ez a define (bar eddig masra hasznaltam), elegge megkonnyitheti a munkat, meg kiserletezem vele.

(mas: miert van az, hogy mindenki azt gondolja, hogy ha netes jatek, akkor tutti a kozepkorban jatszodik, varazsolunk, es arannyal fizetunk?)
25

konstansok vs asszociatív tömb

gex · 2007. Nov. 17. (Szo), 22.32
volt egy téma itt a fórumon arról, hogy a konstansok használata a gyorsabb vagy egy asszociatív tömbé, de most nem igazán találom (esetleg valaki emlékszik rá?). ott ha jól emlékszem sebesség szempontjából a tömb nyert.
26

az adatbázisban

vbence · 2007. Nov. 18. (V), 11.37
Igazából itt a fő cél az adatbázis optimalizálása volt, teját, hogy varchar helett int lehessen az azonosító, amihez értékeket rendelünk. Persze kérdés, milyen áron kapjuk mindezt. A végeredmény nagyon sok mindenen múlik, ezen a ponton nem lenne sok értelme ezen spekulálni.
13

én így tenném

Táskai Zsolt · 2007. Nov. 17. (Szo), 01.14
igazság szerint nem is tudok jobbat elképzelni, HA tényleg adatbázist akarsz/kell építeni.
19

masik erdes.

ErdosJ · 2007. Nov. 17. (Szo), 14.07
sziasztok
emiatt nem szerettem volna uj temat nyitni, de belebotlottam az alabbi kerdesbe:
van egy tablam (tabla), amely ket (kulcs,ertek) cellat tartalmaz. feltoltve sorokkal..
kiadom a SELECT `ertek` AS `kulcs` FROM `tabla` parancsot, es a sorok egy ('kulcs' nevu) sorba gyulnek.. de miert?
hogyan tudnam elerni, hogy foreach-szeruen irja ki a cellak erteket, tehat kulcs sorba ertek keruljon?
valaszaitokat varom
ErdosJ
20

Egyszer nekem is kellett csinálnom egy játékot...

s_volenszki · 2007. Nov. 17. (Szo), 14.56
Egyszer nekem is kellett csinálnom egy játékot, ami nem egy bonyolult játék, de azt gondoltam, a működéshez adatbázisban le kell tárolnom minden lehetséges variációt, így a játék menete közben nem marad ismeretlen állás (táblajáték). Aztán összeszövetkeztem egy matematikus haverommal, és pikk-pakk kiderült, hogy néhány első fokú(!) egyenlettel és három, állandóan jelen lévő adattal bármikor reprodukálható a következő állás összes lehetősége.

És az adatbázis alapú játékból lett egy 70kB-os js :)

s_volenszki