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

• #4456 MrSealRD veterán Szmeby #4455

  Új Válasz 2020-03-10 19:45:32 #4456

  Ú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

  

  MrSealRD

  veterán

  válasz Szmeby #4455 üzenetére

  Így önmagában semmi... Az 1 képernyős karbantartást meg lehet oldani több tábla esetén is. Én csak megosztottam az érvelést amit kaptam.

  nyunyu : Ez mondjuk nem adattárház lesz. Viszont mivel tervezési fázisban vagyunk ezért én próbálok minden esetleges vonatkozást megvizsgálni. Most a Hibernate is elgondolkodtatott... Ott is vannak kérdőjelek az egyesített tábla miatt.

• #4453 MrSealRD veterán Ferfiu #4452

  Új Válasz 2020-03-10 10:48:10 #4453

  Ú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

  

  MrSealRD

  veterán

  válasz Ferfiu #4452 üzenetére

  Persze, semmiképp sem akarom keverni. Én fejlesztési oldalról vagyok érintett. A PM akivel az alapokat tesszük le meg, hát PM meg üzleti oldalról érintett. Ezért nézzük két szemszögből. Itt az a nagy kérdés, hogy mi legyen az elhatározás. Az oké, hogy egyik legyen, de melyik?

• #4451 MrSealRD veterán

  Új Válasz 2020-03-10 10:07:20 #4451

  Ú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

  

  MrSealRD

  veterán

  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.

• #4447 MrSealRD veterán whYz #4446

  Új Válasz 2020-03-09 21:37:38 #4447

  Ú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

  

  MrSealRD

  veterán

  válasz whYz #4446 üzenetére

  Először is igen. Normalizáció. Én is ebben a hitben éltem eddig. Mivel érzékeny adatokról van szó, ezért meg kellett változtatnom a kontextust. Viszont a lényeg, érthető maradt.
  

  Ez egy gyors kivágás és átírás, ezért az ehhez kapcsolódó hibákat és a kapcsolat típusát most ne firtassuk.

  Szóval a lényeg, a ContractTypes és a Level táblák. Ezekbe legfeljebb néhány rekord lenne, de részben ősfeltöltés részben a működés közbeni módosíthatóság miatt kapna CRUD felületet. ContractTypes lehet állandó, vagy ideiglenes...stb A Level, meg amatőr, haladó, profi..stb.

  Na most erre kaptam egy olyan javaslatot, hogy legyen 1 tábla.
  Aminek az első oszlopa legyen TYPE ide kerülne be a ContractTypes vagy Level értéként.
  Második oszlop ID ami lenne valami inkrementált szám.
  Majd jönne LEVEL_NAME ami Level típusnál kapna értéket.
  Végül A CONTRACT_TYPE ami csak ilyen típusnál kapna értéket.

  Ezt nem tudom lerajzolni, mert nekem is fura. De a olyasmi mint egy általános tábla amibe több értékkészlet van összevonva és a TYPE + ID együttesen adja a PK-t.

• #4445 MrSealRD veterán

  Új Válasz 2020-03-09 19:38:56 #4445

  Ú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

  

  MrSealRD

  veterán

  Ugyan a Java topikba dobtam be a kérdésem: [link]
  De gondoltam bedobom ide is, hogy hátha kapok egy kis inspirációt.

  Témával foglalkozó cikkek is érdekelnek(angol nem akadály)

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