ugrás a tartalomhoz

Tiltási szabályok tárolása

world-s · 2009. Okt. 13. (K), 10.37
Sziasztok!
A problémám a következő lenne.
Egy szolgáltatáson belül szeretnék tiltási szabályokat tároló táblát létrehozni.
A feladata az lenne, hogy a különböző ügyfelekre különböző ÉS kapcsolatban lévő szabályok alapján különféle korlátozásokat tudjak érvényesíteni.
Pl.:
1. hétfőtől péntekig 18:00-tól 22:30-ig nem léphet be
2. vagy netán különféle időzítéseket tudjak alkalmazni (pl.: hírlevelet kellene küldeni egy ügyfélnek, de a szabály alapján hétvégén 22:00 után nem küldhetek neki, ezért a szabályrendszerek alapján meg kell azt is határozni, hogy mi az a következő időpont amikorra a küldés beidőzíthető.)

Ehhez milyen adatszerkezetet ajánlotok?
Tudni kell, hogy lehetnek eseti (amikor csak egy konkrét naptári időpontra vonatkozik a szabály), és ismétlődő (pl. minden kedden) feltétel is.
Egy ügyfélhez természetesen több szabály is tartozhat, amik ÉS kapcsolatban vannak. Az Adamikok pedig folyamatosan írják ezeket a szabályokat.

Most ilyesmit találtam ki, de
1. nem olyan szépen írja le a szabályokat
2. egyáltalán nem szép benne a keresés, és a megfelelő időpont meghatározása (programból)

User_ID | INT | azonosító
Type | eseti,ismetlodo | a szabály típusa
Day | H,K,SZE,CS,P,SZO,V,H-P,H-V,SZO-V | rendszeresnél melyik napra vonatkozik
Start | 0000-00-00 00:00:00 | kezdő időpont
End | 0000-00-00 00:00:00 | záró időpont

Start és End esetén ha ismétlődőről van szó, akkor nincs jelentősége a dátum résznek csak az idő számít, így oda 0000-00-00-t tervezek. Ez az ami pl. nem valami szép.
Keresni, és meghatározni a megfelelő időpontot pedig recursive módszerrel lehet csak szerintem.
Meg kell nézni hogy adott időpont jó -e. Ha nem, akkor megnézni, hogy melyik szabály miatt nem jó, majd meghatározni, hogy az adott szabálynak mi a vége, és az így kapott új időponttal újra végig kell nézni az összes szabályt, mert lehet azzal egy másik szabály ütközik.

Sőt elméletileg az adminok készíthetnek véletlen olyan szabályrendszert is ami alapján nem lesz megfelelő időpont.
Ezt is valahogy figyelnem kellene, hogy ne legyen végtelen ciklus.

Segítségeteket előre is köszönöm.
B.Zoli
 
1

Ja a kérdés: Van ettől jobb,

world-s · 2009. Okt. 13. (K), 10.40
Ja a kérdés:
Van ettől jobb, szebb és ráadásul hatékonyabb módszer?
Üdv:
Zoli
2

???

world-s · 2009. Nov. 3. (K), 17.35
Senkinek nincs jobb ötlete?
Szerintem pedig ilyen feladatokkal nap mint nap biztosan találkoznunk kell.

Ha bárkinek bár mi ötlete azt nagyon megköszönöm.

Zoli
3

hm

gphilip · 2009. Nov. 3. (K), 19.42
hát figyi, szerintem nem Írtad le elég konkrétan, hogy mit kell tudnia a szoftverednek.

Az alapján, amit leÍrtál, én ezt csinálnám:

User_ID | INT | azonosító

Days | H,K,SZE,CS,P,SZO,V | SET tÍpusú mező pl MySQL-ben, ahol egyszerre több lehetőség is kijelölhető (igy pl ha Szo-V-t üt be az admin, akkor te "Szo,V"-t tárolsz.) Tulajdonképpen egy bitmap,jól kereshető.

Start | 0000-00-00 00:00:00 | kezdő időpont, ha ismétlődik a dolog, akkor a dátum határozza meg az ismétlődés kezdetét. Ha nem ismétlődik, akkor tulajdonképpen "egyszer ismélődik", tehát a start és end dátumok max egy hetet fednek le. Ha végtelenszer ismétlődik, akkor az end lehet a datetime mező maximális értéke vagy ilyesmi. gy könnyen tudod szűrni az aktÍv szabályokat...

End | 0000-00-00 00:00:00 | záró időpont, ld start
4

.

world-s · 2009. Nov. 5. (Cs), 14.02
Igazából te is hasonló struktúrát írtál le mint én, csak a napokat jelzed máshogy hogy jobban kereshető legye.

Az én esetemben (de lehet több variáció is) a program lényege, hogy az egyes felhasználókat különböző szabályok alapján időről időre aktív státuszra teszi az alapján, hogy az elmúlt időszakban miket csinált. Az aktív státusz esetén tudnak belépni az ügyfelek.
Ilyen lehet pl. egy net korlátozás, stb.
Ez a szabályszerűség megvan írva, ezzel nincs is gond.
A következő aktív státuszra állítás mindig akkor tárolódik az ügyfelekhez amikor kijelentkeznek.
Ugye a helyzet pikantériája hogy az adminok tudnak külön szabályokat írni az ügyfelekre.
Tehát ha azt írják, hogy valaki 22-07-ig (éjszaka) nem léphet be újra, akkor hiába számolja a gép alap esetben, hogy az következő aktív időpont éjfélkor lenne, akkor a szabályok alapján nem éjfélt hanem reggel 7 órát kell bejegyezni.
Minden ügyfélhez több szabály társítható ÉS kapcsolattal, de annyi korlátozással, hogy ezek mind csak tiltások lehetnek.

A te táblád alapján könnyebb a keresés talán (le fogom próbálni), de a másik, hogy csak recurcive tudom így is meghatározni a következő jó időpontot?
Tehát megnézem alap esetben mi lenne a következő aktív időpont, majd megnézem, hogy ütközik -e valamelyik szabállyal. Ha igen, akkor a szabály végét jelölöm meg aktív időpontnak, és újra elvégzem az új időponttal is az ellenőrzést. És ezt addig csinálom, amíg nem találok egy jó időpontot.
A kérdés persze az, hogy ha csak így lehet, akkor hány ciklust érdemes engedni, hogy nehogy végtelen ciklusba érjek?
Ha van más módszer, akkor mi az?
Illetve amikor írják a szabályokat, akkor hogy lehet előre megjósolni azt, hogy a beírt szabályok teljesen megakadályozzák az újraaktiválást. Ezt jó lenne jelezni az adminoknak, hogy változtasson valamin, mert amit beírt az a többivel együtt már túl szigorú.
Zoli
5

események

winston · 2009. Nov. 5. (Cs), 15.28
Csak átfutottam a thread-et, ez alapján reagálok. Tehát ha jól látom a problémát... Mi van, ha nem időintervallumokat írsz le, hanem (akár feltételekhez kötött) eseményeket. Pl.: (IF nap IN (h, k, sze, cs...) ÉS idő = 17) >> (tedd a felhasználót "passzív" státuszba). Erre akár egy queue-t is csinálhatsz, amibe adott időnként egy cron beleteszi az elvégzendő feladatokat, egy másik cron pedig feldolgozza. Véges számú felhasználóig, mivel itt nem beszélünk túl nagy részfeladatokról, ez elég gyorsan használható, így nem lesznek késések. Nyilván az ellentétes eseményt is fel kell venni, és azt is le lehet írni, hogy melyik felhasználók, vagy milyen tulajdonságúak változzanak. Ez persze inkább kódban, mint sql-ben megadható dolog, bár biztos lehet rá valamilyen sql-es tárolást találni. Ha ragaszkodsz az sql-hez... akkor szerintem inkább engedélyezőlistát csinálj, ne tiltót, akár úgy is, h felveszed soronként (userenként, vagy usercsoportonként), hogy hétfő 10-17: engedélyezve. Kicsit könnyebben kezelhetőnek tűnik, illetve biztonságosabb.
6

Válasz

world-s · 2009. Nov. 5. (Cs), 22.13
Érdekes a te ötleted is.

Igazából ha jól értem akkor te státuszváltási időpontokat tárolnád. Sajnos az adminok ilyen szinten nem tudnák kezelni, mert ők csak ilyet tudnak meghatározni:
H-P:22-06-ig nem léphet be
ÉS
CS: 20-21-ig nem léphet be
És most P-en egész nap nem léphet be.

Ebből kellene akkor ha jól értem ilyet készítenie az adminoknak:
H:22 ->tiltás
K:06 ->Engedélyezés
K:22 ->tiltás
SZE:06 ->engedélyezés
SZE:22 ->tiltás
CS:06 ->Engedélyezés
CS:20 ->tiltás
CS:21 ->engedélyezés
CS:22 ->tiltás
P:06 ->engedélyezés (ez egyik nap kimarad)
P:22 ->tiltás (ez egyik nap kimarad)
SZO:06 ->engedélyezés
H: 06 ->engedélyezés


Mivel a belépésen kívül más feladatok is vannak kötve a felhasználókhoz (csak lényegtelennek gondoltam ezzel esetleg elterelni a figyelmet), illetve mivel nagy mennyiségű felhasználóról van szó, ezért történik kilépéskor az új aktiválási és egyéb idők meghatározva (értesítések, időzítések, stb.). Eleve elég összetett számítással történnek meg az idők kiszámítása (4 táblából), ezért sem tartottuk annak idején életszerűnek, hogy több sok milliós táblát állandóan pásztázzunk azért, hogy időnkét 1-2 rekordot frissítsünk.
Ráadásul a nagy rendszer már meg van írva, így ehhez kell már igazodnunk.

Most jelenleg csak az alap szabályrendszer alapján teszi le a felhasználókhoz az adott időpontokat. Ez az alapállapot. Alap esetben egy nyitott rendszer.
Ez kell kiegészíteni a fent leírt dologgal, hogy ha szükséges az adminok tudjanak moderálni (pl. éjszaka valaki ne férhessen hozzá a rendszerhez, ne kapjon SMS értesítőt, ha az alap szabály szerint mondjuk hajnali 3-kor kellene kapnia, stb.). Ráadásul elég ha az adminokat a tiltásokkal terheljük. Amik persze lehetnek esetiek és ismétlődők is.

A te esetedben ugye pl. belépéskor azt figyelnéd - ha csak ezt a funkciót figyeljük - hogy aktív -e az adott státusz vagy nem.
Mi hasonlót csinálunk, csak a lerakott idővel. Ha kisebb az idő, akkor beléphet, ha kisebb az idő, akkor lerakódik a kért értesítés egy táblába, stb.

Zoli
7

csoportok

winston · 2009. Nov. 6. (P), 10.49
ha felhasználói csoportokat képezel, akiket együtt kezelhetsz (pl. a tipikus "tanárok", "diákok" csoport), ezeket akár részcsoportokra osztod, és több szinten kezeled, illetve ha jogcsoportokat is csinálsz (pl. azt az n szabályt, hogy h-k-sz-cs-p 22-6-ig beléphet, arra csinálsz egy gyűjteményt, és azt adod át). Szépen el lehet ezeket a működéseket fedni, én most nem felületi, hanem logikai szempontból néztem. Persze ez nem szent grál :)
Azt, hogy az engedélyezőjogokat kezelném inkább, azért mondtam, mert ha bármi elcsúszik, vagy ha valamire nem gondolunk, szerencsésebb, ha a tiltás az alap, hogy nehogy valaki valamiért véletlen hozzáférjen olyan dologhoz, amihez neki nem kéne joga lennie.

vv.