Firebird vs MsSQL vs egyeb SQL serverek

Firebird vs MsSQL vs egyeb SQL serverek
2002-12-19T11:28:42+01:00
2004-02-06T11:07:57+01:00
2022-11-01T19:55:36+01:00
  • jó, konkrétan fogalmazok: mondjuk úgy hogy két év alatt egyszer sem kellett azért upgradenünk, mert egy mysql hiba miatt (amelyek egytől egyik publikusak és könnyen végigolvashatóak!) felmerült volna hogy adat elveszne vagy hibás eredményt szolgáltatna.

    Webes alkalmazás nekem nem feltétlen azt jelenti, hogy szinte csak lekérdezések (hanem azt hogy brutális mennyiségű kliens egyszerű műveletekkel), de a lekérdezések sebessége miért nem számít?

    Van egyébként egy speciális előnye a mysql-nek amit adott esetben nem lehet eléggé értékelni: másfél millió rekordot szépen elkezelget 10 megabájt lefoglalt memóriában.
    Mutasd a teljes hozzászólást!
  • en meg egy dolgot szeretek figyelembe venni az epp hasznalt RDBMS-nel. Megpedig, mennyire tamogatja az SQL '92 szabvanyt (akik csak szamokban ertenek: ISO 9075. Van neki ANSI is de annak a szamat nem tudom fejbol). En ezen ok miatt nem szeretem a MySQL-t.

    Sting csoportositasaval (valahol lentebb egyetertek).

    Hogy webes alkalmazasoknal nem kell a tranzakcio, az nem igaz. Szvsz nincs semmi kulonbseg a webes es desktop alkalmazasokban ilyen teren. Barmelyikben lehet nagy es kis programot irni, adatbazissal a hatterben.

    Hogy a vas es a penz is szamit ketsegtelen. Az is igaz, hogy az adott feladathoz kell valasztani az adatbazismotort. De MySQL-t en szemely szerint tenyleg csak ott hasznalnek, ahol nincs eleg penz a projectre es nem szamit ha hiba csuszik a dologba, valamint nem nekem kell karbantartanom es fejlesztenem. Az SQL-nek elvileg a magasabb foku absztrakcio megvalositasa is a feladata lenne, amely cel elereseben a MySQL nem tul jo barat...

    ozy
    Mutasd a teljes hozzászólást!
  • Koszonom az eddigi hozzaszolasokat, de sajnos a kerdesemre meg nem kaptam valaszt.

    Kicsit pontositom, hogy mire is lenne szuksegem:
    konkretan szeretnem tudni, hogy egyes SQL serverek mit tudnak es mit nem.

    (pl: ha ismernem az osszes SQL servert es csinalnek 1 bohom nagy tablazatot amiben minden server minden tulajdonsagat, kepesseget beleirnam akkor itt lathato lenne, hogy mi - mit tud.... no ezt tablazatot keresem:)

    az alabbi linkeket talaltam eddig amin olyasmi infok vannak amire szuksegem van (de sajnos FIREBIRD-rol nincs szo bennuk) :


    http://www.mysql.com/information/crash-me.php

    http://mysql.tiszanet.hu/information/benchmark-results/result-db2,in..

    TPC-C - Top Ten Performance Results
    Mutasd a teljes hozzászólást!
  • Szerintem igenis használható a MySQL, egyszerűbb adatkezelési feladatokra, mint PL egy közepesen látogatott webes fórum. Nyilvánvaló, hogy nem arra való, hogy egy nagyvállalat adatait kezelje, de nem is erre szánták. Az adatbázis konzisztenciája is megvalósítható némi odafigyeléssel. Persze tárolt eljárásokkal korrektebb lenne az biztos.





    Mutasd a teljes hozzászólást!
  • Adatvesztéshez nagyon sok fajta hiba vezethet. Pl. egy indexhiba - ami miatt a DBMS nem talál meg egy adott kritériumnak megfelelő rekordot - az alkalmazási logikával közösen ugyanúgy okozhat súlyos adatvesztést, mint egy bad sector. Tehát hibás azt hinni, hogy csak az a hiba súlyos, amiben gyakorlatilag közvetlenül maga az adatbáziskezelő töröl vagy ír felül - a kezelő által nem szándékolot módon - adatokat.

    Egyébként meg a fentiekkel összefüggésben a webes alkalmazásoknál is lehet kritikus a tranzakciókezelés megléte. Egyébként is pont rossz példát hoztál fel, mert a tpikus webalkalmazásoknál (ha már általánosságban beszélünk, ahogy te is tetted) eltörpül a módosítások (INSERT, UPDATE) száma a lekérdezésekhez (SELECT) képest. Ilyen körülmények között pedig nagyon irreleváns, hogy egy század, vagy egy tized másodpercig tart egy adott írási művelet elvégzése, hiszen elsősorban nem ez határozza meg az általános működési sebességet. Pusztán SELECT-ekhez meg ugye nem kell tranzakció...
    Mutasd a teljes hozzászólást!
  • Nem igazak ezek a szintek mert a web típusú alkalmazásoknál nem kell a tranzakció, a sebesség viszont kritikus.

    Az hogy nem kell a tranzakció egyrészt következmény is, mert ha kényelmes is lenne néha, akkor se használhatnád a sebességveszteség miatt.

    "A megbízhatóság is lehet szempont." Na ez így szó szerint igaz. Hogy "is". Alapvetően ugyanis minegyik megbízható. A megbízhatóságnál árnyalatakról beszélünk, minthogy az egyik 99.9% a másik 99.99%. És adott esetben ennek van az utolsó prioritása.

    Azt egyébként nem tudom, miért lenne a MySQL-ben több adatvesztéssel járó bug, mint a DB2-ben. Márcsak azért sem, mert kábé két éve olvasom a MySQL change listáit, és egy olyan bug se volt, ami miatt alapesetben adatok veszhettek volna el.
    Mutasd a teljes hozzászólást!
  • A sebesség és az adatok konzisztenciája szorosan összefügg a fejlettebb adatbáziskezelő funkciók, mint pl. a tárolt eljárások, összetett lekérdezések, stb. létével, vagy nem létével is. Pl. éppen ezért tökéletesen alkalmatlan a MySQL bármilyen komplex adatbázis menedzselésére, mert esetében a végletekig kell fokozni az adatok redundáns tárolását (fényévekre a harmadik normáltól) ahhoz, hogy elfogadható sebességgel lehessen adatokat kinyerni egy komplex rendszerből is. A redundancia persze a konzisztencia és az alkalmazás egyszerűségének rovására megy. De pl. a tárolt eljárások segítségével garantálható lenne a tökéletes konzisztencia - de ugye ezt sem tudja a MySQL. Arról meg hogy a SELECT vagy pl. a típuskezelés terén milyen hiányosságai vannak, jobb ha nem is beszélünk.

    Egyébként szerintem a MySQL jelenlegi, bizonyos speciális környezetekben jelentkező előnyei csak addig maradnak meg, amíg megmarad annak, ami most is: egy SQL front-enddel megfejelt butácska kis rekordkezelőnek. Ha ugyanis még sok plusz raknak bele, akkor önmagát fogja kinyírni. A már piacon levő más (komoly) adatbáziskezelők ugyanis a közép- és felsőkategóráis szegmensekben már eleve sokkal jobb választások nála.
    Mutasd a teljes hozzászólást!
  • A megbízhatóság is lehet szempont. Persze ha minden megy tökéletesen akkor semmivel nincs gond, de Pl. ha egy program lerohad akkor már láttam olyat hogy a fájl alapú rendszerekben sérültek a fájlok.
    Ezt a MySQL már kivédi, ha az app elszáll akkor nem repül vele a szerver, ez már egy alapvető biztonságot nyújt. A második lépés az adatok integritása, azaz ha egy számlát kiadtam akkor a készlet is csökkenjen vele párhuzamosan, ne legyen olyan hogy az egyik művelet sikerült de a másik már nem. Erre jó a tranzakciókezelés ami a MySQL-ből hiányzott. E fölött a szint fölött már szvsz inkább sebességgondok szoktak lenni (nagy adatforgalom hatására fragmentálódás, lassulás, mennyire jó a query optimalizálás és hasonlók) (kivéve ha van egy-két bug a szerverben ami azért valljuk be MySQL-ben szintén valószínűbb mint DB2-ben).
    Mutasd a teljes hozzászólást!
  • MS SQL-el dolgoztam régen és mostanában MySQL-el. Nagyon eltérő témákban, a Microsoftos üzleti alkalmazás volt kevés, de bonyolult tranzakciókkal, a MySQL pedig tömeges de egy-két rekordos műveletekkel web illetve alkalmazás szerver mögött.

    A kettő között nagyon durva sességkülönbség van, a MySQL javára.

    A MySQL tranzakciós tábláival nem dolgoztam, azt nem tudom milyen gyors.

    De például komplex tranzakcióknál a MS Access is sokkal gyorsabb volt az MS SQL-nél! (utóbbi viszont nyilván jobban skálázható). Sybase SQL Anywhere is sokkal gyorsabb.

    Megbízhatónak elég megbízható mindegyik, MS Access-el voltak csak kisebb gondok.

    Szolgáltatásban MS SQL a három közül a jobb.

    Szóval valami abszolút sorrendet leírni nem lehet, még ha az árat nem is vesszük figyelembe akkor se.
    Mutasd a teljes hozzászólást!
  • LC speciel nem "a tudasat / sebessget / funkcioit" tekintve, hanem "teljesítmény, megbízhatóság szempontjából" rendezte sorba az adatbaziskezeloket.

    Ettol fuggetlenul is fenntartom - es ha valaki ert hozza, nem fog ebben cafolni -, hogy a feladattol es az alatt levo vas tipusatol fuggoen egy MySQL is lenyomhat egy MSSQL-t sebessegben/ teljesitmenyben, es forditva is.

    Egyebkent a PostgreSQL is egy csomo teren siman ubereli az IB-t - mas helyeken meg iszonyu hianyossagai vannak utobbihoz kepest. (De ez megint csak ezt erositi, hogy a konkret feladat donti el, melyik a jobb valasztas.)

    A masik, hogy az MSSQL-t, Oracle-t es DB/2-t meg veletlenul sem emlitenem semmilyen szempontbol egy lapon az IB-vel, es a PostgreSQL-lel, mint ahogy a MySQL is inkabb kulon kategoria.

    A MySQL-t egyebkent en sem szeretem, de ettol meg teny, hogy van olyan feladat, amire alkalmasabb, mint a tobbiek.
    Mutasd a teljes hozzászólást!
  • ellenben a kollega reszltesen a
    tudasat / sebessget / funkcioit
    figyelembe veve erdeklodott az elso es utolsoban pedig stimmel az LC alltal felallitott sorrend.

    ozy, aki itt nem elfogulatlan, mert bar az IT-n belul szinte mindennel ki van bekulve, de a MySQL-t tiszta szivbol gyuloli. Persze, csak ha hasznalnia kell.

    Mutasd a teljes hozzászólást!
  • A "teljesítmény" az erősen függ a feladattól (pusztán a sebességet figyelembe véve - ami azért nem minden - is van olyan alkalmazás és konfig, amihez a MySQL a gyorsabb, és van olyan amihez az MSSQL a jobb választás), megbízhatónak pedig mindegyikük stabil változata ugyanannyira megbízható (vagy ugyanannyira megbízhatatlan, mert bugok közismerten mindegyikben vannak, bár ezek általában nem kritikusak).

    Szóval csak úgy a "levegőbe" - a konkrét feladat, konfig, és egyéb jellemzők ismerete nélkül - nem lehet megmondani, hogy melyik jobb/gyorsabb.
    Mutasd a teljes hozzászólást!
  • Én még nem láttam ilyet, de azok alapján amit a neten lehet olvasgatni kb. ez a sorrend az adatbáziskezelők között teljesítmény, megbízhatóság szempontjából:

    - ORACLE, DB2
    - M$ SQL
    - FireBird, Borland IB 7, SAP DB (erről nagyon keveset hallani pedig a leírása alapján elég jó)
    - Postgresql, Open IB
    - MySQL
    - Fájl alapú dolgok (dBase, Access, paradox)
    Mutasd a teljes hozzászólást!
  • sziasztok

    tudtok-e olyan doksirol es hol ami osszehasonlitja az egyes SQL serverek tudasat / sebessget / funkcioit...?
    ha van akkor elsosorban olyan kene amiben FIREBIRD vagy rosszabb esetben INTERBASE is szerepel....

    elore is kosz thx...
    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