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

• modder aktív tag

  #2095

  #2092 PazsitZ

  2014-01-27 16:00:17

  Új Válasz

  Ú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

  

  modder

  aktív tag

  #2092 PazsitZ

  #2092 PazsitZ

  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ó

  Csak hogy ne kanyarodjunk el nagyon, az előfeltételek, amiket már legelőször is említettem (vagy nem) a kutyafuttában összedobott hozzászólásomban:
  - Átlagos/kis terhelésű weboldalról van szó, nem valami hatalmas terhelésről. Mit tudom én, napi pár 10e oldal lekérés
  - Kis adatbázisméret: pár 10e rekord, pár 10MB adatbázis méret (ez mondjuk egy blog mérete sok cikkel)

  Azért fontos ezt megemlíteni, mert nagy tábláknál, amik sok I/O műveletet igényelnek, fontos, hogy ne növekedjen duplájára a rekord méret egy CHAR field miatt.

  Mondok két előnyt:
  - az egyik, amiből az egész kiindult, hogy ha a lekérdezéseket szerkesztem valamilyen kliens programban, akkor jobban esik az agyamnak, ha a konkrét információt látom a mezőben, ha ellenőrzöm, jó lekérdezést írtam-e meg. Ide tartozik még, ha valaki (vagy én) évek múlva hozzá akar nyúlni a szoftverhez és adatbázishoz, leegyszerűsödik a dolga.
  - a városos példánál maradva nincsen szükség joinra, ami egy kicsit le tudja egyszerűsíteni a lekérdezést, ha egyébként az nagyon összetett; sok másik jointot is tartalmaz.
  - ha szoftverben valamilyen ORM frameworkot használunk, közvetlenül benne lehet a város neve a személyek entitásban, ahelyett, hogy egy varos entitason keresztül kéne hozzáférnem az értékhez. (Elképzelhető, hogy egy-egy kapcsolatnál be lehet süllyeszteni a személy entitásba a várost, de most nem jut eszembe, hogy pl. JPA-nál lehet-e)

  ...három lett

  Egyébként én először olyan információt akartam szövegként tárolni, ami tipikusan egy enum (SQL) típus lenne, és a mező "kardinalitása" olyan 10 db érték körül mozog. Enummal az a baj, hogy nem elég dinamikus, ha új értékre van szükségem az alkalmazásban, akkor módosítanom kell az elérhető enumok listáját, ami MySQLnél azt is eredményezheti, hogy újragenerálja az egész táblát. És az enumra lett volna alternatíva a numerikus vagy szöveges érték, ahol én arra szavaznék, hogy legyen csak szöveges pl.
  Státusz = {"active", "inactive", "suspended", "deleted"} ahelyett, hogy 1,2,3,4-t tennénk a mezőbe. És szerintem ez tényleg nem nagy eretnekség.

  VÁLASZOK:
  ----------------------------------------------------

  bambano, pazsitZ: De fontos ha rossz teljesítményt produkálna a szöveges tárolás. Az volt a gondom, hogy azt sugalltad, az SQLlel egyébként is teljesítményt vesztünk, következésképpen mindegy, hogy a szöveges tárolással teljesítményt vesztünk. Ezzel ki is dobhatnám az érvem, miszerint nem volt teljesítménybeli különbség. Egyébként itt az említett link - aki lemaradt volna -, érdemes megnézni, hogy 1.5 millió rekordnál, kis rekord méretnél, tehát befér a memóriába a tábla, nem volt különbség. http://www.mysqlperformanceblog.com/2008/01/24/enum-fields-vs-varchar-vs-int-joined-table-what-is-faster/
  Egyébként nem hálós adatbázisról beszélünk, hanem relációs adatbázisokról (és nem SQL adatbázis).

  martonx: Ebben teljesen igazad van, hogy szöveges mező index esetén, ha mysql B-TREE indexről van szó, az index mérete bizony jócskán megnövekedhet a numerikus indexhez képest, de a keresés nem lesz annyival lassabb, mert a string összehasonlítás csak az első nem egyező karakterig hasonlít, a fa magassága pedig nem nő akkorát, jellegéből adódóan. Hash indexnél pedig mindegy, mert ott úgyis csak a hash van eltárolva az indexben.

  pazsitZ: 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?
  (Arról az esetről van szó, ha szövegként tárolom a város nevét, de kell egy másik tábla, ahol az összes lehetséges város tárolva van) Nincs szükségem string joinra lekérdezésnél, hiszen a város neve ott van a személyek táblában. Beszúrásnál van szükség idegen kulcs ellenőrzésre, ami index alapján történik.

  martonx: Ráadásul pont ez az az általad is sokat kritizált gányolós, kókányolós, hozzáállás az, ami miatt aztán tömegek bele is kövesednek ebbe a programozói attitűdbe. Elvégre minek normálisra megcsinálni az indexeket, meg a relációs kapcsolatokat, há' nem sokkal egyszerűbb, mindent beb***ni egy táblába, megfelelő indexeket rátenni, és ha megnézem ezer sorig még gyors is?
  Azért ez nem teljesen így van. Akkor lenne kókányolás (amúgy imádom ezt a szót, én is sokat használom ), ha ezzel alapjaiban véve mennénk szembe a relációs adatbázis elvekkel, de ahogy kifejtettem a normalizálós hozzászólásomban, erről szó sincs. Egyébként én is nagy teljesítményhajhász vagyok, de nem szeretek lemondani a kényelemről ott, ahol nem kapok érte cserébe elég nagy előnyt teljesítményben. És úgy érzem, amíg tudom, hogy nem lesz több száz megabyteos az adatbázisom, addig ez egy ilyen helyzet.

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