Adatbázis rendszer választás egyedi célhoz
2014-09-29T11:53:34+02:00
2014-10-02T23:13:48+02:00
2022-07-19T03:56:56+02:00
  • Azzal van gondom, hogy egyes esetekben nagyon sok plusz munkát tud jelenteni más-más adatkezelő elkészítése és ennek a munkáját szeretném minimumra csökkenteni.

    Ha mindenképpen szükség van egy "valós db szerveres" és egy "single file" alapú megoldásra is, akkor (is) az alkalmazás rétegeinek megfelelő szeparálásával lehetne minimalizálni a munkát.
    Én az alábbi rétegekre bontanám az alkalmazást: DataAccess, BusinesLogic, UI, Entity. Az entity a dal-bl-ui rétegek között mozgó objektumok leírását tartalmazná, osztályok property-kkel, mindenféle logika nélkül, a bl-ben lenne a logika, a dal tartalmazná az adatelérést, a többféle adatbáziskezelő sajátosságai miatti eltéréseket, attól fölfelé a BL és a UI már egységes.
    SQL CE-vel még nem használtam entity framework-öt, de ha SQL Server Expresst és CE-t választanék, akkor, mivel ezek elég közel állnak egymáshoz és a CE a "butább" csak olyan megoldásokat használnék, ami CE-ben elérhető, és azt is elképzelhetőnek tartom, hogy EF-fel ugyan azt a dalt lehet használni akár CE, akár Express felett csupán a connection string app.config-ban való átállításával .
    Mutasd a teljes hozzászólást!
  • Erre találták ki az Entity Framework-öt.
    Mutasd a teljes hozzászólást!
  • A jelen probléma esetén lényegtelen, hogy az adatkezelő réteg a kliensbe van téve vagy ki van rendelve egy külön programba a szerverre. Azzal van gondom, hogy egyes esetekben nagyon sok plusz munkát tud jelenteni más-más adatkezelő elkészítése és ennek a munkáját szeretném minimumra csökkenteni.
    Mutasd a teljes hozzászólást!
  • Én a helyedben kettészedném a programomat egy (vagy több azonos) kliensre és egy szerverre (ami akár lokálisan is futhat) ami biztosítja a hozzáférést az adattáblákhoz. Így a klienseid objektum/stream szinten kezelhetnék az adatokat függetlenül az adattároló infrastruktúrától, a szervernek meg csak arra kéne ügyelni, hogy ne akadjon össze saját magával, miközben adatforrásnak bármilyen szimpatikus megoldást választhatna, sőt váltogathatna a megoldások között.
    Mutasd a teljes hozzászólást!
  • Ha egy adatbázisban volt minden, nekem még soha nem sikerült használható hálózatos Access programot készíteni.
    Eléggé ismerem az Access lehetőségeit, de nem sikerült. Az MS is azt mondja amit írtál, de ennek ellenére sem sikerült.
    Mutasd a teljes hozzászólást!
  • Okosabb. Pl. CE-n esélyed sincs triggert csinálni.
    Mutasd a teljes hozzászólást!
  • @lwaters
    Minden lehetséges, sajnos erről konkrét információm nincsen, szerencsére nem azt kaptam feladatnak, hogy VB6-os kódot javítsak:) Nem szeretnék én Access frontendet, nem tudom mire képes és mire nem, de grafikákat is meg kellene jeleníteni és szerkeszteni. Mi előnyöm lenne winforms-szal szemben? Távoli Asztal és a hasonló megoldások nem játszanak, ez egy dobozos szoftver, nem lehet azt mondani, hogy használjon mondjuk team viewert hozz:D

    @Hupcihér
    Ahogy írtam nem tudom, hogy mi volt a konkrét indok amiért hekkelni kellett a konkurens kezeléshez, elhiszem, hogy megoldható.


    Esetleg valaki próbálkozott már mssql express-ben attach-detach pendrive kombinációval? Előnyének látom, hogy megoldható egyetlen adatbázis kezelő réteggel, támogat tárolt eljárást (pl ce, lite nem) és rá lehet húzni entity frameworkot is. Az olyan jellegű vélemény, hogy "lassú, rossz elképzelés mert ez nem így működik" nem segít. Nem mi szeretnénk ezt így megoldani, a legjobb lehetőséget keressük az ügyfél igényére.
    Mutasd a teljes hozzászólást!
  • Egy régi, VB6-ban írt, ACCESS-t használó hálózatos program... a hálózatos működés nehézkes és sok hiba forrása

    Szerintem a VB6 programban nem volt megfelelő módon megnyitva az adatbázis és a táblák, ezért zárolhatta a táblákat és így a többiek nem tudtak dolgozni párhuzamosan.
    Mutasd a teljes hozzászólást!
  • Működő megoldás lehet az Access frontend és MSSQL Express backend. Ezzel az adatok egy központi helyen tárolódnak, bármelyik gépen, nem kell feltétlenül komoly szerver, és ingyenes is az adatbázis kezelő. Az MSSQL táblákat becsatolod Accessbe, és elkészíted a formokat, riportokat, lekérdezéseket. Hálózatból sok felhasználó elérheti a saját gépén lévő Access program felületén keresztül az adatokat. A távoli elérésre lehet pl. használni Távoli Asztalt. Vagy ha mindenképp hordozni kell, akkor pl. SQL backupolod az adatokat, átmásolod lokális gépre, ahol szintén lennie kell egy MSSQL Expressnek, és restore-olod a helyi adatbázisba. Így haza is vihető a program, adatok, nem kell semmilyen kapcsolat a központi szerverrel. Másik megoldás: Accessel létrehozod a program hordozható változatát és átemeled bele a szükséges formokat, adatokat. Ezt akár pendriveról is indítható, csak egy ingyenes Access Runtime kell hogy legyen a gépen.
    Mutasd a teljes hozzászólást!
  • Itt csak azért szerepel DB, mert az Access nem ismer mást.
    Ha egy Access DB-ba nem teszel semmi mást csak VBA modulokat, akkor csak programod lesz az a DB.


    De már miért csak programot tennél bele, amikor ott van egy komplett DB kezelő? Nagyon jó lokálisan használható ideiglenes táblákat és lekérdezések lehet ott tartani. Nagyon leegyszerűsítik a programozást.
    Mutasd a teljes hozzászólást!
  • Az Accessel így meglehet oldani a problémát. Lehet, hogy másképp is lehet, de így biztosan.
    Szép, folyamatosan működő hálózatos programokat lehet vele készíteni.


    Ha direkt keresed, hogy hogyan nem akarod, lelked rajta. Ha feltétel, hogy mindent egy adatbázisba kell tenni, az összes táblát, lekérdezést, jelentést, programot, stb., akkor az Access ezekkel a csak általad generált feltételekkel nem alkalmas a feladatra. De ha tudomásul veszed, hogyan _lehet_ megoldani a feladatot, akkor alkalmas.

    Nem valami nyakatekert megoldást írtam, csak annyit, hogy válaszd szét a programlogikát az adatbázistól. Ez egy sima többszintű szemlélet, ami még elméletileg is helytálló megoldás.

    Ha a felhasználói proramot különválasztod a központi adattábláktól, akkor lesz egyetlen nagy központi adatbázisod és sok kicsi felhasználói program, melyek a felhasználó gépén alig foglalnak helyet.
    (Ebben az esetben például a felhasználói oldalon nagyon szépen kihasználható, hogy egy komplett adatbázis kezelőt lehet program feladatokra használni.)

    Ha úgy használod az Accesst, ahogy ő kívánja, akkor nagyon szép dolgokat lehet vele csinálni.
    (Például szoktam olyan feldolgozások csinálni, hogy röptében generálok egy Access adatbázist mindenestül, programmal, táblákkal lekérdezésekkel, stb., majd abban indítok egy feldolgozást, a feldolgozás eredményét átveszem, utána törlöm ezt az ideiglenes adatbázist.)
    Mutasd a teljes hozzászólást!
  • Külön db használata lokálisan és az bekötése a nagyba. De biztos csak azért mert nem látom teljesen magam előtt a koncepciót.
    Mutasd a teljes hozzászólást!
  • Mit tartasz hekkelésnek?


    Eddig semmi olyat nem írtam, ami ne lenne az Accessben beépített funkció.
    Mutasd a teljes hozzászólást!
  • Pontosan azzal van gond^^
    Persze lehet van rá megoldás, esetleg lehet az általad leírt is megoldja. Viszont ezt is már hakkolásnak hívnám. Persze kinek mi az:)
    Mutasd a teljes hozzászólást!
  • Access formról írtam. A lényeg, hogy az adat és a kezelő programja külön adatbázisban legyen.


    Kérdésedben szereplő esetben ismerni kellene, hogyan akarta a lekérdezést futtatni, mert ha valaki szerkeszt egy táblát, egy másik felhasználó pedig _ugyanabban az adatbázisban_ levő lekérdezést használna, akkor azzal lehetnek gondok.
    Mutasd a teljes hozzászólást!
  • Te most egy Accessben futó formról beszélsz vagy egy külső programról? Nem igazán tudom, hogy van e különbség. Nálunk egy másik egyszerű probléma volt, hogy valaki megnyitott egy felhasználót írásra más pedig riportot akart készíteni a userekről és kiakadt. Ezt egy VB6 os program hívogatta meg az Accessből.
    Mutasd a teljes hozzászólást!
  • A kezelő formokban vagy "nincs zárolás"-t vagy rekordzárolást kell megadni.
    Ha nincs zárolás, akkor egyáltalán nem fognak összeakadni, ha rekordzárolást adsz meg, akkor csak akkor, ha azonos rekordokat szerkesztenek. A tábla zárolás tényleg használhatatlan ebben az esetben.
    Mutasd a teljes hozzászólást!
  • Köszi a leírást!
    Hogyan oldod meg ha ugyanabba a táblába akarnak írni? Emlékeim szerint az volt az alapvető probléma, hogy A felhasználó megnyitotta írásra a Users táblát és B felhasználó is egy User-t akart szerkeszteni, akkor ezt nem tudta az access lekezelni. Tévednék?
    Mutasd a teljes hozzászólást!
  • Az adatokat, de csak az adattáblákat tedd egy külön adatbázisba. Ide semmi mást ne tegyél. Se lekérdezést, se formot, se semmit, csak táblákat az indexeikkel. Ezt utána tarthatod akárhol.

    A felhasználói programok külön adatbázisban fussanak, melyeket felmásolsz a felhasználók gépeire. A felhasználók programjai ne tartalmazzanak semmilyen közösen használt adattáblát, csak ideiglenes táblákat, ha kell a programnak. Ha beállítod, hogy kilépéskor tömörítsen az Access, akkor a felhasználó adatbázisának mérete nem száll el.

    A felhasználó adatbázisához csatolt táblaként csatold fel a központi adatokat. Működés közben csak sorszintű lockot használj. Ide kerülhet minden egyéb, ami nem közös tábla.
    Ha az adatbázis máshová kerül, és szokott, akkor a táblák csatolása kódból automatizálható, a csatolásokat frissíteni lehet programcsere nélkül.

    Ha ezeket a szabályokat betartod, simán megy minden. Egy felhasználó sok programot indíthat akár és többel is dolgozhat egyszerre.
    Mutasd a teljes hozzászólást!
  • Ejj, és mi ez a metodika amit használsz? Tényleg kíváncsivá tettél. Nem ellenzem én az Access-t, a régi alkalmazáshoz nem sok közöm van, így a konkurencia kezelőjét sem én írtam. Ha nem üzleti titok akkor szívesen meghallgatnám, hogy kezelsz le ennyi felhasználót egyszerre.
    Mutasd a teljes hozzászólást!
  • Az access, esetén egy darab fájlt használ a program, megnyitod, olvasod/írod, bezárod. Nincsen körülötte egy kezelő motor, ezt a kliensek végzik. Viszont ezért nem kezeli a konkurens működést, mivel a kliens "nem tud a többiekről". Különböző hakkokkal lehet megoldani, hogy ne dobjon hibát/fusson hibára.

    Nem kell azt hekkelni, nem fut az hibára sok felhasználónál sem, ha jól kezeled.
    Mutasd a teljes hozzászólást!
  • Egy régi, VB6-ban írt, ACCESS-t használó hálózatos program újraírását tervezem. Az új programban WinForms és .net 4.5 lesz használva, ez más-más paraméterek miatt fix. Cél, hogy az alkalmazás gyors legyen, sok esetben 10.000 sort tölt be és a felhasználó "szemmel keres" közöttük. Jelenleg az ACCESS miatt a hálózatos működés nehézkes és sok hiba forrása.

    Mert rosszul használja a program az Accesst.
    Nálam kb. 30-50 user dolgozik egyidejűleg Access adatbázissal, és semmilyen gond nincs velük. Az igazat megvallva, kb. másfél éve nem volt egyetlen hibajelzés sem.

    Ha az Access elegendő, és szükséges, hogy kompakt legyen a megoldás, akkor jó választás lehet.

    (Természetesen itt most majd jönnek az Access-t ellenzők akiik számosan vannak.)
    Mutasd a teljes hozzászólást!
  • Félre érted, nem kevés munka a cél, hanem kevesebb. Sőt nem is csak a munka mennyisége, hanem a használt technológia rugalmassága is számít. Ha mondjuk a lekérdezés kódját kell módosítani, de cserébe máshol a többihez képest nagy plusz támogatást ad, nem probléma.

    Nem minden helyen engedik meg maguknak a dedikált szerver gépet, de szeretnék többen használni egyszerre. Ne felejtsük el, hogy attól még, hogy nekünk alap, hogy kell egy szerver gép, az ügyfél diktál és ő nem mindig szeretne. De ezen fölösleges is törni magunkat, a probléma adott.
    Mutasd a teljes hozzászólást!
  • Nem tudom, mekkora programról van szó, de nekem nem úgy tűnik, hogy most ezt kevés munkával nem fogod megúszni. Jól gondold át, hogy végül mire lépsz.

    Ha egy cégnek adod el, ahol több felhasználó van, akkor ott melegen ajánlott egy olyan gép, amit szervernek hívnak - feltételezzük, hogy nem akarják az adatokat harmadik félnél tárolni.
    Ha pedig van olyan, hogy szerver gép, akkor arra ajánlott tenni egy üzleti logikát.  Majdnem mindegy, hogy milyen adatbázis motor van. Pláne, ha kevés kliens akad rá.
    Mutasd a teljes hozzászólást!
  • Meg is indokolnád, hogy miért lenne jobb mint a CE mondjuk?

    Köszi
    Mutasd a teljes hozzászólást!
  • SQL Server Expresss és SQLite szerintem jobb megoldás. Vagy firebird.
    Mutasd a teljes hozzászólást!
  • Ezt "a user viszi magával pendrive-on a saját adatbázisát" nem nagyon értem.

    Az ügyfeleink igénye, hogy ne a cloudban és ne is nálunk tároljuk az adataikat. Egyszerűen szükség van rá, hogy a saját pendriven legyen minden. Ezzel szemben hajlandóak limitációkat elfogadni mint például a hálózatos használat korlátozottságát/nehezen megoldottságát. Viszont ugyanazt a dobozos terméket használhatják olyanok is, ahol 10 kliens szeretné konkurensen nyűni az adatbázist.

    A usert belépteti, authentikálja az új alkamazásod, innen eldől, hogy ki van bejelentkezve az adott kliensen, építhetsz jogosultsági rendszert, mindenki csak a saját szerepköréhez és/vagy a saját useréhez tartozó információkat láthatja.

    Tisztában vagyok az autentikáció alapjaival, nem ezzel van a gond. Próbálj egy Access-t rávenni arra, hogy többen tudjanak ugyanabba a táblába írni, ellenkezni fog:)

    Vagy ez egy kis dobozos termék lenne, amit nem csak egy cég használ, hanem egymástól független cégek vagy magányszemélyek akiknek nem akarsz követelményként sql szervert előírni?

    Pontosan, ez egy dobozos termék. Van aki még a windows xp-t is újdonságnak gondolja sajnos, náluk majd megküzdünk a .net verzióval. Az lenne még a szép, ha rá kellene venni, hogy a régi laptopján fusson egy mssql express...

    Ha már teljesen újra akarod írni a legacy alkalmazást és mindenképpen desktoposra .net-tel akkor én inkább a WPF-re szavaznék, kicsit más szemléletű, mint a WinForms, de jobban szét lehet szeparálni a dolgokat ha jól használod az MVVM patternt.


    Szóba jött ez is, végül elvetettük és maradtunk a formsnál.
    Mutasd a teljes hozzászólást!
  • Az access, esetén egy darab fájlt használ a program, megnyitod, olvasod/írod, bezárod. Nincsen körülötte egy kezelő motor, ezt a kliensek végzik. Viszont ezért nem kezeli a konkurens működést, mivel a kliens "nem tud a többiekről". Különböző hakkokkal lehet megoldani, hogy ne dobjon hibát/fusson hibára. Ezzel szemben egy adatbázis szerver mint pl az mssql már futtat egy rendszert az adatbázis "körül", ami várja a klienseket, sorba teszi a tranzakciókat és ügyel a konkurens kezelésből adódó problematikákra (és még sok minden másra, de az mindegy). Ezért viszont nem ingyenes (vagy korlátozásai vannak, pl amit első hozzászólásomban írtam) vagy nagyobb erőforrásigénye van.

    Lényeg a lényeg, a problémám adott, szükségem volna egy megoldásra, hogy különböző igényeket (fájl alapú és szerveres adatbázis) tudjon a programom kiszolgálni és ezt úgy tegye, hogy minél kevesebb munkát kelljen a változatok megírásába tenni.
    Mutasd a teljes hozzászólást!
  • Ha MS SQL Servert használsz (Express is) vagy bármi egyebet pl Oracle, MySql, az megold(hat)ja mind a 3 kategória igényeit: egy felhasználó egy gépen, egy felhasználó több gépen, több felhasználó több gépen. Nem is értem, hogy miért kellene ekkor ezt a 3 különböző opciót megkülönböztetni. A usert belépteti, authentikálja az új alkamazásod, innen eldől, hogy ki van bejelentkezve az adott kliensen, építhetsz jogosultsági rendszert, mindenki csak a saját szerepköréhez és/vagy a saját useréhez tartozó információkat láthatja. Ezt "a user viszi magával pendrive-on a saját adatbázisát" nem nagyon értem. Miért nem jobb, hogy van egy fix db szervered és a kliensek innen szedik le az adataikat? Vagy ez egy kis dobozos termék lenne, amit nem csak egy cég használ, hanem egymástól független cégek vagy magányszemélyek akiknek nem akarsz követelményként sql szervert előírni? Ha egy cég célalkalmazásáról van szó, akkor símán lehet a domainen belöl valahol egy dedikált sql szerver.
    Ha már teljesen újra akarod írni a legacy alkalmazást és mindenképpen desktoposra .net-tel akkor én inkább a WPF-re szavaznék, kicsit más szemléletű, mint a WinForms, de jobban szét lehet szeparálni a dolgokat ha jól használod az MVVM patternt.
    Mutasd a teljes hozzászólást!
abcd