Adatbázis hibák elleni védelem
2003-07-24T13:00:17+02:00
2003-07-27T07:41:47+02:00
2022-07-19T05:57:26+02:00
  • A paradox szerintem a lehető legrosszabb megoldás. Teljesen zárt bináris formája van, ha megsérül akkor csak a TUTILITY.DLL-re épülő programokkal lehet próbálkozni de többnyire elég kevés sikerrel. Ráadásul tud például olyat hogy az adatbázisnak csak a 1500, 3900, 9512-es sora sérül, a többi nem, és ezt csak fél év múlva veszed észre amikor a féléves összesítésnél olvasni szeretnéd. Ilyenkor már általában mentés sincs... Ha már valaki fájl alapú vackokat használ akkor inkább DBF vagy MDB, az előbbinek ismert a szerkezete, az utóbbi pedig valamennyire ellenőrzi hogy sérült-e az adatbázis és valamivel hatékonyabb javító mechanizmusa van mint a tutility.dll. De szvsz minden fájl alapú dolognál sokkal jobb még egy MySQL is, nem beszélve a komolyabb dolgokról, Pl. Firebird.
    Mutasd a teljes hozzászólást!
  • Sziasztok

    Régóta foglalkozok különböző tipusú programok fejlesztésével. Működik több helyen különböző számlázással kapcsolatos programom, elég nagy rekordszámmal. Lekérdezések is vannak benne rendeswen. Megfelelő módszerekkel a lekérdezések, sőt a tranzakciók is kellőképpen gyorsak. Nagyrészüket paradox táblákra irtam, még adatot nem vesztettem. (kopp kopp) Szerintem 1-2 gigás adatbázisra tökéletesen jó a paradox. Olcsó, szereti a Delphi. Különösebb karbantartási igénye nincs. Jelenleg Oracle-lel dolgozok, de az már egy más kategória. A kettő között részemről a Postgre jöhetne még szóba. MySql-ben nincs tárolt eljárás, MsSql nem ér annyit.

    Kellemes adatbázisfejlesztést mindenkinek.
    Mutasd a teljes hozzászólást!
  • A program egy kis- és mikrovállalkozás-irányítási program lenne... ELég sok megvan már belőle (35e sor körül), egyenlőre paradox táblákkal, amik mondjuk remekül működnek egyenlőre, de még kevés az adat ahhoz, hogy azt tudjam mondani, hogy marad a paradox.
    Ezért keresnék alternatívákat a paradox kiváltására, és ezeknél fontos lenne a biztonság, a folyamatos rendelkezésre állás, és az ár.
    Mutasd a teljes hozzászólást!
  • "Arra, hogy egy programhoz olyan adatbázis-kezelő rendszert tudjak kiválasztani"

    Éppen az a kérdés, hogy milyen programhoz. Lásd pl. bocs fejtegetését.

    Mutasd a teljes hozzászólást!
  • "Volt rá eset, hogy munka közben elszállt a server, miután a tápellátása megszűnt. Bekapcsolás után nem volt adatvesztés. (No comment.) "


    Nekünk volt régebben egy villámcsapott NT4-es szerverünk. Azon IB 5 futott, fizetős.


    A lényeg az, hogy az egyik táblában volt úgy 4-500 ezer rekord. Ha a leválogatás néhány rekordra ért (összesen kb. 10-20 ilyet találtunk) akkor az NT4 szerver szónélkül bootolni kezdett :))))
    Mutasd a teljes hozzászólást!
  • Én határozottan MSDE-t ajánlok, HA
    - kis vagy közepes méretű adatbázisról van szó (max valahol 1 GB)
    - egyidejűleg 5 konkurrens lekérdezésnél nem lényegesen több fog futni
    - tranzakció kezeléssel nem akarsz komolyan foglalkozni, mert az szvsz elég rossz

    A legfontosabb szempont a stabilitás, és ebben igen jó az MSDE: nekem napi 8 órai fejlesztéssel 5 év alatt nulla darab elszállást produkált. Ebben tehát jó.

    Sebességben 1-2 száz MB adatbázis méret és tisztességes adatbázis szerkezet (PK, FK, index ahol kell) egész jó, nincs vele gond.

    Ár: olcsó. Ugyanis megveszed kb 100 eFt-ért, és onnantól ingyen adhatod tovább bárkinek.

    Ha tranzakció kezelésre van kihegyezve a projekted, akkor viszont inkább az InterBase vonalat javaslom. Annak viszont teljesítményben és stabilitásban kell megfizetned az árát.

    Sajnos a DB2 most beindított low-end vonaláról nem tudok semmit.
    Valaki?
    Mutasd a teljes hozzászólást!
  • Arra, hogy egy programhoz olyan adatbázis-kezelő rendszert tudjak kiválasztani, ami - ha lehet - nem kerül sokba, esetleg ingyenes, de ettől függetlenül biztonságos.

    inetg
    Mutasd a teljes hozzászólást!
  • Nos, az Interbase ingyenességére vonatkozó állítás nem pontos. Az IB 6.0x verzio két változata létezik:
    a. Ingyenes, de támogatás nincs (unsupported), emellé még open source is.

    b. Támogatott, nem ingyenes verzió.

    Még egy adalék:

    kb. 2 éve megy Linuxon az IB 3 serveren, Windows alatti Delphiben fejlesztett kliens programokkal, BDE kihagyásával. Volt rá eset, hogy munka közben elszállt a server, miután a tápellátása megszűnt. Bekapcsolás után nem volt adatvesztés. (No comment.) A 2 év alatt a 3 helyszínen összesen mintegy 8 óra volt a leállás, ebben benne van egy diszk elszállás és egy tápegység csere. Program vagy IB lepukkanása miatt nem volt üzemszünet.
    Mutasd a teljes hozzászólást!
  • mire?
    Mutasd a teljes hozzászólást!
  • Akkor végülis mit ajánlotok? IB, FreeBird, MSSQL, PostgreSQL, MSDE?

    inetg
    Mutasd a teljes hozzászólást!
  • Koszi a kiigazitast ! Jogos, eleg spongyolan fogalamaztam... ill. valoszinuleg nem is tudtam pontosan a tortenetet!

    Udv.
    Mutasd a teljes hozzászólást!
  • (idokozben a Borland visszavette sajat berkeibe a fejlesztest az open-source kozossegtol es ujra fizetos)

    Egyrészt az IB sosem volt ingyenes. Voltak ingyenes változatai FreeBSD-re, meg Linuxra, de ennek köze nincs a kód megnyitásához (még előtt voltak ezek), és pl. Win-en mindig is fizetős volt.

    A másik dolog, hogy a Borland semmit nem vett (nem vehetette) vissza, így továbbra is elérhető a Firebird nevű alternatíva, ami a Borland által korábban megnyitott kódbázis továbbfejlesztését képezi.
    Mutasd a teljes hozzászólást!
  • visszatérve mysql-re, lecserélheted a táblákat MyISAM-ról InnoDB-re, az jobban bírja az ad-hoc táplekapcsolásokat. ALTER TABLE-val meg lehet változtatni a típust utólag is. Másik opció, az indító scriptbe berakni egy automatikus table check + repairt a MyISAM táblákra.

    Nálam két év alatt kétszer volt hasonló probléma. Ha jól emlékszem az egyiknél utána nem indult a mysql, a másiknál csak a backup nem ment, repair table mindkettőnél segített.
    Mutasd a teljes hozzászólást!
  • Ha meg MS környezetben dolgozol, akkor ott az MSDE. Előnye, hogy ingyen van, ha van fejlesztőeszközöd (VStudio vagy Office Developer, vagy WebMatrix -- ez utóbbi letölthető, igaz, hogy csak a .NET Framework-öt támogatja), akkor ingyen adhatod a saját cuccoddal. Ráadásul az ilyen alkalmazást utána változtatás nélkül tudod áttenni MSSQL-re, ha kell.

    Hátránya, hogy 2GB/adatbázis a méretkorlát, és a konkurrens lekérdezések szaporodásával fékezi a teljesítményt, de ez erősen forgalomfüggő.
    Mutasd a teljes hozzászólást!
  • Szerintem probald ki a firebird-t, ez
    a Borlandos interbase alapjain fejlesztik (idokozben a Borland visszavette sajat berkeibe a fejlesztest az open-source kozossegtol es ujra fizetos), es ugyanugy jellemzo ra ami az interbase-re, megpedig a minimal config, magyaran felteszed es megy...

    Udv.
    Mutasd a teljes hozzászólást!
  • A régi szép időkben én is elkövettem pár fájl alapú ügyviteli szoftvert (dbf, paradox, acccess). Ezeknek közös tulajdonságuk volt hogy ha elszállt a progi (ami azért előfordulat akkor is ha maga a program nem hibás, Pl. a user felülnyom egy dll-t, vagy a grafkártya drivere instabil és megfagy az egész gép,stb) gyakran sérültek az adatok is. Érdekes egyébként hogy a régi szép DOS-os időkben ez annyira nem volt probléma, ha el is szállt egy clipper progi fizikai adatsérülés nem nagyon volt.
    Úgy hogy pár szívás után rájöttem hogy a legegyszerűbb egy RDBMS szerver a lokális gépen is: ha a program elszáll általában nem viszi magával az adatbáziskezelőt is. Ha mégis elhal az RDBMS szerver is (Pl. takarítóasszony kihúzza a drótot) akkor is lehet reménykedni hogy egy journaling fájlrendszer + az adatbáziskezelő védelmi mechanizmusai kiküszöbölik a nagyobb bajt.
    Azért nem ár néha menteni így sem...
    Mutasd a teljes hozzászólást!
  • Igen.. ilyen nekem is volt, hogy elszállt egy-egy adat, de aztán Paradox tábláknál FLushBuffers, és refresh sűrű használata esetén sikerült ezt kiküszöbölni.
    Én is gondolkoztam azon, hogy milyen adatbáziskezelőre lehetne áttérni, most is egy nagyobb projekt kezdése előtt vagyok és ennél nem lennének jók az elszállások.
    Viszont valami olyan megoldás érdekelne, amit kereskedelmi programhoz is mellékelni lehet, illetve a beállításaivan installáláskor nem kell bajlódni sokat. Tud valaki ajánlani valami jó megoldást?

    inetg
    Mutasd a teljes hozzászólást!

  • ...Paradox, DBE megoldás volt. Egy kis idő kelett hozzá hogy rájöjek arra hogy ha elszáll a program vagy az egész gép akkor történik meg. Rá kelett jönnöm hogy nem hagyhatok mindent a DBE-re hanem magamnak kell gondoskodnom az ilyen dolgokról.


    Azt kell mondjam a Paradox nem jo valasztas ilyen, nagy adatbiztosnagot igenylo rendszerhez. Hisz tulkepp nem mas csak egy rekordmanager, es nem relacios adatbaziskezelo rendszer (RDBMS), igy nem is nyujthat ilyen szolgaltatasokat.
    Nem hiszem hogy megerne rengeteg idot raszannod hogy te magad tedd meg a szukseges vedelmet a paradox helyett inkabb valassz valami SQL alapu RDBMS rendszert (akar ingyenest is, pl. Firebird, v. PostgresSQL, vagy penzest ha te vagy a megrendelod ki tudja fizetni : pl. MS SQL Server, Oracle, Sybase, stb. De konnyen elkepzelhetonek tartom ha ez egy egyszeru szamlazoprogram akkor boven eleg valasztas egy freeware cucc). Ezek felepitesuknel fogva biztositjak ezeket.

    Mélyebben nem ismerem a többi adatbáziskezelőket sem.

    Hat akkor itt az ideje hogy utananezz hogyan is mukodik egy RDBMS, vannak nagyon jo magyar konyvek is a temaban, nezz szet a kiskapu.hu-n !

    De egy dolog hogy mit nyujt alapbol egy SQL adatbazis, nem art ha azt annak a filozofianak megfeleloen hasznaljak, tehat jol kell tudni az SQL-t, es erdemes kicsit elmelyedni a kivalasztott RDBMS finomhangolasaban is a megfelelo teljesitmenyhez, ill. meg egy lenyeges dolgot nem szabad elfelejteni ha adatbiztonsagrol van szo : BACKUP !!!!
    Mutasd a teljes hozzászólást!
  • Egyrészt ott kezdődnek a dolgok, hogy a hibát nem tünetileg kell kezelni, hanem gyökerében, azaz a programot kell megírni rendesen, meg gondoskodni arról, hogy az OS se fagyhasson le, áramszünet se lehessen, stb.

    A másik, hogy tudomásul kell már venni, hogy MySQL, Paradox és társaik nem adatbáziskezelők. Ezeket nem eleve arra tervezték amire ma használják őket, hanem csak különböző hackekkel "felokosították" a szükséges szintre - és hát az eredmény kevéssé meggyőző.

    A Paradox már csak azért is sokkal sérülékenyebb ilyen szempontból, mert a rekordmenedzser teljes kódja magában az alkalmazásban fut, így ha az megpusztul, akkor a DBMS-ben is megáll az "ütő". MySQL, Interbase, PostgreSQL, stb. esetén legalább külön processz gondoskodik az adatbázis fizikai manipulálásáról, így a kliens program megfagyása esetén ő még képes lehet kezelni a helyzetet, azaz pl. az utolsó műveletet visszavonni, vagy befejezni.
    Mutasd a teljes hozzászólást!
  • Én is akartam viát indítani erről a témáról.
    Nemrég az történt hogy az egyik helyen a számlázóprogramom elfelejtette az egész napi adatokat. Megtörtént többször is. Érdekes jelenség hogy mások nem jöttek ilyen panasszal. Paradox, DBE megoldás volt. Egy kis idő kelett hozzá hogy rájöjek arra hogy ha elszáll a program vagy az egész gép akkor történik meg. Rá kelett jönnöm hogy nem hagyhatok mindent a DBE-re hanem magamnak kell gondoskodnom az ilyen dolgokról.
    Mélyebben nem ismerem a többi adatbáziskezelőket sem.
    Szerintetek nem logikus hogy egy adatbázis szerver automatikusan gondoskodjon az ilyen dolgokról.
    Van-e valaki közöttetek aki meg tudná mondani hogy az ilyesmit hogy szokták megoldani és hogy hogy van ez a nagyvilágban (Oracle vagy hasonló).
    Valóban az áramkiesés nem normális dolog, de az is biztos hogy nem lehet komoy program az amelyik géplefagyáskor elfelejti a napi forgalmat.
    Mutasd a teljes hozzászólást!
  • nem normális dolog ha egy gép elszáll.


    Ebben igazad van, csak épp a kérdés nem erre vonatkozott. Ráadásul ha az adataid eléggé értékesek, akkor még a nagyon valószínűtlen gépelszállásra is gondolni kell, áramszünet (vagy esetleg fakezű taki néni) meg bárhol lehet, és ez is gépelszállásnak minősül az adatbázis szempontjából.

    Rendes adatbáziskezelők a módosításokat akkor is implicit módon tranzakcióban hajtják végre, ha ezt külön nem kéred; pont azért, hogy az adatbázis szerkezete konzisztens maradjon. Ha persze te jobban tudod, hogy az alkalmazásod számára milyen utasítás-sorozat alkot egy tranzakciót (azaz atomi módosításhalmazt), akkor ezt persze megmondhatod neki.

    megnézném, hogy egy szerverek bérbeadásával foglalkozó cég milyen gépeket használ és egy pontosan ugyanolyat vennék/raknák össze.


    Ezzel meg az a baj, hogy bár az elv jó, de a piac működésmódja, meg a hardvergyártók hihetetlen költségérzékenysége miatt nem fogsz tudni ugyanolyan gépet összerakni. Pláne nem, ha egy éve futó konfigurációt akarsz duplikálni: az a fajta alaplap, vezérlők, stb. már valószínűleg más fajta alkatrészekből lesz összerakva, ha egyáltalán kapható még.
    Mutasd a teljes hozzászólást!
  • nem normális dolog ha egy gép elszáll. Gyakran ez valami hardverhibára utal. Ha nekem most magamnak kellene szervert összeállítanom, akkor megnézném, hogy egy szerverek bérbeadásával foglalkozó cég milyen gépeket használ és egy pontosan ugyanolyat vennék/raknák össze. De még náluk se a legújabb típust, hanem valamit ami már legalább egy éve megy.
    Mutasd a teljes hozzászólást!
  • Nem MySQL-t kell használni, hanem adatbáziskezelőt, és máris meg van oldva a probléma. Egymással összefüggő módosításokhoz meg tranzakciót nyitni. Ennyi.

    A programozói hibák ellen nem, de a manipulációk, injektálás és hasonlók ellen nagyon jó szolgálatot tehet az is, ha az adatbázis tábláit sosem közvetlenül módosítod (insert, update, delete, segítségével), hanem csakis és kizárólag tárolt eljárásokon keresztül.
    Mutasd a teljes hozzászólást!
  • Azt elfelejtettem írni, hogy bármilyen adatbázisra gondoltam, általánosságban gondoltam a kérdést, legyen szó mySQL-ről, PostgreSQL-ről, Paradox, dBase táblákról, stb.

    inetg
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Azon gondolkoztam, hogy van-e valami általános mód arra, hogy az adatbázisokban történő hibákat kiküszöböljük, vagy megelőzzük?
    Régebben programoztam php-ban, mysql kapcsolatoknál néha volt olyan, hogy fagyás esetén pár hibás adat került az éppen nyitott táblákba. Ezt pl. egy FlushBuffers-el el lehetett kerülni, vag y atáblát rögtön lekérdezés után zárni.

    inetg
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd