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

• nyunyu félisten

  #4454

  #4451 MrSealRD

  2020-03-10 11:23:56

  Ú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

  

  nyunyu

  félisten

  #4451 MrSealRD

  #4451 MrSealRD

  Először is köszi az észrevételeket.

  bambano : A fenti szerkezet csak egy kivonat. Pontosan ez volt az érvelés mögötte amit te is írsz. Ettől biztosan több lesz a karbantartandó adat. Az ehhez kapcsolódó implementáció nem akkora overhead. Inkább felhasználói oldalról volt ez vizsgálva. Hogy ne kelljen sok képernyőn keresztül kiigazodnia a user-nek, hogy karbantartsa ezeket az adatokat. Így egy képernyőn el tudja intézni. Persze az implementáció is szóba került, hogy egyszerűbb 1 képernyőt megcsinálni.
  Objektíven nézve nekem ez egy új megoldás...és úgy érzem ez ellentéte a normalizálásnak.

  whYz A tovább bontás az már meglévő gondolat. Igazából az egész állapot egy piszkozat. Szóval ez még nem a végleges. Sok kérdés tisztázás alatt van még.
  A TYPE+ID esté type-onként lenne egyedi az ID. Ezért kell együtt PK-nak lenniük.
  Én a szétbontás mellett vagyok, ahogy az ábrán is rajzoltam. Viszont látok realitást is a másik ötletben is...

  nyunyu A hibernate nem kőbe vésett dolog. De abból amit írsz nekem inkább egy rosszul konfigurált és rosszul működtetett Hibernate réteg körvonalazódik... Ezt a fejlesztőkkel kell lejátszani, mert ez így nem fenntartható. Széles körben alkalmazott technológia. Nem tökéletes, semmi sem az, de viszonylag jó vélemény van róla többségében.
  -----
  
  Visszatérve a DB szerkezetére. Nem nagyon tudok érvelni a közös tábla ellen. Mondjuk kódból kell nagyon undorító dolgokat csinálni. Mert egy közös típus lesz különböző dolgokra. A pókösztönöm azt mondja ez nem egészséges hosszú távon.

  Normalizálásnak megvan a maga helye és az ideje, de ez az eset nem tűnik annak.
  Mostanában már nem annyira a tárhely (memória, vinyó, szalag...) a szűk kapacitás, mint tizenévekkel korábban, így már nem feltétlenül érdemes a normalizációval megspórolható helyre gyúrni.

  Adattárházaknál például bevett szokás a csillag séma, amikor egy nagyon széles, sokmillió soros ténytáblához joinolnak sok kicsi dimenziót, viszont a dimenziótáblák tartalmát nem nagyon szokták normalizálni, hogy minél kevesebb joinnal gyorsabban lekérdezhető legyen a nagy mennyiségű adat.
  Vannak olyan mondások is, hogy a dimenziókat nem ártana normalizálni, azt hívják hópehely sémának, de az általában ront a lekérdezések, adattranszformációk sebességén.

  Előző projektünkből kiindulva az sem ideális, amikor tizen-huszon, alig pár rekordot tartalmazó paramétertáblát kell kerülgetned, hogy mi az amit a következő shipmentbe bele kell tenned, és mi az amit nem szabad.
  Olyankor valami mindig kimarad, vagy éppen felülírod az éles beállításokat egy alsóbb környezetre érvényes teszt beállítással.
  Ráadásul fél évvel később az üzemeltetési doksi írásakor már nem is emlékeztem arra, hogy kollégák melyiket mire használták, sokat úgy kellett kitúrni a kódból, amikor az üzemeltetők rákérdeztek valami egyedi beállítási lehetőségre.

  Azon a projekten a fontosabb paraméterek állítására például az Üzlet kért egy képernyőt, ahol Excelben letöltheti a fontosabb paramétertáblák tartalmát, majd szerkesztés után visszatölthesse.
  Azokat a táblák tartalmát például tilos volt dumpként a shipmentbe adni, nehogy felülírjuk a felhasználók beállításait.
  Ha új sorok kellettek, akkor azokat élesítéskor insertekkel kellett beszúrni.

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