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

• #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