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

• #1413 fordfairlane veterán biker #1410

  Új Válasz 2013-08-20 18:05:28 #1413

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

  akkor minden darabolással egy redundáns termék_ID oszloppal hízlalod az adatbázist...

  Mert jellemzően nem attól lesz redundáns az adatbázis, hogy túl sok tábla kerül bele, hanem attól, hogy túl kevés. Például ebben a példában a közös akciókban szereplő termékeket nem tudod összekötni egymással, mert termékenként tárolod az akciók összes attribútumát. Aztán mi van akkor, ha egy adott termék más szállítótól érkezik, hogyan kapcsolod a kettő tételt össze, ha a termék statisztikájára vagy kíváncsi?

  Ez az egész téma ráadásul egy adatbázis tervezési tanfolyam első leckéi közé tartoznak. Normálformák, ilyesmi. Alapvető dolog relációs adatbázisoknál. Ez az egész aggódás, hogy túl sok a tábla akkor szokott előjönni, ha a JOIN-ok vagy az indexek használata már lassan és nehézkesen megy, ami adatbáziskezelésnél viszont alapvető dolog.

• #1412 Peter Kiss őstag biker #1410

  Új Válasz 2013-08-20 16:56:48 #1412

  Ú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

  

  Peter Kiss

  őstag

  válasz biker #1410 üzenetére

  Arra hivatkozni, hogy redundás lesz a termék ID-ja, az kicsit megmosolyogtató, egy SQL szervernek ez nem érdekes.

  Termékek tábla:

  id,
  név,
  rövid leírás,
  hosszú leírás,
  cikkszám,
  vonalkód,
  kat_id,
  + ki mikor módosította és még e mögé a tábla mögé még egy, ami minden sort ment triggerrel.

  Kellene egy szállítók, és a szállítókkal összerendelő:

  szállítói kód,
  szállítási idő,
  termék_id
  + mettől meddig ki és mikor módosította

  Címkék nyilván nem kerülhetnek ide, szintén: címkék tábla + összerendelés + audit;

  ÁFA osztály inkább tartozik a kategóriához, ha egy termék csak egy kategóriában lehet.

  Egy termék árát szintén külön táblában vezetjük, hogy lássuk, mettől meddig mennyi volt, és ki módosította. (Nem beszélve arról, hogy már a jelenben beszélhetünk a jövőről.)

  Az akciókat belekeverni talán a legdurvább, azt eleve ki kell vezetni, hogy milyen akcióink vannak, meddig tart és mi tartozik bele, nyilván a beállításai (melyik/minden termék hány százalékkal, stb) + az auditálási dolgok megint.

  Csík így hirtelen pongyolán ezek jutottak eszembe. A gond az, hogy elég lenne csak egy "ki mit csinált" kérdést feltenni a te szerkezetedhez, fel kellene tenned a kezed, hogy izé, az úgy volt. .

• #1411 Sk8erPeter nagyúr biker #1410

  Új Válasz 2013-08-20 15:22:44 #1411

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

  Csak gyorsan futottam át, amit írtál, de sztem a legrosszabb példákat írtad, például ha van egy adott termék, aminek az alapvető jellemzői nem változnak, de a szállítói adatok bőven változhatnak (például adott hónapban valamiért más a szállítója ugyanannak a terméknek), akkor azok miért kell, hogy ugyanott szerepeljenek, ahol a termék id, név, leírás? Vagy például az akció eleje és vége hogy lehetne már ugyanabban a táblában, sőt, ugyanabban a rekordban tárolható? Az ára, akciós ára meg aztán végképp állandóan változik... Szerinted nem épp az a feleslegesen redundáns, hogy a leírás ennyiszer szerepel a táblában? Vagy nem is értem az elgondolást.
  Az a kijelentés meg, hogy az indexelések nem gyorsíthatnak jelentősen a rengeteg adatot tartalmazó táblában való keresésen, már inkább a vicces kategória szerintem.

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