Nem (teljesen) összefüggő adatok tárolása (MySQL)

Rendben, köszönöm az ötletébresztést.
Gyorsan átgondolva két dologra jutottam, amit tovább kell gondolnom.
1) Átfogom nézni bővebben az XML előnyeit, hátrányait.
2) nemo1: text típusban biztosan nem fogok tárolni mindent. A táblába minden mező sem hinném, hogy eléggé hatékony. Ezek alapján inkább létrehozok választípusonként pl. 4 táblát (szám,igen/nem,szöveg,memo), és a válaszok id-jét a típussal együtt bejegyzem a válasz mellé.

A linkeket köszi, átfogom futni a forrást, hátha segítenek valamit. Aminek még utána fogok nézni, hogy mennyivel lassabb a fájl I/O a MySQL-nél. A userek száma nem sok, a kérdőívkitöltők viszont annál többen vannak. A végső lekérdezés nem érinti a kérdőívek kitöltőit, így náluk a lekérdezés sebessége nem szempont.

-vision-

Az xml igazából azért jó, mert tudsz mellé xslt -t csinálni, amik templatek Azonkívül tudod egy táblában tárolni, parse-olva vagy anélkül, kihasználhatod az xquery előnyeit, osztán nem reklámozom tovább

Nos erre két megoldást látok (maradván az egy kérdések tábla elvnél)

1. a válasz ntext típusú, így bármit megeszik, és beírásnál/kiolvasásnál úgyis a típus alapján validálsz

2. a válasz táblába minden adattípusból csinálsz egy mezőt, és abba teszel csak adatot, ami a típusnak megfelel.

Esetleg meríthetsz ötletet másoktól:
KLIKK
KLIKK2

Lehet, hogy én vagyok már a lassú ilyenkor, de ez esetben pl. egy szám adatot is szövegmezőben tárolok? Lehet, hogy lesz 5-600 karakteres kifejtős is.
Igen, én is ezért vetettem fel a témát, mert ha az adatbázisban találnék megfelelő helyet erre, akkor kerülném a fájlokat.

Blado: az XML még eszembe sem jutott, mindjárt utána is nézek, alkalmazható lenne-e a problémára. Template-ben nem tudom, megéri e gondolkoznom, mert igen vegyes kérdőívek lehetnek. Pl. januárban egy A szám- B szám-C szöveg-D szám, februárban pedig egy A szám, E szöveg, F igen/nem.

-vision-

Miért nem template-ket használtok? A másik kérdésem, hol fogják tárolni a felhasználók a formokról bekért adatokat? Az XML előnyeit miért nem használjátok ki?

Részemről ellene vagyok a fájlos megoldásnak, sokan esnek abba a hibába, hogy azt gondolják ez egyszerűbb hatékonyabb vagy gyorsabb, nos bizton állíthatom egyik sem igaz.

Az adatbázis mindíg korszerűbb,gyorsabb, biztonságosabb mint a natív IO.

És egy jól megtervezett adatbázisból bármilyen statisztika/összesítés/keresés megvalósítható, és a megvalósításnál az adatbázis "dolgozik".

Nem kell választípusonként külön tábla, csak egy mező, ami jelöli a típust.

pl:
válaszok tábla
- id
- valasz_szoveg
- tipus (vagy újabb táblára kapcsoló, vagy sima ENUM/szöveg)
- statusz
.....

Kapcsolótábla a kérdések/válaszok közt:
- id
- kerdes_id
- valasz_id
- statusz
....

Kérdés felvitel menete:
- kérdés tábla adatainak megadása
- kapcsolótábla kitöltése (a válaszlehetőségek id-jét írod be)

Kérdés megjelenítés:
- kérdés kiírása
- kapcsolótáblán keresztül (JOIN) kiszeded a kérdéshez tartozó válaszlehetőségeket
- a válaszlehetőségeket típustól függően a megfelelő GUI elemmel és ellenőrzéssel megjeleníted
- válasz/válaszok tárolása

Úgy érted, választípusonként egy tábla?
Nem igen lesz kérdés-ismétlődés, nem "neve/címe/kora" típusú kérdőívekről van szó. Különféle adatokra leszünk/lesznek kíváncsiak, de a kérdőívek elképzelhetőek, hogy időről-időre újra felhasználásra kerülnek (változáskövetés).

Visszatérve. Mintegy "ötletébresztőként" vetettem fel a kérdést, átgondoltam már sokszor. Úgy tűnik, a fájlos módszert egyszerűbb lenne kezelni. 4-5-x táblát használni egy kérdőív kedvéért, nem beszélni a lekérdezésről, összesítésről, úgy vélem, nem kifizetődő, sőt.

Köszi a válaszokat! Ha van még ötleted, szivesen várom :)

-vision-

Nos akkor komplikáljuk:

Az egészet szét kell robbantani a legkisebb egységeire, és mindent külön táblába, +egy kapcsolótábla.

A "mindenféle" verzió miatt a válaszlehetőségeket is kénytelen leszel táblába foglalni, a típusával együtt. De ezzel egyuttal nyersz is, mert ezeket bedobhatod közösbe.
Vagyis mikor a júzer megdja a lehetséges válaszokat, kkor ebben tallózhat, és csak akkor kell újat felvinnie, ha nincs még ilyen válasz, és a megjelenítő részt is könyebb megírni, a kérdés típusa a alapján. (combo,radio,check,multi,list...stb)

Esetleg a kérdésekkel is közösködhetsz, mert gondolom nem elképzelhetetlen az ismétlődés (pl.: mia neve, hány éves ... stb.)

3 tábla, és ömlesztve az összes. Megfordult a fejemben, de erősen gondolkozom rajta. Bármilyen kérdés lehet: csak szám, szöveg, eldöntős, igen-nem, ... Jelezhetném a típust egy mezőben, és szövegben várok minden választ, de... és itt a de. Ez nem túl "elegáns" és nem túl optimális.
Az egyik kérdőív lehet, hogy csak 1 mezős, a másik meg 20.

-vision-

Sztem lenne 3 táblád:

1. kérdőívek:
-id
-nev
-user_id
-datum
-statusz
...

2. kérdések:
- id
- kerdoiv_id
- kerdes_szoveg
na itt jön az érdekesség, mert nemtudom milyen kérdésekere számítasz (eldöntendő, kiválasztós, kifejtős...stb)
- statusz
....

3. válaszok
- id
- kerdes_id
na itt megint a fenti kérdés
- user_id
- statusz
....

Szterm ennyi...

Üdv!

Szeretnék egy-két tanácsot, ötletet, véleményt kérni az alábbiakhoz.
Adott egy jelenleg még tervezés alatt álló információs rendszer. A rendszer interneten keresztül lesz elérhető (PHP,MySQL), alapvető célja egy adott belső (de nem egy helyen dolgozó) csoport (30-50 fő) mindennapi munkáját támogatni, segíteni (egyszerű dokumentumkezelés, véleményezés, fórum, eseménynaptár, stb).
Mindehhez jönne egy egyedi feature: szükség lenne egy olyan modulra, melynek segítségével bárki létrehozhat egy egyedi kérdőívet. Ezt a kérdőívet adott (korlátozott jogosultságú) személyek tölthetik ki, kérdőívenként max. 1500-2500. Az egyes kérdőívek a rendszeren belül maximum 1 táblához kapcsolódnának, a többihez nem. A kérdőívek funkciója, hogy a rögzítések végén összesítéseket, jelentéseket lehessen készíteni.

Kérdésem, hogy véleményetek szerint nyissak-e minden kérdőívnek egy új táblát (szerk.: táblákat), vagy célszerűbb, ha a felvitt adatokat egy-egy fájlban tárolom? 20-30 kérdőív után úgy vélem, kis zűrzavar lenne az adatbázisban, és mivel a kérdőíves adatok lényegében nem szerves részei a teljes adatbázisnak, nem biztos, hogy ez a legjobb megoldás.
Vélemények?

Köszi!

-vision-