ugrás a tartalomhoz

Változó mennyiségű és típusú adatok (oszlopok?!)

Pepita · 2012. Május. 20. (V), 01.24
Sziasztok!
Előre is bocs a címért és ha nehezen érthetően fogalmazok, a gond az, hogy én sem értem...

A mese:
Adott egy aránylag kicsi, nonprofit honlap (tervben), ahol meg kéne valósítani egyfajta rendezvényszervezést jelentkezéssel. Azazhogy nem egyfajta, hanem akárhányfajta, és minden programnál gyakorlatilag egyedi a jelentkezéshez szükséges adatok mennyisége is és típusa is. A programot aki szervezi, az ír (wysiwyg) egy programkiírást, ezzel nincs semmi gond, ez egy tartalomtípus. A baj az, hogy előre nem behatárolható, hogy milyen adatok kellenek a jelentkezéshez. (A felhasználókezelés itt nem lényeges, fórum, stb. miatt megoldott.)

Vázlatosan a szempontok (ha sikerül):
- A jelentkezési űrlapra ki tudja hány db input, textarea, stb. kell.
- Ezek mindegyikéhez gyakorlatilag egyedi label kell.
- A jelentkezések eredményét nem csak HTML táblába, hanem letölthető pl. XML fájlba (->Excel) is ki kell írni (ezt meg tudom oldani). Ezzel még utómunkáznak, tehát nem lehet benne "összetett adat" (ilyesmire gondolok: 123,456,789 egy varchar mezőben).
- A programok kiírója ("honlapgazda") gyakorlatilag semmilyen HTML tudással nem rendelkezik.
- A programok közt még olyan különbség is előfordulhat, hogy egy jelentkező nem egy ember, hanem egy család, gyerekek számával, életkorral, stb.
- Hab a tortán: olyan is van, hogy aki (Jelentkező) az űrlapot kitölti, nem vesz részt a programon, hanem pl. a kisfiát íratta fel egy kirándulásra...
- Az egész történetnek egyszerűnek kell lennie a regelt Júzer és az üzemeltető számára is, "az sem ártana", ha aránylag kevés munkával meg tudnám oldani (=minimális táblaszám és kód).
- Nem cél, hogy "hű-de-webalkalmazás" legyen, már most szinte biztos, hogy jóval kevesebb pénz lesz rá, mint amennyibe reálisan kerülne. De én akkor is jó megoldást szeretnék.

Eredeti elképzelésem[1]: elsőre azt mondtam, a programok egy tábla, jelentkezések a másik. Össze kell szedni az összes olyan adatot, ami bármilyen jelentkezéshez kellhet (+1 tarcsi, meg egy id), ennyi oszlop megy a jelentkezések táblába. A program egyes példányaival tároljuk a required mezőket is (x db boolean). Na, ez azért nem jó, mert úgy tűnik, hogy nem lehet előre definiálni minden adatot.

Elképzelés[2]: legyen kiindulásként mondjuk 20 db sorszámozott adat. A program kiírásakor Üzemeltető sorban megadja a label feliratokat, amelyiknek nincs, az nem lesz a jelentkezős űrlapon. Ennek több hátránya van: nem tudom az adat típusát (...int, varchar, ...text, timestamp); sokat kell Üzemeltetőnek gépelni; nem tudok egyszerű megoldást arra, hogy az adott adathoz illeszkedő HTML beviteli elemet adjak az űrlapra.

Kérek mindenkit, akinek van valami ötlete, ossza meg velem! Lehet csak egy pici szikra hibádzik, de nem gyün...

Mégegyszer bocs ennyi rizsáért, de ez már eléggé idegesít. (Azért sincs kódmelléklet, mert még csak tervben van. Illetve lenne...)

Üdv. Pepita
 
1

NoSQL

Hidvégi Gábor · 2012. Május. 20. (V), 06.45
3

MySql

Pepita · 2012. Május. 20. (V), 10.05
Hasznos cikk, köszönöm!
Azonban nekem MySql megoldásra van szükségem, a szerveren valószínűleg nincs más - és ezen kívül én is csak a BDE-t ismerem.
9

Key-value?

janoszen · 2012. Júl. 6. (P), 08.12
Az nem jo, hogy kulcs-ertek parban tarolod az adatokat?
12

Lehet

Pepita · 2012. Júl. 7. (Szo), 03.28
Lehet, hogy jó lenne, köszi, de ez a projekt már befulladt.
A pp-féle szerializált tárolás nekem tetszett. Egy-egy programra úgy 50 jelentkező szokott lenni (legyen max. 500), ennyinél még nem túl lassú egy programexport XML-be vagy CSV-be (lokális továbbfeldolgozáshoz).
Külön problémám volt (lett volna), hogy az adatellenőrzéseket hogy oldjam meg. Végül én arra tendáltam, hogy lesz 20-50 db előregyártott űrlapmező (táblában v. fájlban), mindegyikhez lekódolva az ellenőrzés, a program adminisztrátora meg kipipálgatja, hogy melyek kellenek az ő programjához. Ezt mondjuk elég nehéz könnyen továbbfejleszthetőre csinálni, de ez nem is volt szempont (állítólag 10 éve u.olyan jellegű programok).
Csak aztán ezt sem sikerült letárgyalni, de asszem ezt már leírtam itt valahol.
2

Kész megoldást használjatok.

pp · 2012. Május. 20. (V), 07.08
Kész megoldást használjatok.

Van számos kész megoldás a problémára, amit használni lehet erre. Én biztos nem állnék neki nulláról összerakni. A legegyszerűbb talán a Google megoldásának integrálása. Ha külső adattárolás zavar akkor meg valamilyen CMS/kérdőív generáló lenne szerintem az üdvözítő. Én erre a feladatra a Drupal + Webform kombót használnám. Egész jó a felhasználói felülete.

Ha magad szeretnéd, akkor viszont semmi esetre se javasolnám, hogy egy tábla fix mezőszámot használj. Én a következő felépítést javasolnám:

Kérdőívek tábla:
================
azonosító: egyedi azonosító (pl. MySQL autoincrement)
felépítés: text - benne serializálva a beállításokat tartalmazó tömb.

Válaszok/jelentkezések tábla:
===============
Kérdőív azonosító: külső kulcs a kérdőívek táblára
Válasz/jelentkezés: text - a választ tartalmazó tömb serializálva.

A nulláról fejlesztés nem lesz olcsó (már ha a munkaidőd költségét nem nullával számolod), rengeteg korláttal fog rendelkezni, a felhasználói interfésze borzalmas lesz és hozzád láncolja a nonprofit szervezetet. Ez utóbbi célt kivéve csak akkor tartom értelmesnek saját megoldásba vágni, ha a tanulás a célod. Ez utóbbit viszont mondd el a megrendelődnek is, hogy tudja miért készülsz el olyan lassan a megfogalmazott igényekkel.

pp
4

Nem CMS

Pepita · 2012. Május. 20. (V), 11.02
Ha CMS lenne, Drupal lenne, de nem akarok CMS-t, sok okból, nem részletezem. De köszönöm a Webform modul linket, eddig is sokat tanultam a Drupal megoldásaiból!

A Google-féle dolog tetszetős, de nem a honlapon/tárhelyen van. (Mégis elképzelhető, hogy ez lesz a vége, köszi!)

Maradt a harmadik lehetőség. Pont ettől "féltem", hogy saját serializálót kell írjak (oda-vissza). Ezt hívtam "összetett adat"-nak. Viszont így maradhat két táblában, az adatszerkezet legalább egyszerű.
A nulláról fejlesztés nem lesz olcsó ...

- Valóban. De mennyibe kerülne pl. Drupal-lal, egyedi sminkkel?
- Ha CMS-t használnék, akkor is legalább rövidtávon "hozzámláncolnám" őket.
- Nem tanulás a fő cél (bár szeretek tanulni), de semmiképp sem akarom egy mások által fejlesztett, általános célokra való rendszer korlátait felvállal(tat)ni. Nagyon jó a Drupal, de nagy is, bonyolult is - és szerverigényesebb is, mint egy "ici-pici" célszoftver. (Idő: ez inkább csak nekem szempont, de mire a Drupalba eléggé mélyen beletanulnék, addigra le is programozom bőven - remélem.)

Nagyon köszönöm a véleményed/ötleted, ez a szikra hiányzott: serialize. Esetleg - ha megtalálom - felhasználom a webform adatexportját is, kíváncsi vagyok, hogy csinálja (főleg Excelbe, ha nem CSV-vel).
5

Idő nyerése kizárt a saját megoldásnál.

pp · 2012. Május. 20. (V), 11.27
„Idő: ez inkább csak nekem szempont, de mire a Drupalba eléggé mélyen beletanulnék, addigra le is programozom bőven - remélem.”

Kizárt, legalább próbáld ki, szánj rá fél-egy órácskát.

„- Valóban. De mennyibe kerülne pl. Drupal-lal, egyedi sminkkel?”

??? az egyedi sminket akkor is el kell készítened, ha nem Drupal (vagy bármi más), azt a több száz embernapot viszont meg tudod spórolni ami a választott rendszerbe már beleraktak. (bármit választhatsz, én azért javaslom a Drupalt mert igazából azt ismerem)

pp
6

Nemigazán időnyerés

Pepita · 2012. Május. 21. (H), 12.19
Ha hosszútávon nézem, akkor nem időnyerés, mert x honlap után már biztos, hogy gyorsabb "gyári" CMS-el. (Én azért a Drupalt választanám, mert alapjaival már úgy-ahogy ismerkedtem, és ezt a CMS-t tartom a legjobbnak.)

Azonban nem fél-egyóra kipróbálnom a Drupal-t, pláne nem a sminkelést. Saját backend frontend-fejlesztésekor a saját változóimmal, hátteremmel kell tisztában legyek, nem a többezer ember által fejlesztettel.

Eddig a Drupallal komoly telepítési gondjaim is voltak, és nagyon-nagyon nem szeretem, ha nem értem egy szoftver "legbelső lelkivilágát", ha én (is) fejlesztem azt. Ehhez pedig jóval több kell, mint 1-2 óra.

A tárhelyről még nincs konkrét infóm, de kb. olyan (vagy gyengébb) lesz, mint egy ingyenes. Ha esetleg nincs cron, a frissítéssel már meg is vagyunk lőve.

De azért köszönöm neked a "Drupal felé lökdösést", idővel lehet, hogy odajutok! (Akkor viszont könnyen lehet, hogy Drupalfüggővé is válok.)
7

én is így voltam

EL Tebe · 2012. Júl. 5. (Cs), 18.05
ez már csak akkor lenne még szebb feladat (és lehet hogy ez idővel megfogalmazódik a megrendelőben), ha mindezt többnyelvűvé kell tenned. ;)

Tapasztalatból mondom: ugyanez volt a felfogásom korábban és úgy gondoltam hogy ebből nagyon sokat is tanulhatok. Ez részben igaz, és jó ha az ember "belát a motorháztető alá" is, de ha határidők és pénzről van szó, akkor ez nem feltétlen a helyes út.
Tanulás szemontból tényleg nem rossz, viszont ha tényleg pénzt akarsz csinálni ebből, akkor javaslom a "futószalag-elv"-et:

építkezz abból ami van és amit már "feltaláltak" és minél gyorsabban add át. (most itt nem a végeredmény összelapátolására gondolok, csak érzékeltetni szeretném, hogy 0-ról megírni valamit más, mint egy közösség által több szempontból megcsócsált sokszorosan (0-ról) átírt eszközt működésre bírni). Első körben problémát fog okozni az "átállás", mert nem olyan formátumban vannak a dolgok, ahogy te szoktad, nem olyan könyvtárszerkezetben vannak, ahogy te szoktad ésatöbbi. De az első 1-2 ilyen "megerőszakolom magam" jellegű kör után, megvillannak ezeknek az előnyei, és hogy "jé, erre én nem is gondoltam (volna)".

A jQuery-vel való találkozásomnál voltam így: a javascripttől már a hideg rázott és lám, találtam valamit, ami megkönnyíti az életem - holott eleinte bonyolításnak gondoltam.

Viszont ha azt vesszük, a Drupal előtt is volt élet és a Drupal-t is emberek fejlesztik. De itt megintcsak érdemes visszakanyarodni a konkrét feladathoz és a konkrét célhoz.

Amúgy ha üzletileg nézzük, akkor gondolkodj üzletemberként: tehát ha eladásra szánsz ilyen - bonyolultabb - megoldást, akkor még a legelején érdemes megfontolni: érdemes-e egyáltalán foglalkozni a feladattal, ha például ugyanannyi idő alatt 10x annyi statikus html oldalt raksz össze (profibban) és 10x annyi további üzleti kapcsolatra teszel szert.

Az új kihívások és feladatok amik nem hagynak nyugodni és tényleg érdekesek/szórakoztatóak a számodra: fektess be: fordíts időt arra napi 1-2 órában (és munkaidőn kívüli tanulmányozással/tanulással), hogy elméleti megoldást találj rá. Aztán ha úgy látod, hogy erre komoly keresleted is lenne, akkor valósítsd is meg, a már összeszedett gondolatok/tervek alapján.

(Többszemélyes workgroup-oknál nyilván máshogy van és jó esetben minden feladatra megvan a külön ember, arra az iménti nem vonatkozik, de egyedül már csak így megy ;) )

Amúgy van egy másik járható út is: a fejlesztés értékét ténylegesen "kiszámlázod". Ha a megrendelőnek ez nem jó, akkor bemutathatsz neki egy "áthidaló" B tervet is, aminek a megvalósítását gyorsabban meg tudod csinálni. Ez persze azért nem az igazi, mert a megrendelő nem azt kapja amit akar, de még mindig jobb, mintha te is buksz rajta x időt (pénzt) és a végeredmény sem lesz tökéletes (tehát az üf sem lesz elégedett).
8

Megszívlelendő

Pepita · 2012. Júl. 6. (P), 01.30
Köszönöm, jól leírtad szinte minden "tipródásomat". Alapból semmi bajom a Drupal-lal, csak az - számomra - egy hosszú folyamat lesz (ha lesz), hogy beletanuljak, pont a "lelkivilága" miatt. Erre van - ha nem is minden nap - az 1-2 óra. De eddig is már sokat tanultam "tőle", egy-egy nagyon jó megoldást.
ez már csak akkor lenne még szebb feladat (és lehet hogy ez idővel megfogalmazódik a megrendelőben), ha mindezt többnyelvűvé kell tenned.
Hát ez a veszély nem fenyegetett - lévén egy szűkebb (kizárólag magyar nyelvű), összetartó közösségről szó. (A kérdéses funkció: saját maguknak szervezett programokra (kirándulás, tábor, stb.) jelentkezés.) A projekt egyébként hello, amikor sokadszorra több, mint egy hétig nem kaptam e-mailre választ, meguntam telefonálgatni. Benne volt egy csomó tervezés már - kuka. :(
10

konf.

EL Tebe · 2012. Júl. 6. (P), 09.12
Úgy tudom, hogy a Drupal-osok tartanak (legalább évente) konferenciát.

Lehet, hogy egy ilyen alkalomra érdemes lenne benézni, hátha az előadásokból - és mindenféle ingyen reklámtárgyak begyűjtéséből :) - jóval több kerekedik ki, mintha leülsz elé és barátkozol a forráskóddal :)
11

Ecccer talán...

Pepita · 2012. Júl. 7. (Szo), 03.06
Nem tudom, a Drupal egy életforma. Sok szabadságot ad, de vesz is el. Pont az nem szimpi nekem a CMS-ekben, hogy "nagyon kész vannak". Persze akkor szabom át, amikor akarom (és tudom), de ott a gát, hogy "az már ott van". Nem olyan nagy gát ez, de még óckodok tőle. Viszont a konf. jó ötlet. Ha egyszer el tudok menni egyre, nagyban befolyásolni fog, hogy hány %-át értem az elhangzottaknak.
13

Egy custom (néha még a

deejayy · 2012. Júl. 9. (H), 15.37
Egy custom (néha még a core-ba is belenyúlkáló) fejlesztésekkel megtoldott drupal verziófrissítése mennyire lehet fájdalmas téma?
14

Verziókövető

Poetro · 2012. Júl. 9. (H), 16.19
Ha megfelelően van verziókövetve, akkor egy merge / pull nem feltétlen lesz fájdalmas.
15

Nekem eddig még nem volt

tgr · 2012. Júl. 9. (H), 17.08
Nekem eddig még nem volt olyan Drupal frissítésem, ahol pár modul ne szűnt volna meg működni, vagy ne romlott volna el az adatbáziséma.
19

Nem volt részlet

Poetro · 2012. Júl. 9. (H), 17.43
Nem volt részltezve, hogy milyen verziófrissítésről van szó, ezért én minor verzióváltásra gondoltam.
21

^ erre gondoltam.

deejayy · 2012. Júl. 17. (K), 09.34
Nekem eddig még nem volt olyan Drupal frissítésem, ahol pár modul ne szűnt volna meg működni, vagy ne romlott volna el az adatbáziséma.


^ erre gondoltam.
16

Drupalnak akkor van értelme,

tgr · 2012. Júl. 9. (H), 17.13
Drupalnak akkor van értelme, ha van ember, aki folyamatosan foglalkozik az adminisztrálásával (és a megrendelő hajlandó fizetni érte), mert a CCK kezeléséhez ugyan nem kell programozói tudás, de ettől még az átlag felhasználó nem fogja tudni megtanulni. (Eseményregisztrációhoz van célszoftver is egyébként, pl. CiviCRM, de azzal is ugyanez a probléma.)

Persze egyáltalán nem biztos, hogy egy nulláról lefejlesztett CCK-szerű interfész tanulhatóbb lesz, ellenben brutál sok munka.
17

Ez az ami minden rendszerről elmondható...

pp · 2012. Júl. 9. (H), 17.22
"Drupalnak akkor van értelme, ha van ember, aki folyamatosan foglalkozik az adminisztrálásával"

Még az egyedi fejlesztésekről is.

pp
18

Általában nem

tgr · 2012. Júl. 9. (H), 17.37
Általában nem (meg általában a Drupalról sem, pl. egy Drupalban összerakott fórum vagy webshop remekül elketyeg, amíg nem akarsz módosítani rajta), de ha mondjuk tartalomtípusokat kell létrehozni menet közben, azt a Drupal nem képes olyan felhasználóbarát módon megoldani, hogy oda lehessen adni a megrendelőnek, hogy innentől csinálja ő. Egyedi fejlesztéssel biztosan meg lehetne oldani, de csak irreálisan sok erőfeszítéssel, valószínűleg sokkal jobban jön ki a megrendelő anyagilag, ha felvesz havi pár órára egy Drupal admint.
20

Új tartalomtípus

Pepita · 2012. Júl. 17. (K), 00.10
Szerintem egyedi fejlesztésnél ezt felhasználóbarátan nem lehet megoldani. Legalábbis nem jobban, mint a Drupal. A gond inkább a megrendelő / üzemeltető hozzá(nem)értéséből fakad, többségük azt sem érti (joggal, mert nem szakmabeli), hogy mi az a tartalomtípus. Innentől elég nehéz (lehetetlen) olyan felületet gyártani, ami szerinte (is) felhasználóbarát.

Egyszer valaki azt mondta nekem, hogy egy mikrofon kéne billentyűzet helyett...
Azt feleltem: nem mikrofon kell, hanem egy jobb képességű titkárnő. :)