Adatbázis alapú, elágazásokkal teli feltételek alapján egyedi műveletek - szerkeszthetően

Sziasztok!

Ti hogy oldanátok meg azt, ha adatbázisban tárolt szabályok, feltételek alapján kell különböző műveleteket végrehajtani?
Van erre valami példa engine, működő megoldás?

Példa feladatok, amiket meg kellene oldani, hogy később webes felületről szerkeszthető legyen minden része: a számok, a szavak, az és/vagy, zárójelek, elágazások, bár az utóbbit meg lehet oldani több új szabállyal:

x,y,v,z = normál input mezők
a,b,c,d,e,f = adatbázisban tárolt, szabály mezők

Ha igaz: (x > a) és (y = HAMIS) és ( (v = b) vagy (z < c) ) akkor pelda_fugveny(x,y) indítás.
Ha x dátum régebbi, mint 1 nap de nem régebbi mint 1 év, térjen vissza a értékkel.
Ha x dátum régebbi, mint 1 év, térjen vissza b értékkel és hívja meg a pelda2_fugvenyt(x).

Tehát lennének fix értékek, amiket webes felületről lehetne módosítani.
De meg kellene oldani, hogy módosítható legyen az összes példa bármire.

Az lenne a cél, hogy programozás nélkül lehessen módosítani a folyamatokat.
Tudom, ez nagy árral, lassulással, stb jár, de ezt akarom megoldani.

Gondolom nem én vagyok sem az első, sem az utolsó, aki ilyet szeretne PHP-ban... ;-)

Köszönöm előre is a véleményeket.

Hozzászólások

Az adatbazisban tarolt szabalyok mennyire szabadok? Van valami ami fix?

Egyebkent tarolhatsz php kodot adatbazisban es ha eleg orult/bator vagy hasznalahtsz hozza eval()-t.

kivancsi lennek, mi a valos felhasznalasa a programodnak

Ahogy atolvastam az eredeti kerdesed rajottem, hogy kicsit hasonlo dologba en is beleutkoztem.
Az en peldam a kovetkezo. Adott x adatbazis tabla es egysegsurau juzernek kell tetszoleges sql lekerdezest tudni generalni, ugy hogy szegenyeknek foggalmuk sincs table join-rol, termeszetesen kell egy query builder is amiben gui-alapon tudjak a szabalyokat megadni. Ezeket a lekerdezeseket el kell mentenem, hogy kesobb ha esetleg frissul az adat a tablakban akkor ujra le tudjak futtatni, esetleg a szabalyokon tudjanak modositani.

Az en peldam nem futtat fuggvenyeket, csak sql lekerdezeseket, ha az en peldam kicsit is hasonlo, vagy erdekel hogy csinaltam szolj.

Az ilyesmivel alapvetoen az a problema, hogy csak nagyon korlatozott szamu rekordra mukodik ertelmesen. Egyebkent ezekre keress ra: Lua, Quercus, DQL.

--
Pásztor János
Üzemeltető Macik

Ha a PHP a biztos pont, akkor én felvennék egy másik biztos pontot is: a kiértékelést nem bíznám a PHP-ra, hanem pl. (elsőnek ez jut az eszembe) a bemenetekből a bc szintaxisának megfelelő kódot generálnék, és annak a kimenetét jeleníteném meg - URL-kódolva. Magyarul: a frontendtől eltávolítanám a számítást, amennyire lehet.

Konkrétan (mondom, első agyroham) a bc shell toolra gondoltam.
Pusztán azért, mert abban már ott van az egész parser/solver.

Ami persze az evalban is ott van, de arra azt írtad, hogy nem szeretnéd. Nem tudom, annak milyen alternatívája létezik php-ban, de ha tényleg jól van védve a rosszhiszemű ill. gondatlan bemenetektől, nekem nincs szavam semmi ellen.

Csak egy elsőperces így-csinálnám volt, amit írtam, az eval kiszorításának szem előtt tartásával.

Te akarod használni, vagy más?

:)

Van egy félbehagyott hasonló project-em, ott az eval()-t és alapvetően az egész kérdést úgy oldottam meg, hogy a folyamatoknak a szerkesztés után php fájl volt a "kimenete", és azokat futtattam. Megjegyzem erősen meggondolandó így is, mivel csak egy ötletelés része volt, nem foglalkoztam a biztonsági kérdéssel, de itt az elkerülhetetlen, ha komolyan akarod futtatni tovább a project-et.

Van publikus része a project-nek, amiben használni akarod?

"De meg kellene oldani, hogy módosítható legyen az összes példa bármire."
"Az lenne a cél, hogy programozás nélkül lehessen módosítani a folyamatokat."

Szerintem nem gondoltad ezt teljesen végig.
Tipizálnod kéne a szabályokat - új típus bevitele programozói feladat lenne, de a meglévő típusokat tetszőleges adattal programozás nélkül tudnák használni.

Helló Zoli!

"Tipizálnod kéne a szabályokat - új típus bevitele programozói feladat lenne, de a meglévő típusokat tetszőleges adattal programozás nélkül tudnák használni."

Erre felé haladok én is, mint jelenleg egyetlen működőképes megoldás, PHP alapon. Persze biztos van, amire még nem gondoltam.

Tehát definiálom:

- funkciókat, paraméterezhetően, vagy épp minden kombináció 1-1 külön funkció
- a rendelkezésre álló konstansokat, adatbázis táblákat, mezőket, lekérdezéseket
- ezeket lehet kombinálni és szabályokat rakni rá, a megfelelő sorrendben lefuttatni.

Így értetted?

Sakk-matt,
KaTT :)

Viszonylag egyszerűen megoldható: írnod kell egy interpretált programozási nyelvet :)

Annó Java-ban elkövettem egyet (azóta is én vagyok a világ legjobb ExpressionScript programozója :P ), gyakorlatilag egy túlnövesztett kompozit minta volt: két alap interfész (Function és CompositeFunction), és egy raklap osztály (Literal, Add, Or, Xor, ilyenek, viszonylag hamar Turing-teljes lehetsz; ha jól rémlik annó odáig elmentem vele, hogy lehetett jdbc-n adatbázist csesztetni belőle jdbc_connect és hasonló függvényekkel). Gyorsnak nem volt gyors (nem sokat mértem, de a nagyságrendet érzékelteti: csináltam hozzá egy grafikont ugyanazt az algoritmust C-ben/Java-ban/PHP-ben és még egy-két nyelven megvalósítva - hogy látható legyen mellette a C/Java, logaritmus skálát kellett használnom :).

Ha ezek megvannak, akkor tudsz belőlük szépen építeni egy objektumgráfot (akár kattingatós felületen, akár egy parserrel programkódból). Ha pedig megvan a gráfod, akkor azt futtathatod, vagy - annó nekem pont erre kellett - kényelmesen kevés szabállyal utána tudsz belőle kódot (különösen gyengén típusos nyelvekre, nekem SQL kellett) generálni [ügyelve persze a szemantikára].

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A szakdolgozatomhoz csináltam - egy olyan rendszer, amiben XML-ben definiáltál egy egyed-tulajdonság-reláció modellt, és az alapján futás közben legyártotta neked a sémát és egy adott egy grafikus felületet egyszerű CRUD cuccokra és lekérdezésekre. Két dologhoz kellett a saját nyelv (és az átírhatóság képessége): a modellben meg tudj adni szabályokat (pl.: egy irányítószám típus értékeire legyen igaz, hogy mindig 1000 <= érték <= 9999, egy összetett típus mezőire tudj feltételt adni etc.), amiket még Java-ban alkalmazásszinten betartasson [ill. ha jól emlékszem, amit át lehetett írni, arra csinált CHECK megkötést], és amikor a grafikus felületen összekattintgat egy user egy szabályrendszert egy lekérdezéshez, akkor az annak megfelelő objektumgráfot előállítsa, aztán átírja SQL-re. (sajnos túlvállaltam magam, és szvsz. elég szörnyű lett a megvalósítás)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

+1. Soha többet nem írok saját parsert, mert az önhajtépés miatt masszív kopaszodás kezdetét jelenti... sajnos az elején még úgy gondoltam, hogy jó feature, hogy a parser-be dinamikusan lehet dobálni nyelvi elemeket ("úgyis SQL-be fogod átírni és nem kell változó támogatás? szedd ki a változók kezeléséért felelős objektumot a felelősségi láncból :) van egy dinamikus adatmodelled és szeretnél egy `foo.bar(obj)` operátort, ami a foo típusú objektum bar tulajdonságát adja vissza? adj hozzá egy új objektumot a feldolgozó lánchoz"), utána már maradt az :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Az ilyen kifejezések kiértékelésére vannak a rule engine-ek. Pl. Javaban a drools(http://www.drools.org/). Ezek környékén érdemes utánanézned, annak amit szeretnél.