2. Fórumok
  3. Szoftverfejlesztés
  4. SQL kérdések
  5. (kiemelt téma)
Keresés

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

  • #4956 bambano titán Taci #4941
    Új Válasz #4956
    Ú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 Taci #4941 üzenetére

    jó lett volna, ha leírod, hogy milyen adatbáziskezelőről van szó.
    a későbbi hsz-eid alapján ha találgatnom kellene, azt írnám, hogy mysql.
    miért nem postgresql? :)

    igen, jól érted. a jól normalizált adatszerkezet lényege, hogy később sem kell belenyúlni. ha most rakás táblád van és azt később bővíteni kell, akkor a lekérdezésekbe is bele kell nyúlni, meg mindenbe.

    a lényeg, hogy el kell választani a logikai sémát a tárolási sémától. a logikai séma azt mutatja meg, hogy hogyan kell kinézzen az adatbázis, miután normalizáltad. a tárolási séma meg azt, hogy indokolt esetben miben tér el a logikai sémától.

    amit emlegettek mások is, ha nagy a tábla, akkor lehet particionálni a táblát. ráadásul ha külön tablespace-be teszed a partíciókat, akkor a diszk elérés is gyorsulni fog (régen a mysql tudott raid0-t, de kivették belőle...)

    mondjuk az is relatív, hogy kinek mi a nagy adatbázis. a postgesql párszázmillió rekorddal még szépen elgurul. utána kell elkezdeni tákolni a tárolórendszert hozzá.

  • #4944 nyunyu félisten Taci #4941
    Új Válasz #4944
    Ú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

    nyunyu

    félisten

    válasz Taci #4941 üzenetére

    De amúgy tényleg érdekelne, hogy miben/mennyivel "rosszabb", ha több táblában vannak az adatok. Nyilván a sebesség az egyik válasz, ez biztos. De érdekelne, miben még.

    Leginkább a kód karbantarthatóságról szól a felvetésünk. (meg olvasni, átlátni is könnyebb a rövidebb, egyszerűsített kódot)

    Most ha bejön egy új alrendszer/forrás, akkor kézzel definiálsz neki egy új táblát, arra indexeket, meg a meglévő kódbázisban az összes union-os selectet ki kell bővíteni +1 ággal, hogy az új forrást is visszaadja.
    Plusz szopni fogsz, ha bármelyik táblába fel kell venni egy plusz mezőt, mert akkor kézzel alter table az összesre, hogy az unionok továbbra is működhessenek...

    Míg egy táblánál csak az új forrás adatbetöltő rutinját kell megírnod, ami egy új azonosítóval szúrja be a meglévő táblába a rekordokat.
    Plusz oszlop igény esetén meg elég egy táblát alterelni, nem fog elszállni a kód (ha ki van mindenhonnan irtva a select * :)) )

  • #4943 nyunyu félisten Taci #4941
    Új Válasz #4943
    Ú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

    nyunyu

    félisten

    válasz Taci #4941 üzenetére

    Úgy szeretném megcsinálni, hogy utána szerkezeti változás miatt ne kelljen már "soha" belenyúlni, ezért veszem a fáradságot és időt és átírom, ezzel nincs baj. Csak érteni is szeretném a miértjét.

    Ha most nem léped meg a refaktort, és később kiderül, hogy valamelyik táblába fel kell venned pár plusz oszlopot, akkor az összesbe veheted fel egyesével ugyanazokat, ugyanabban a sorrendben, különben hibával elszáll az összes union-os lekérdezésed!

    Mondjuk ebből a szempontból a select *-os slendriánság sem egy életbiztosítás :DDD
    Sokkal elegánsabb, és hibatűrőbb, ha egyesével felsorolod a lekérdezendő oszlopokat + insertnél a beszúrandó tábla oszlopait.

    magyarul mindenhol így nézzen ki a kód:
    insert into tábla (oszlop1, oszlop2, oszlop3)
    select oszlop1, oszlop2, oszlop3
    from tábla2;

    Ez nem fog megborulni, ha bármelyik tábla szerkezete módosul.

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