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

• #2092 PazsitZ addikt modder #2083

  Új Válasz 2014-01-27 09:41:37 #2092

  Ú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

  

  PazsitZ

  addikt

  válasz modder #2083 üzenetére

  Nekem a problémám megint csak ott van, h ellentmodnást érzek.

  Szóval mégis csak szükséged van egy másik táblára.
  Ahol mondjuk település adatokat tárolsz. Ekkor viszont már minek a string?
  String join amúgy is lassabb lesz feltehetőleg, persze biztos elmegy úgy is, de végül akkor amúgy is lesz szükséged join-ra.
  Nagyon egyszerű tesztelésen kívül pedig nem látom még mindig a rációt a kézzel túkálok a táblában érv mellett. De ekkor is én nem kézzel turkálnék, hanem query-vel populálnék be minta adatot is talán.

  Egyébként a karakterkódolásra bár azt mondtad, nem lehet gond, én mégis idegenkedek ilyen-olyan spec. karaktereket használni (bár konkrét példa most nem jut eszembe), az int index az viszont biztos, h teljesen egyértelmű és hibamentes lesz.

  A hatékonysági kérdésekkel csak akkor érdemes ilyen mélyen foglalkozni
  Feljebb még te linkeltél performance eredményeket a sztring tárolás védelmében, akkor fontos volt. Ha valaki negatív performance eredményt említ akkor már nem fontos?

  U.i.:
  Most téynelg nem kötözködni akarok, csak még mindig nem látom a hasznot. De persze ettől még nyugodtan tárolhhatod így, nincs ezzel gond, engem legalább is nem zavar.

  Nem zavar, amíg nem kell más ilyen DB-jét migrálnom. Sajnos kellett már, nem volt jó

• #2089 martonx veterán modder #2083

  Új Válasz 2014-01-26 22:48:19 #2089

  Ú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

  

  martonx

  veterán

  válasz modder #2083 üzenetére

  Mivel semmi konkrétumot nem írtál, nyilván én se tudtam mit írni azon kívül, hogy még a felvetés is hülyeség. No, de közben jött itt egy példa a településnevekkel.
  Szerinted melyik megoldás a rövidebb? Egy 16 - 32 bit hosszú mezőben eltárolni egy numerikus adatot, vagy egy 50X16 bitnyi mezőben eltárolni egy szöveges adatot.
  "- index sebessége: annyival lassabb egy pl. 30 karakter hosszú CHAR vagy VARCHAR mezőn az index használata?"
  Jelzem, amikor erre a mezőre indexet húzol, az indexed is pont ilyen méret differenciákkal fog létrejönni.
  Aztán nézzünk még egy érvet. A processzorok leggyorsabban számok feldolgozásával működnek. Persze-persze, minden mást is fel tudnak dolgozni, ami binárisan leírható, de akkor is minden CPU alapja a "számolás".
  Számszerűsítve a dolgot, olyan több mint 50-szeres sebességkülönbség simán lehet a két megoldás között. Azt persze aláírom, hogy kis tábla méreteknél ez észrevehetetlen, de ha egy táblában van 2-3 ilyen szarul megoldott indexed, és a tábláid több százezer sorosak, netán valami gyenguc hoszting gépen vagy többtized magaddal ugyanazon az adatbázison, akkor ez máris másodperceket, akár perceket jelenthet.

  Egyébként amit felvetettél, abszolút nem eretnek gondolat. Tegyél fel egy MongoDb-t, vagy bármilyen NoSql-t, toljál a hoszting gépedbe pár 10 Gb memóriát, és máris bármilyen lehet az adatbázisod, és még csak lassú se lesz.

• #2088 bambano titán modder #2083

  Új Válasz 2014-01-26 19:24:51 #2088

  Ú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 modder #2083 üzenetére

  "Ez úgy hangzott, mintha az SQL használatával nagyságrendekkel rosszabb teljesítményt érnénk el": ez valószínűleg azért hangzott úgy, mert igaz, feltéve, hogy nem az eredeti szövegkörnyezetéből kiszakítva értelmezed a mondatot. az eredeti szövegkörnyezetben nem az volt az állítás, hogy egyik sql lekérdezés a másik sqlhez képest milyen, hanem az, hogy egy adott sql lekérdezés egy nem sql rendszerű, itt konkrétan hálós volt emlegetve, adatbáziskezelőhöz képest milyen. hát lassú.

  Az eredeti mondat ez volt: "merthogy az sql masszívan nem hatékony akár a hálós adatbáziskezelőket nézed, " és igen, az sql rohadtul nem hatékony egy hálós adatbáziskezelőhöz képest, pláne, ha a lekérdezés olyan, amire a hálóst tervezték.

  a személy meg a város kérdéskör meg akkor lesz érdekes, ha egy városból több személy van, pláne, ha nem egyszerre töltik be az adatokat, és akkor elkezdik a t. userek mindenféle néven illetni a településeket. ez még városoknál nem annyira nyilvánvaló, de én még nem láttam olyan adatbázist, ahol az utcaneveket képesek lettek volna egységesen írni. az meg, hogy ilyenkor nyakonvágjam a t. usert, kívánatos, de nem lehetséges megoldás

  no mindegy, járod a magad útját, oszt jónapot.

• #2086 fordfairlane veterán modder #2083

  Új Válasz 2014-01-26 18:45:28 #2086

  Ú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

  

  fordfairlane

  veterán

  válasz modder #2083 üzenetére

  Tároljuk a település nevét szövegként a személy táblában, vagy egy numerikus kódot és joinoljuk egy településeket tartalmazó táblával mindig?

  Ha a település neve egyedi, akkor a név lehet kulcsmező. Szövegként tárolni a települések közt, és idegen kulcsként is felhasználható egyidejűleg.

• #2084 Ispy nagyúr modder #2083

  Új Válasz 2014-01-26 18:16:14 #2084

  Ú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

  

  Ispy

  nagyúr

  válasz modder #2083 üzenetére

  Tároljuk a település nevét szövegként a személy táblában, vagy egy numerikus kódot és joinoljuk egy településeket tartalmazó táblával mindig?

  Igen, pontosan, erről szól a relációs adatbázis kezelés, ettől még persze nem muszáj így csinálnod, de megerősítésre itt ne várj.

  (12 éve dolgozok SQL-lel, megírni egy joint, olyan mint levegőt venni, fel sem tűnik)

  "könnyebb elírni": miért, a numerikus azonosítót nem könnyű elírni?

  Ha van numerikus mezőm, nem kézzel kell megadni az értéket, hanem listából választani, így elírni nem lehet (max. rosszat választani).

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