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

• GreenIT tag

  #3496

  #3488 martonx

  2017-07-12 14:51:53

  Ú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

  

  GreenIT

  tag

  #3488 martonx

  #3488 martonx

  "A problema lenyege az, hogy ha van egy elvaras, hogy egy tablaba kell felvenni nehany adatot, de kiderul, hogy az adatok egy resze tobb mas adattol fugg, akkor mi legyen az eljaras?
  Legyinteni, hogy ha nektek ez kell, akkor legyen, vagy megprobalni egy jo megoldast kitalalni es meggyozni a feladatot adot, hogy van jobb megoldas?"

  Egyre kevésbé értelek. Eddig ezért sem szóltam hozzá a "kérdéseidhez". Életvezetési tanácsokat vársz itt az SQL topikban, vagy önmenedzselési tanácsokat, vagy szakmai tanácsokat konkrét szakmai kérdésekre? Mert nagyon nem mindegy. Ha beküldesz egy SQL fiddle-el megtámogatott query-t, hogy mit és hogyan kellene, abban simán segítünk. De az ilyen szintű kérdésekre, hogy vajon hogyan tároljam a ki tudja milyen adatot, mégis mit vársz tőlünk? A feladatot sem ismerjük, de valószínűleg a megismeréséhez is több óra kellene, ami simán meghaladja egy jószolgálati alapokon nyugvó topik segítőkészségének a határát.
  Életvezetési problémák megoldásához meg biztos, hogy nem ez a megfelelő topik, noha off-ban akár tudunk ez irányban is tanácsokat adni, de minek ide szemetelni?

  Szerintem roviden irtam, de a kedvedert zanzasitva ismet leirom, ha hosszunak talalod, aminek megertesehez par ora kell, lapozz le az utolso mondathoz, ott a kerdes lenyege.

  Ossze kell irnod a kapcsolataidat, gyorsan rajossz, hogy 2+x tablara van szukseged: NEV, CEG, es egyeb adatok - legyen csak cim es telefon az egyszeruseg kedveert - valamint datum es megjegyzes a valtozasok kovetesehez.
  Gyorsan rajossz, hogy a NEV-hez es CEG-hez is tobb, sot tobbfele cim tartozhat, majd arra is rajossz, hogy a telefonnal meg bonyolultabb a helyzet, az tartozhat a NEV-hez, CEG-hez, sot a NEV-hez tartozo cimekhez es a CEG-hez tartozo cimekhez is.

  Legalabb haromfele valasztasod van:
  1. A NEV-hez es CIM-hez is csinalsz tablakat kulon cimek es telefonok, valamint datum es megjegyzes mezokkel, es akkor a szemelyes es ceges adatok elvalnak egymastol, viszont tobb helyen lehet azonos adat.
  2. Csinalsz egy harmadik tablat ADATOK neven es mindent abba teszel, lehetoleg minden tipusnak kulon mezovel (allando es ideiglenes lakcim, postacim, szekhely, telephely, telefontipusok, stb.) datum es megjegyzes - ekkor az adatrogzitok orulnek, mert konnyen rogzitheto, hogy adott idopontban adott indokkal milyen valtozasok tortentek.
  3. Csinalsz egy harmadik tablat, amiben cim, cimtipus, telefon, teltipus, datum, megjegyzes mezok vannak, es akkor a tablak kozotti kapcsolatok jelentenek problemakat es lekerdezesek reven tudod kitalalni a helyzetet.

  Osszefoglalva: Az egyik modszer az adattarolas minimalizalasara, a masik az adatrogzites egyszerusegere, a harmadik az adatkapcsolatokra es lekerdezesekre fokuszal.

  Nekem eddig az elso kettot sugalltak, hogy a normalizalasnal alapveto szempont, hogy ne legyenek parhuzamos adatok, es az emberi tenyezo kikuszobolese miatt az adatrogzitesnek egyszerunek es atlathatonak kell lennie. (A programozo pedig azert van, hogy a lekerdezeseket megoldja, es amugy is lesznek kesobb ujabb igenyek meg bonyolultabb lekerdezesekre.)

  Egy programozo szerint ez mind marhasag, az adatrogzites egyszeri feladat, a lekerdezes viszont folyamatos, ezert mindent a lekerdezesekre kell tervezni.

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