Új hozzászólás Aktív témák

• #7 bambano titán cucka #6

  Új Válasz 2011-08-09 20:03:52 #7

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  válasz cucka #6 üzenetére

  mint ahogy a hsz-ben, amire válaszoltál, nem is lett kijelentve, hogy egyik vagy másik egyértelműen jobb.

  Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

• #13 bambano titán cucka #11

  Új Válasz 2011-08-11 01:02:00 #13

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  válasz cucka #11 üzenetére

  szerintem ha egy adatszerkezetet mindenre megpróbálsz optimalizálni, végül nem optimalizálod semmire. ezért nem hatékony szerintem az sql.
  de meggyőzhető vagyok az ellentétéről.

  Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

• #17 bambano titán cucka #15

  Új Válasz 2011-08-11 12:59:22 #17

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  válasz cucka #15 üzenetére

  Persze, hogy nem lehet globálisan kijelenteni, hogy valami hatékony, ezért nem hatékony az sql egy-egy lekérdezésre lehet mondani, hogy az adott adatszerkezet ahhoz a lekérdezéshez optimális.

  a hálós adatbáziskezelőkben pont ez a trükk, hogy egy bizonyos lekérdezésre vagy lekérdezés-típusra bitang gyors, a többire meg erősen vakaródzik. szemben az sql-lel, ami egyenletesen nem optimális.

  Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

• #26 attila9988 őstag cucka #25

  Új Válasz 2011-08-11 14:48:03 #26

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  attila9988

  őstag

  válasz cucka #25 üzenetére

  A postgre teljesen jó rendszer, de pont nem a sebességéről híres.

  Megfelelően kell "hangolni", és akkor gyors.

  „Csak az apró titkokat kell védeni. A nagy felfedezéseket a nyilvánosság hitetlensége védi.” (Marshall McLuhan)

• #27 bambano titán cucka #25

  Új Válasz 2011-08-11 16:00:53 #27

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  válasz cucka #25 üzenetére

  Az miért rendszergazda szemszög, hogy fontos a sebesség?

  "Egy rdbms X funkcióhalmazt valósít meg, egy nosql adatbázis meg Y-t, ahol jellemzően Y részhalmaza X-nek.": ami, szerintem, nem annyira fontos. A helyesebb nézőpont az, hogy egy sql-ben x módon kell elérni egy eredményhalmazt, hálósban meg y és x meg y között semmi összefüggés sincs.

  Bankos példánál maradva: sql-ben egy ügyfél számláján a mozgásokat, a history-t kb. úgy szeded elő, hogy egy táblából szelektálsz azon sorokra, ahol a tranzakcióhoz tartozó számlaazonosító az, amit keresel. Kapsz egy eredményhalmazt, amin egyesével végiglépkedve kapod meg a program adatterületein belül az eredményt.

  Hálósban meg megkeresed az ügyfél számláját, ahhoz oda vannak láncolva a mozgás rekordok, csak a láncon kell végigmenni, mintha memóriában egy kétszeresen láncolt listát buherálnál. Ciklus, következőre mutató mutató, stb. Csakhogy itt oda vannak láncolva a rekordok a számla rekordoz, tehát nem kell szelektelni, nem kell végigolvasni az egész táblát és/vagy index táblát.

  Következmény: ha már megtaláltad az ügyfél rekordját, a számlatörténet előállítása ebben a hálós adatszerkezetben nagyon sokkal gyorsabb. Viszont egy nem elsődleges kulcs szerinti keresésbe meg beleszakadsz. Leprogramozni is ótvaros, lefuttatni is.

  "Ha a rendszered építése során neked olyan szolgáltatásokra van szükséged, amelyek X-nek részei, de Y-nak nem, akkor az összehasonlításod értelmét veszti.": minden nyelven lehet fortranban programozni. másik mondás a szomszédból: amit nem lehet assemblyben leprogramozni, azt nem is érdemes.

  Az összehasonlítás nem veszíti értelmét attól, hogy valamit nem tud az adatbáziskezelő, csak költség/idő ráfordítás oldalon kapsz pofont, hogy le kell programoznod. A szokásos végeredmény pedig az, hogy egy másik ponton meg akkorát javul a rendszer, hogy kutyaszorítóba kerülsz, melyik ujjadat harapd le.

  A vételár eléggé egzakt valami szokott lenni. Ha van mondjuk egy projekted, ahol 20 fabatkát költhetsz sw-re, 20-at hardverre és akkor bejön a kilométeres nagypofájú oracle sales manager és meg akar győzni, hogy 140 fabatkáért vegyél egy alap oracle-t, akkor ilyen paraméterek mellett tetszőleges oracle jó tulajdonság sem ér semmit.

  Az, hogy valami a mysqlnél 2.5x gyorsabb, elég gyenge érv

  Az emberek egy része egyszerűen szokott választani: valahogy ráesik az egyikre, azt megszokja, és attól kezdve, hogy kalapácsa lett, mindent szögnek lát.

  Lehet, hogy a postgresql nem a sebességéről híres, azért én csak kicsiholtam belőle kb. 60x-os sebességet az akkori mysql-ekhez képest. Nem muszáj, hogy erről legyen híres, nem is számít pedig a mysql-ben még raidelt táblákat is használtam.

  A mysql nálam akkor vágta el magát, amikor a szabad licenszű mysql-ben nem volt tranzakció kezelés, így adatbáziskezelőnek se nagyon lehetne nevezni. Az a tény, hogy időközben lett benne, engem már nem szoktatott le a postgresről.

  Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

• #30 bambano titán cucka #28

  Új Válasz 2011-08-12 21:55:44 #30

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  válasz cucka #28 üzenetére

  Az a baj az összes hszeddel, hogy feltételezed: egy adatbázis hozzáférési interfésze kizárólag relációs lehet. Ha ezt el tudnád vetni, rájönnél, hogy az rdbms nem kizárólagos út, gyakran nem is az optimális út. A relációs adatmodell mellett még legalább kettőt tanítanak rendes egyetemen, a hálóst és a hierarchikust. Ha rendes egyetemre jártál, ahol rendes oprendszereket is tanítanak, nem csak hulladékot, akkor hálós adatbáziskezelővel találkozhattál.

  - nem, nem hagyom ki a szoftvert.
  - "Az, hogy milyen típusú adatbázist érdemes használni, azt a szoftver dönti el, a szoftver igényei szerint kell adatbázist választani, ami tudja a megfelelő funkciókat": persze, ez egy frankó álmodozás, a valódi életből vett tapasztalatok meg azt mutatják, hogy egy vagy több tulajdonságban minden adatbáziskezelő hibádzik. Az egyik az egyikben, a másik a másikban.

  - "ha noSQL-t használsz és a szoftver rétegben megírod alá az rdbms funkcionalitást": ez egy ökörség. Azért használok nosql szerű adatbáziskezelőt, mert NEM akarok rdbms funkcionalitást, mivel az korlátoz.

  - "különféle tranzakciók során garantált-e az adatbázis integritása, ...": nem értem a problémát. annyira lehetetlennek tartod, hogy amit egyszer le tudtak programozni (az rdbms-ben), azt máskor soha nem lehetett leprogramozni? ne már...

  -"Akkor meg oda lyukadunk ki, hogy gyakorlati szempontból nézve mégsem hasonlíthatod össze.": miért?

  - " Kevés nagyobb ökörség van, mint noSQL-t használni, majd szoftveresen alátenni azokat a funkciókat, amiket egy rdbms tud.": ez igaz. más kérdés, hogy ilyet nem is akar senki. ha hálós adatbázist használsz, akkor hálós gondolkodásmódot kell felvenned és úgy kell programoznod. Az, hogy rdbms szemlélettel programozol hálós rendszert, az ökörség, mint ahogy te is leírtad.

  - persze, csak ha a drága szoftver nagyságrendileg lóg ki a költségvetésből, akkor felesleges agyalni rajta.

  A neve egyszerű: a hálós adatmodell szabványt a codasyl dbtg dolgozta ki, magyarul Halassy Béla munkája alapján terjedt el. De olvashatsz róla a Korth-Silberschatz könyvben is.

  Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Új hozzászólás Aktív témák