Adatbázis vagy memória
2010-08-19T17:22:33+02:00
2010-08-22T11:03:58+02:00
2022-07-25T00:27:28+02:00
  • Tudom mit csinál, és azt is hogy hogyan működik. És egyébként úgy 2 éve megy kifogástalanul ott ahol használják, 6 userrel amiből 4 intenzíven pakolja bele az adatokat napi 8 órában.
    Mutasd a teljes hozzászólást!
  • A saját megoldások jók, csak nem szabványosat, csökkentik a hordozhatóságot, ha a logikát egyszer mégis átkell helyezi kliensről szerverre akkor könnyebb.
    Mutasd a teljes hozzászólást!
  • Szeretem, ha egy programozó tudja mit csinál, és hogy működik a rendszer :)
    Mutasd a teljes hozzászólást!
  • Erre találták ki Java-ban a JPA-t, csak a memóriában dolgozok objektumokkal, és a perzisztálást megoldja a keretrendszer, tehát mindig szinkronban lesz, de csak egyszer kell módosítani: nincs felesleges (kód)redundancia.
    Mutasd a teljes hozzászólást!
  • Ugyanaz mint ha sima query lekérés esetén történt volna a dolog. Aki kimaradt majd átjön a következő frissítés után. Illetve van egy olyan üzemmódom is hogy ha a trigger létrehoz egy új sort akkor az SQL szerver visszaüzen a kliensnek hogy frissítsen, ilyenkor az lefrissíti a sorokat és kiértesíti a központi konténerből dolgozó listákat is hogy firssítsék le önmagukat. Ez is működik, csak sok usernél kicsit lassú, ezért defaultból ki van kapcsolva. Ezek amúgy sem túl gyakran változó táblák, és gyakorlatilag 0 az esélye a konkurens módosításnak, de ha megtörténik akkor sincs tragédia.
    Mutasd a teljes hozzászólást!
  • És mi van ha changelog lekérés közben történik változás?
    Mutasd a teljes hozzászólást!
  • Az én rendszeremben két nagyobb tábla van (úgy 20 000 sorosak). Ezeket objektumokat tartalmazó lista konténerbe olvasom be. A fizikai táblákra rá van aggatva egy trigger ami egy changelog táblát tölt. Amikor kíváncsi vagyok az objektum listámra akkor előtte ez alapján szinkronizálom, azaz lekérem a táblából a változásokat és végigvezetem a konténerben lévő objektumokon. Amikor szükségem van rájuk (Pl. egy datagridben) akkor feltöltök egy rendezhető bindinglist konténert az alap konténerben lévő objektumokból a linq segítségével. Kilépés előtt fájlba mentem a konténerek tartalmát, bejelentkezés előtt visszatöltöm azokat.
    Mutasd a teljes hozzászólást!
  • En mostanaban egy ilyennel kiserletezek:

    Datamodulon van egy főobjektum, ez felel meg az adatbazisnak. Abban pedig published fieldként egy rakás listaobjektum, ezek pedig megfeleltethetők az adatbazis tablainak. A listaobjektumok elemei pedig tablasoroknak.
    Ebben a formaban szepen meg lehet tervezni a classokat uml-es vagy akarmilyen atlathato modszerrel. Es a felhasznalasnal sem kell attol tartani, hogy jaj elirtam egy fieldnevet, mert segit az intellisense es tarsai.

    Amit eddig volt:
    A lista tud nezeteket kezelni, (sorbarendezni+szurni), ezeket a nezeteket runtime frissiti. (genericssel egyszeru barmilyen class-ra rahuzni)
    Az egymasra hivatkozo objektumok figyelik egymast, azaz ha valamelyik felszabadul, akkor az jelez az osszes rá hivatkozonak, hogy fel fog szabadulni, igy olyan classpointer nem lehet a rendszerben, ami ma'r felszabadult teruletre mutat.
    Minden objektum ismeri sajat magat (rtti).
    Minden objektumnak van ownerje. Ha a datamodulon levo főobjektum felszabadul, akkor az osszes alobjektumot is felszabaditja.
    Objektumok figyelik a valtozasaikat (property setterekben, plusz create,destroy-nal) es errol az ownerjeiket is ertesitik rekurzivan.

    Innentol az "ezeket az adatokat nyilván könnyebb objektumokba tagoltan kezelni" kriterium mar teljesult. :D

    Ami most egy adatbaziskezelosdi miatt kellett bele:
    Mindharom 'szint' (db,table,row) tudja scriptelni magát (most csak mssql).
    A főobjektum, ami 'TDatabase (sajat, nem a delphis)'-bol lett szarmaztatva, tud kapcsolatot tartani adatbazissal, indulaskor lerantja az osszes tablat (a nagy tablakat eloszuressel, torzsadatot viszont mind), a valtozasfigyeles miatt pedig kuldi az inserteket/updateokat/delete-ket is.

    Ami még lehet pl:
    'ugyviteli lan party' azaz azonnali adatszinkron a kliens UI-k kozott. Ehhez kell egy kis szerver exe, ami beekelodik a kliensek es az sql szerver kozé és broadcastolja a változásokat.

    A fejlesztes pedig ugy indul, hogy csak az osztalyhierarhiara osszpontositva letre kell hozni a classokat. Majd kesobb, ha mar nem sok minden valtozik 1 paranccsal ki lehet scriptelni az egesz adatbazist es lehet atallni mssql-re. Addig viszont lehet kiserletezni is, a tesztadatok addig meg xml szeru formaban (valtozasokra nem erzekenyen) serializalodhatnak.

    Az elv az, hogy minden adat legyen elerheto egy szép osztalyhierarhiabol, es amit ezekbol kovetkezik, az pedig legyen automatikus. Plusz a user interface-hez is olyan lusta vagyok, hogy az is ebbol az objektum hierarhiabol dolgozik (binding szeruseg formcreate-kor) es egy copypaste onchange eventet sem akarok latni.
    Neha olyan figyelmetlensegi hibaim vannak, hogy az már fáj, szoval inkabb minnel tobb hiba deruljon ki már forditaskor, de legkesobb az ui bindingeknel!

    Altalaban a 'kozpont' (ha jol gondolom) az adatbazis-szerkezet szokott lenni es abbol szarmazik az UI kliens. Na nalam ez a 'kozpont' meg a klienshez legkozelebb van (egy ctrl+space -nyi tavolsagra :D) es abbol scriptelődik az adatbazis-szerkezet.
    Na de ez csak kiserleti stadium, az is lehet, hogy a vegen ilyen lesz -> , de csak nem :D

    Bocs a sok rizsaert, a kerdesre visszaterve ott legyen az adat, ahol azzal dolgoznak, a szerver meg elofeldolgozzon es biztonsagosan taroljon! (szerintem)
    Mutasd a teljes hozzászólást!
  • Hali!
    Bizonyos projektben döntést kell hozni annak értelmében, hogy az adatbázisban tárolandó adatokat - amelyeket egyébként memóriába is be kell tölteni - hogyan kezeljük.

    Példa: bármilyen admin felület, pl. auto nyilvaántartas. Egy uj elem beszúrásakor azt hozzáadom a memoriában tárolt adatokhoz, és beszúrom az adatbázisba is, ez ugye konzisztenciabeli nehézségeket okozhat. Vagy beszúrom adatbázisba és újra frissítem az adathalmazt (listát pl.) a memóriában, ez meg nagyobb műveletigénnyel jár.

    Vagy, .net-ben használhatok DataSet-et, ami berántja az adatbázist memóriába(ha akarom), de ezeket az adatokat nyilván könnyebb objektumokba tagoltan kezelni. Ekkor egy beszúrás alkalmával berakom a DataSetbe is, meg az adatmodellemet is frissítem, ami meg duplikáció és nem igazán tetszik. Persze ez azért jó, mert a műveletek végeztével minden változtatást egyszerre tudok akceptáltatni a db-vel.

    Van jól bevált metodika, vagy programozási stílustól, esetleg problémától függ, hogy melyiket (esetleg vmi hatékonyabbat) illik használni?

    Köszi,
    M.
    Mutasd a teljes hozzászólást!
abcd