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

• #4455 Szmeby tag MrSealRD #4451

  Új Válasz 2020-03-10 14:17:53 #4455

  Ú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

  

  Szmeby

  tag

  válasz MrSealRD #4451 üzenetére

  "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."

  Mi köze a UI-nak a DB reprezentációhoz?

• #4454 nyunyu félisten MrSealRD #4451

  Új Válasz 2020-03-10 11:23:56 #4454

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

  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.

• #4452 Ferfiu tag MrSealRD #4451

  Új Válasz 2020-03-10 10:39:43 #4452

  Ú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

  

  Ferfiu

  tag

  válasz MrSealRD #4451 üzenetére

  Én azt javaslom, hogy tedd le a voksodat a közös vagy a külön táblák mellett. Nincs lényegi különbség gyorsaságban, a fejlesztők/üzemeltetők életét könnyíted meg, ha egységes, és nem keveredik a két hozzáállás egy adatbázison belül.

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