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

• #1428 Sk8erPeter nagyúr biker #1419

  Új Válasz 2013-08-21 14:28:11 #1428

  Ú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

  

  Sk8erPeter

  nagyúr

  válasz biker #1419 üzenetére

  "Ne viccelj, miért ne lehetne kigyűjteni egy selecttel az összes terméket ami mondjuk a köv 10 napban akciós ?"
  Senki nem mondta, hogy ne lehetne kigyűjteni, de ezek szerint még mindig nem érted, hogy mi a probléma azzal az elvvel, amit alkalmazol, ami mondjuk elég szomorú. Tényleg ennyire nem vágod az alapvető normalizálási elveket?
  A lényeg: az akciós és aktuális árnak, aktuális szállítónak és egyebeknek semmi keresnivalójuk ugyanabban a táblában, amiben a termékek alapvető, ritkán változó paramétereit tárolod. Most ugyanazt mondtam el másként, mint amit már korábban is leírtam.

  "Itt az az alap tézis részetekről, csak rossz lehet mert sok oszlopa van"
  Kezd tényleg fárasztó lenni. Tudtommal elég régóta vagy fejlesztő, ehhez képest bevált alapelveken vitatkozol, mint aki az évek során jól begubózott, és a saját jól megszokott tervezési elvein kívül mást nem is hajlandó elfogadni, kritikát meg aztán végképp nem. Pedig ha előveszel akármilyen jobbféle adatbázis-kezelős könyvet, ami a kezdő szinttől indít, hidd el, hogy ezekkel az elvekkel elég hamar találkozol...
  fordfairlane amúgy előttem már leírta nagyvonalakban az alapvető problémákat, de erre azt reagáltad neki, hogy "az alapoktol zavaros amit irsz Egyaltalan Te erted?" - most azon kezdtél el kattogni, hogy de hiszen az akció termék nélkül nem is létezhet, de azon még mindig nem gondolkoztál el, hogy vajon miért állítjuk többen is már régóta, hogy alapvető, nem változó paraméterek egyszerűen nem tehetők egy táblába állandóan változó - és például megőrizendő - paraméterekkel (ismét leírtam, hátha átjön), mert az rengeteg kellemetlen problémát szül (átnevezési, törlési, beszúrási probléma, esetleges inkonzisztencia, és az összes többi dolog, amiről már vakerásztunk, vagy amiről még nem). Megdöbbentő ez a vita. Olyan, mintha nem lenne tiszta számodra, mire valók a kapcsolótáblák, az idegen kulcsok, egyáltalán mik azok a normálformák, miért használják manapság ezeket... Ha nem tudod, akkor inkább kérdezz vissza, miért is lenne jobb ezeket használni, de ne úgy pattintsd le magadról az egész témát, mintha még mi lennénk a korlátoltak, hogy nem fogjuk fel, hogy a Te szerkezeted milyen csodálatos (nem az). Kissé türelmetlenné teszed az embert ezzel a stílussal.

  =====

  (#1417) Athlon64+ :
  "Mi kérünk elnézést? "
  Jaja, nagyon úgy tűnik. Ne haragudj, biker.

• #1421 fordfairlane veterán biker #1419

  Új Válasz 2013-08-21 00:14:23 #1421

  Ú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 biker #1419 üzenetére

  Itt az az alap tézis részetekről, csak rossz lehet mert sok oszlopa van

  Nem az oszlopok számával önmagával van a probléma, hanem azzal a fajta adatszerkezettel, amivel letárolásra kerülnek a termékhez kapcsolódó adatok.

  Jelen példa esetében a termékhez kapcsolódik egy akció, aminek vannak attribútumai, például kezdeti-, és végidőpontja. Ezt tranzitív függésnek hívják, és a probléma nem az, hogy egyben van, mert lekérdezés szempontjából ez az adatszerkezet kvázi "kész" van, csak ki kell íratni a mezőket, amire épp szükség van

  A probléma a következők lehetnek:

  1. beszúrási anomália

  Addig nem tudsz létrehozni akciót, amíg nincs készen felvíve legalább egy termék, amihez hozzácsatolod.

  2. módosítási anomália

  Az akciók paramétereit az összes termékrekordon egyszerre kell végrehajtanod, különben inkonzisztens lesz az adatbázis (új akció keletkezik a semmiből, ha valami probléma folytán nem hajtódik végre minden termék rekordján a módosítás)

  3. törlési anomália

  Ha törölsz minden terméket, akkor az akció is törlődik magától. (Mellékhatás, amit ebben az adatszerkezetben nem tudsz megkerülni)

  Ezek olyan nem várt mellékhatásai, amik problémát okozhatnak minden ilyennél, nem csak az akcióknál.

  A normalizálás erről szól. Nem véletlenül találták ki több évtizede, és használják mindenhol.

  És igen, ez azt eredményezheti, hogy akár egy mezőt is külön táblába kell tenni adott esetben, majd ellátni a megfelelő foreign key-jel, ( és persze erre majdhogynem automatikusan mehet rá az index, így a JOIN gyakorlatilag "költségmentes" lesz). Viszont így az adatszerkezet sokkal karbantarthatóbb lesz.

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