Többszempontos tábla létrehozása

Többszempontos tábla létrehozása
2007-04-30T11:33:50+02:00
2007-05-05T09:44:33+02:00
2022-10-30T12:55:33+01:00
  • ha egy táblából lekérdezem az miért lassabb

    1. Ne a lekérdezés idejét nézd, hanem azt, hogy a user megnyomja az OK gombot és megkapja az eredményt.
    2. Ha kódokkal jelölöd szöveg helyett a szöveges adatokat akkor maga a lekérdezés gyorsabb mintha még másik 2 táblával összekötöd. Ellenben ha szövegként tárolod és teszel egy feltételt a lekérdezésbe akkor már koránt sem biztos, hisz
    - megnő a tábla mérete ezáltal többet kell wino-t kergetni és memóriát lapozni
    - lasabb az összehasonlítás (méghozzá nem is kevéssel) mint a számok esetében.
    3. A tied egy viszonylag egyszerű szerkezet, itt nem feltétlen jön elő a probléma, de ha mondjuk egy számlázó rendszerre gondolsz amit egy táblában szeretnél megoldani, akkor már érdekes eredmények fognak születni.

    Én annál a gyerekes(?) módszernél ragadtam le, hogy az Excel táblát mentem weblapként

    Ez a gond. Ne akard az Excel-t 1-1-ben átültetni SQL-re.
    Két teljesen külön világ.
    Mutasd a teljes hozzászólást!
  • Szerintem gyorsabb a keresés/megjelenítés, ha már eleve tárolva van, pl. a bevételek és kiadások összesenje
    ...
    ...
    Lekérdezni igen. És módosítani egy adatot?


    Amikor módosítok egy értéket, ezzel párhuzamosan módosítom az összesent is! Vagy ez nagy hülyeség?

    Amikor ERP-ről tanultam, akkor vetődött fel bennem a kérdés, hogy készítenek főkönyvi kivonatot? Végigmennek az idősoros könyvelés adattábláján gyűjtögetve a főkönyvi számlákat, majd az értékeiket? Képzeld el mondjuk egy céget, ahol 30.000 könyvelési tétel van egy évben és 300 számla. 300*30.000, azaz 9.000.000-szor fut le a ciklus, és csak 1 oldalt néztünk(pl. tartozik). Ezért gondoltam, hogy lehetne a főkönyvi számok tábláján már eleve összegezni a tartozik-követel forgalmat! Ez megint csak redundáns, ha az előző az volt, de gyorsabb, ha csak 1 táblán fut végig. Nem?
    Mutasd a teljes hozzászólást!

  • Szerintem gyorsabb a keresés/megjelenítés, ha már eleve tárolva van, pl. a bevételek és kiadások összesenje, amiből az arányukat is ki lehet számolni (ha már felhoztad)! Egyébként ez egy külön Excel tábla, azért nem is írtam erről.


    Akkor már van 2 táblád és nem egy. View-ról nem hallottál véletlenül?


    Erről írtam az előző hozzászolásaim egyikében: letárolom a részleg kódját, de csak én tudom, hogy mit takart! Kiolvasásnál pedig a kód mutatná, melyik oszlopba és sorba kell helyezni az adatot, azaz hogy jelenjen meg a felhasználó képernyőjén!


    És ha te elmész a cégtől? :D Vagy így biztosítod be magadat, hogy csak te tudod, hogy az a szám mit jelent?
    Hmm. Remélem kapsz egy 5x-es fizetési ajánlatot egy másik cégtől, de nem mehetsz el, mert csak te tudod, hogy az adott kód mit jelent.
    Talán egy másik táblában el kéne tárolni, hogy a kódok mit is jelentenek és kész.

    Ajaj már megint van 1 táblád

    Ez már 3 db tábla. (Nah jó az egyik csak view.)

    Értékesítés?

    Én csak példának hoztam fel.
    De talán jó lenne elővenned egy könyvelőtől egy számlatükröt.
    Abban megfelelő bontásban el tudsz mindent számolni. Ha nem, akkor irány a pénzügyminisztérium :)

    Szóval a relációs adatbázis nagy előnye, hogy jól bővíthető az esetek nagy részében.

    Jön egy új üzem, jön egy új adónem, jön egy új értékesítési forma? Honnan tudod, hogy a jövőben nem lesz ilyen?

    Mutasd a teljes hozzászólást!
  • A kiliens oldalon (mondjuk php-ben) összeállítod a táblázatot. Szerinted mennyivel lesz ez így gyorsabb?


    Fogalmam sincs. De akkor sem értem, hogy ha egy táblából lekérdezem az miért lassabb, mintha 1 táblából az értékeket, 1 táblából a oszlopokat(részleg) és 1 táblából a sorokat (tevékenység), azaz összesen 3 táblából kérdezem le!

    Ezen felül: user egy év múlva csak annyit kér, hogy jó-jó, de ide szúrjunk be még egy sort/oszlopot.
    Mit csinálsz? Hogy kezeled le?


    Én annál a gyerekes(?) módszernél ragadtam le, hogy az Excel táblát mentem weblapként. Tehát a tábla fix. Ezek után érthető, hogy miért nem foglalkozom ezzel, gondolom.
    Mutasd a teljes hozzászólást!
  • Örülök, hogy felhoztad a redundanciát! Sosem tudtam, hogy redundánsnak számít-e, ha letárolom "A", "B" és "C" különböző adatokat, miközben C=A+B! Ez redundancia?

    Igen. Ezért nem tároljuk C-t, csak ha optimalizálni (denormalizálni) akarunk, de nagyon körültekintően és óvatosan kell eljárni.

    Szerintem gyorsabb a keresés/megjelenítés, ha már eleve tárolva van, pl. a bevételek és kiadások összesenje

    Lekérdezni igen. És módosítani egy adatot?

    Ha nagyon nagy mennyiségű adat van akkor egy külön report szervert/adatbázist kell beállítani ahol felösszegezheted az adatokat a reportoláshoz olyan szintig ameddig az érdekel (lsd. OLAP kockák).
    Mutasd a teljes hozzászólást!
  • Fogd meg az adatszerkezet lényegét és fiktív adatokkal (lehetőleg egyszerűsítve, amennyire lehet, hszen a többieknek ezt meg is kell érteni és nem biztos hogy korlátlan időt szánnak rá!) mutass egy néhány soros minta adattáblát.


    Bár több sorból és oszlopból áll, de lásd feljebb!

    Egyébként (kevéssé megfigyelve a feladatod), az oszlop1, oszlop2... mezőnevekbe belekapaszkodva ez a "módszer" csak nagyon indokolt (nélkülözhetetlen optimalizálás) esetekben célszerű.


    Ez már lejárt lemez, már túlléptem rajta. Most azon vitatkozunk, hogy több tálában legyen vagy egy táblában, mégpedig ezekkel a mezőnevekkel:

    ügyfél_id
    időszak
    sor_megnevezés (bev, kiad)
    oszlop_megnevezés (részleg)
    érték

    Ez tűnik elsőre bonyolultnak, de hamar kiderül, hogy egy erőltetett (vagyis nem normalizált) adatszerkezettel jóval több gondod lesz a jövőben


    Na ezt várnám: egy értelmes kritikát! Igen, kezdek elbizonytalanodni a saját álláspontommal kapcsolatban...
    Mutasd a teljes hozzászólást!
  • A másik pedig, hogy hasonlóan képzelem, de egy táblába: lenne hely_id (talán nem ilyen néven), viszont nincs hely tábla!!!

    Tételezzük fel, hogy megvalósítod. Mit is fogsz ezután tenni?
    A kiliens oldalon (mondjuk php-ben) összeállítod a táblázatot. Szerinted mennyivel lesz ez így gyorsabb?
    Ezen felül: user egy év múlva csak annyit kér, hogy jó-jó, de ide szúrjunk be még egy sort/oszlopot.
    Mit csinálsz? Hogy kezeled le?
    Mutasd a teljes hozzászólást!
  • Ez a pontos feladat, csak a megnevezések és adatok mások, mert nem akarok ügyféltitkokat leírni! Ez, gondolom, érthető!


    Senki nem kiváncsi a "titkaidra".

    Fogd meg az adatszerkezet lényegét és fiktív adatokkal (lehetőleg egyszerűsítve, amennyire lehet, hszen a többieknek ezt meg is kell érteni és nem biztos hogy korlátlan időt szánnak rá!) mutass egy néhány soros minta adattáblát.

    Csak ezután várhatsz el segítséget

    Egyébként (kevéssé megfigyelve a feladatod), az oszlop1, oszlop2... mezőnevekbe belekapaszkodva ez a "módszer" csak nagyon indokolt (nélkülözhetetlen optimalizálás) esetekben célszerű.

    Ne félj a relációktól, tipikusan a több tábla és a left outer join használata a célravezető (az analitikus adattáblához, mint alaphoz, hozzácsatolod a hivatkozás kulcsok feloldásait).
    Ez tűnik elsőre bonyolultnak, de hamar kiderül, hogy egy erőltetett (vagyis nem normalizált) adatszerkezettel jóval több gondod lesz a jövőben

    eMeL

    Mutasd a teljes hozzászólást!
  • A relációs adatbáziskezelés lényege, hogy az adatokat táblákba szervezzük és a táblák között kulcsokkal összefüggéseket hozunk létre, illetve a normalizálás folyamán 1 adat csak 1 helyen legyen eltárolva elkerülendő a redundanciát. (Most az elosztott adatbázisokat hagyjuk!)

    A te verzióddal az a baj, hogy a megfelelő adatmódosításokat és főleg a kereséseket nehéz megcsinálni.

    Pl a január havi bevételek és kiadások aránya. Minden egyes hónapra fogod a függvényeket másolgatni?


    Örülök, hogy felhoztad a redundanciát! Sosem tudtam, hogy redundánsnak számít-e, ha letárolom "A", "B" és "C" különböző adatokat, miközben C=A+B! Ez redundancia?
    Szerintem gyorsabb a keresés/megjelenítés, ha már eleve tárolva van, pl. a bevételek és kiadások összesenje, amiből az arányukat is ki lehet számolni (ha már felhoztad)! Egyébként ez egy külön Excel tábla, azért nem is írtam erről.

    Egyébként a sebesség kedvéért. Hozz létre 2 táblát.

    hely_id: 1,2,3,4,5
    hely_nev: Budapest, Győr, Szeged, Szekszárd, Gyömrő

    és generálj egy 1 millió rekordos táblát.

    id: 1,2,....
    értékesítés: x Ft, y Ft, ....
    hely_id: 1,2,....

    Majd keresd ki a győri adatokat sql-el. Aztán helyettesítsd be a hely_id helyére a Budapest, Győr etc string-eket és utána is nézd meg. Azért nem mindegy, hogy sztringet hasonlítasz vagy számot, főleg ha az eleje megegyezik a szövegnek.


    Két baj van a példáddal: az egyik, hogy a tevékenységek(Excelben a sorok) is különbözőek (nem csak értékesítés van, és különben is, melyik értékesítés?), tehát ezt ilyen formában nem lehet letárolni!
    A másik pedig, hogy hasonlóan képzelem, de egy táblába: lenne hely_id (talán nem ilyen néven), viszont nincs hely tábla!!! Erről írtam az előző hozzászolásaim egyikében: letárolom a részleg kódját, de csak én tudom, hogy mit takart! Kiolvasásnál pedig a kód mutatná, melyik oszlopba és sorba kell helyezni az adatot, azaz hogy jelenjen meg a felhasználó képernyőjén!

    Nem azt mondtam, hogy Excel-ből csinálj weblapot, hanem weblapból csinálj excelt

    PHP-ből a mysql-es adatbázisból csinálsz egy excel fájt olvasásra! (Megfelelő header küldéssel megoldható.)


    Nem írtam, hogy Te mondtad. Én közöltem, hogy arra gondoltam, nem kellene a weblap szerkezetével és a dizájnnal foglalkozni, hanem egyszerüen lementem az Excelt weblapként és ehhez írom meg a PHP kódot! De átgondolom, amit írtál (PHP, MySQL -> Excel)!
    Mutasd a teljes hozzászólást!
  • Hmm. Tanultál adatbáziskezelést?

    Akkor meg végképp nem értem.

    A relációs adatbáziskezelés lényege, hogy az adatokat táblákba szervezzük és a táblák között kulcsokkal összefüggéseket hozunk létre, illetve a normalizálás folyamán 1 adat csak 1 helyen legyen eltárolva elkerülendő a redundanciát. (Most az elosztott adatbázisokat hagyjuk!)

    A te verzióddal az a baj, hogy a megfelelő adatmódosításokat és főleg a kereséseket nehéz megcsinálni.

    Pl a január havi bevételek és kiadások aránya. Minden egyes hónapra fogod a függvényeket másolgatni?

    A sebesség egyáltalán nem a táblák számától függ.
    Sokkal inkább, hogy mennyi a lekérdezésék és az adatmódosítások aránya, és melyik oszlopban keresel leginkább, melyikre teszel index-et a gyorsabb keresés érdekében.

    Web-es kezelés lassú? Ha kevés diszítés, képek stb. nincs benne, akkor viszonylag gyors, meg jól kell megszervezni és nem 1 oldalra 6000 sort kirakni.
    Az tényleg lassú.

    Egyébként a sebesség kedvéért. Hozz létre 2 táblát.

    hely_id: 1,2,3,4,5
    hely_nev: Budapest, Győr, Szeged, Szekszárd, Gyömrő

    és generálj egy 1 millió rekordos táblát.

    id: 1,2,....
    értékesítés: x Ft, y Ft, ....
    hely_id: 1,2,....

    Majd keresd ki a győri adatokat sql-el. Aztán helyettesítsd be a hely_id helyére a Budapest, Győr etc string-eket és utána is nézd meg. Azért nem mindegy, hogy sztringet hasonlítasz vagy számot, főleg ha az eleje megegyezik a szövegnek.



    Na, ha eddig nem kapaszkodtál meg, akkor most kapaszkodj: pont arra gondoltam, hogy az Excelből csinálok weblapot, ehhez jön a PHP, meg az adattábla!


    Nem azt mondtam, hogy Excel-ből csinálj weblapot, hanem weblapból csinálj excelt

    PHP-ből a mysql-es adatbázisból csinálsz egy excel fájt olvasásra! (Megfelelő header küldéssel megoldható.)
    Mutasd a teljes hozzászólást!
  • Az a baj, hogy általánosságban szeretnéd megvitatni, de így nem lehet kritizálni, vitázni.
    A pontos feladat ismeretében ki lehet fejteni, hogy mi a legjobb út, vagy épp mi a legoptimálisabb.


    Ez a pontos feladat, csak a megnevezések és adatok mások, mert nem akarok ügyféltitkokat leírni! Ez, gondolom, érthető!

    De azon, hogy "ha beledöglök is egy tábla" vagy "ha kell akkor több tábla" nem lehet érdemi vitát folytatni.


    Nem értem. De azért nem kellene túlzásokba esni! Egy biztos: előbb-utóbb felteszik a kérdést, miért nyitottam a topicot, ha nincs min vitázni. Pedig van: egy tábla vs. több tábla!

    Egy webes progi sebessége nem azon múlik, hogy hány tábla van az adatbázisban, hanem azon, hogy mennyire optimális az adatszerkezet és mennyi adat van. (Egyetlen táblával egy bonyolult adatszerkezet biztos, hogy nem optimális.)


    Ha több táblából nyerjük ki az adatokat az gyorsabb, mint ha egy táblát olvasna csak a program? Nehezen hiszem el.

    És honnan tudná? Beégeted a kódba?
    Nem ésszerűbb akkor egy táblában eltárolni?


    Még mielőtt kikiáltanátok, hogy olaci a világ legnagyobb hülyéje, megjegyezném, hogy tanultam adatbázis-kezelést és teljesen logikusnak tartom, amit írsz. De én nem így értettem a "kódba égetést". Mivel csak megjeleníteni kell az adatokat, ezért a képernyőn a megfelelő rublikába kerül az adat, amit a táblából olvasna ki. Maga a sor/oszlop megnevezése van a kódban. pl. 101 110 azt jelentené, hogy a táblában (a képernyőn) az érték jelenjen meg a Budapesti részleg oszlop és készletértékesítés sorban!

    Tehát hiába logikus, amiket írtok, még mindig nem győztetek meg.
    Mutasd a teljes hozzászólást!
  • Az a baj, hogy általánosságban szeretnéd megvitatni, de így nem lehet kritizálni, vitázni.
    A pontos feladat ismeretében ki lehet fejteni, hogy mi a legjobb út, vagy épp mi a legoptimálisabb.
    De azon, hogy "ha beledöglök is egy tábla" vagy "ha kell akkor több tábla" nem lehet érdemi vitát folytatni.

    Egy webes progi sebessége nem azon múlik, hogy hány tábla van az adatbázisban, hanem azon, hogy mennyire optimális az adatszerkezet és mennyi adat van. (Egyetlen táblával egy bonyolult adatszerkezet biztos, hogy nem optimális.)


    Lekérdezésnél a program tudná, hogy 101=Budapesti részleg

    És honnan tudná? Beégeted a kódba?
    Nem ésszerűbb akkor egy táblában eltárolni?
    Mutasd a teljes hozzászólást!
  • Tulajdonképpen lásd az előző hozzászólásomat! Hol a valódi kritika, a magyarázat, hogy miért totál hülyeség, amit írtam! Nem működne?

    Van egy excel táblád amiben vannak adatok, ez nagyon szép és nagyon jó, akkor mi a gond, ha neked 1 táblás megoldás kell?


    Nos, amit még nem írtam: nem csak adminisztátorok töltik a táblát, hanem maguk a részlegek is. Ez azt jelenti, hogy bár nem rossz így sem, és nem is életbevágó a feladat(!), de jelen pillanatban e-mailben egymásnak küldözgetik az Excel táblát a részlegek és a központ! Na ebből lehetne egy webes változatot készíteni, de persze kell ehhez adattábla is! Na, gondolom, már érthető, miért nyitottam a topicot. Vagy még mindig nem?

    A formátuma nyugodtan lehet az amit a hozzászólásodban láttam. Akár .xls-t is generálhatsz.


    Na, ha eddig nem kapaszkodtál meg, akkor most kapaszkodj: pont arra gondoltam, hogy az Excelből csinálok weblapot, ehhez jön a PHP, meg az adattábla! Így nem kellene foglalkoznom a dizájnnal és a felhasználóknak sem kellene nagyon elveszniük a "rendszerben", mert már ismerik! Vagy most egyik hülyeségből a másikba ugrottam?

    Esetleg valami nem tetszik nekik, akkor egy formot is generálhatsz, amiből visszafejted, hogy hogyan is kéne az adatbázist módosítani, hogy az jó legyen, de ez gyanítom meghaladják a képességeid!


    Meg. De a problémád megértése és nem a kivitelezés

    Legyen tehát egy adatmodelled (adatbázisod), amihez a programod nyúl hozzá, és legyen egy felület, amihez a megrendelőd hozzáférhet. Neki nem kell az adatbázisban turkálnia.


    De jó, hogy ezt leírtad, így legalább nem halok meg hülyén

    Ha csak ezért akarod az 1 táblát, akkor inkább lebeszéllek róla.


    Sajnos vannak tapasztalataim a webalapú programokról. Sokszor a beteg csiga gyorsabb náluk. Ezért szeretném, hogy minél kevesebb táblában turkáljon a program, mert ez is csak lassítja a működést!
    Mutasd a teljes hozzászólást!
  • Azért nyitottam ezt a topicot, hogy megvitassuk, és hátha ötletet kapok! Nem mondom, hogy nem fogadom el a többtáblás verziót! Az viszont zavar, hogy a sértegetésen kívül semmi épkézláb kritikát nem kaptam a megoldásommal kapcsolatban!
    Mutasd a teljes hozzászólást!
  • Egy Tábla mind felett, egy Tábla kegyetlen,
    Egy ami a sötétbe zár, bilincs az Egyetlen!


    Mutasd a teljes hozzászólást!
  • Ehh, némi idiótaságot vélek felfedezni a leírásodban.

    Talán jó lenne szétszedni, hogy mi a jó édes francot akarsz (már bocsi a kifejezésért)!

    Van egy excel táblád amiben vannak adatok, ez nagyon szép és nagyon jó, akkor mi a gond, ha neked 1 táblás megoldás kell?

    Vagy pedig te az adatokat szépen átpakolod egy mysql adatbázisba, rendesen normalizálva az adatokat, és azt az adatbázist használod.
    A főnökséget ebből a részből inkább hagyd ki.
    Ha nekik kell valami kimutatás, akkor a mysql adatbázisból generálj nekik egyet! A formátuma nyugodtan lehet az amit a hozzászólásodban láttam. Akár .xls-t is generálhatsz. Esetleg valami nem tetszik nekik, akkor egy formot is generálhatsz, amiből visszafejted, hogy hogyan is kéne az adatbázist módosítani, hogy az jó legyen, de ez gyanítom meghaladják a képességeid!

    Legyen tehát egy adatmodelled (adatbázisod), amihez a programod nyúl hozzá, és legyen egy felület, amihez a megrendelőd hozzáférhet. Neki nem kell az adatbázisban turkálnia. Ha csak ezért akarod az 1 táblát, akkor inkább lebeszéllek róla.
    Mutasd a teljes hozzászólást!
  • szerintem ezt a munkát adjátok ki egy hozzáértő embernek, jó pénzért, mert ez neked nagyon nem megy, semmi rálátásod a dolgokra, csak a begyöpösödött egy tábla nótádat fújod
    Mutasd a teljes hozzászólást!
  • Vagy ha te is így tervezted akkor mi a kérdés?


    Ez. Mármint, hogy vitassuk meg a dolgokat Tehát azon a véleményen vagy, hogy sok helyet foglalnak.

    esetleg plusz egy/két tábla, hogy ki melyik oszlopot/sort használhatja


    Na ezért (is) akartam minél kevesebb (lehetőleg 1) táblát, mert hogy majd ezek is kellenének.

    Egyébként nem tudom, hogy mennyire alaposan olvastad el az eddigi hozzászólásaimat? Ugyanis egy Excel táblát kell átültetni. Ráadásul ez csak, hogy is mondjam, illetve írjam , egyfajta szemléltetés a vezetőségnek.

    Tehát visszatérve a helyfoglaláshoz: mivel ez csak egy "szemléltetés", ezért arra gondoltam, hogy nem igazán tárolnák "semmit" (arra van külön rendszer, ha annyira kell nekik). Ezalatt azt értem, hogy mondok egy számot, pl. 101, és ez lesz Budapest. Lekérdezésnél a program tudná, hogy 101=Budapesti részleg. Ez azt jelenti, hogy nem a "Budapesti részleg" kifejezést tárolnám, mert akkor valóban sok helyett foglalna. Az, hogy a kódot csak én értem, az meg tökmindegy. Vagy nem?
    Mutasd a teljes hozzászólást!
  • Bocs.
    Így annyira nem gáz, csak rengeteg helyet foglal feleslegesen (nincs normalizálva): lefoglalsz egy varchar(50)-et a típusna és egyet a részlegnek. Ez 100 byte.
    E helyett 2 integer (Micu javaslata alapján) 2*4=8 byte (és már ekkor is pocsékoltál, mert lehet, hogy elég összesen 2 byte).

    Ez rekordonként (gondolom pár ezerrel lehet számolni) majd 100byte azaz 10000 rekordnál 1MByte.
    Ha elkezded indexelni is, hogy gyors legyen a select akkor 2MByte
    Amikor visszakeresel valamit akkor egy 50 char hosszú sztringet hasonlítasz egy másikhoz, a helyett, hogy 2db 4 byteos számot hasonlítanál össze (gyakorlatilag egy processzor ciklus alatt).

    Ráadásul gondolom nem szabadkézzel írják a típusokat, tehát amúgy is el kell tárolnod valahová.
    Gondolom azt szintén eltárolod, hogy milyen részlegek vannak a cégnél.
    Akkor miért is nem lehet ezt összekötni integerrel?
    Vagy ha te is így tervezted akkor mi a kérdés?

    (esetleg plusz egy/két tábla, hogy ki melyik oszlopot/sort használhatja)
    Mutasd a teljes hozzászólást!
  • Csak gondolj bele mi van ha bejön a képbe még telephely? Felveszel egy új oszlopot?


    Hm. Egy kicsit később kapcsolódtál be! Szóval ez csak egy hasonló jellegű példa!

    Persze ekkor sem értem a fenti idézetet, amit kiemeltem az írásodból. Új telephely jön be, akkor új oszlop is kell? Nézd meg ezt:

    ügyfél_id
    időszak
    sor_megnevezés (bev, kiad)
    oszlop_megnevezés (részleg)
    érték

    Biztos, hogy kell új oszlop? Vagy eleve rossz a tábla, ha így adom meg?
    Mutasd a teljes hozzászólást!
  • Én 1 táblában szeretném megoldani az egészet, ha lehetséges.

    Lehetséges, csak semmi köze ennek a megoldásnak a relációs adatbáziskezeléshez.
    Csak gondolj bele mi van ha bejön a képbe még telephely? Felveszel egy új oszlopot?
    Mutasd a teljes hozzászólást!
  • Na ezért nem akartam ennyire a mélyre ásni (bár még nem vagyunk a legmélyén ), mert így már joggal bezárhatják a topicot, mondván: ez a tudástárba való. Pedig nekem csak az ötlet kellene, amin elindulok, a többit már én elintézem. Na mindegy.

    Én 1 táblában szeretném megoldani az egészet, ha lehetséges.

    Az előző hozzászólásomban már leírtam, hogy lehet olyan ügyfél, ahol egy bizonyos időszakban alig van adat a táblában, tehát sok a NULL érték.
    Mutasd a teljes hozzászólást!
  • Ez csak 1 példának szántam, hogy érzékeltessem, hogy néz ki szerkezetileg az Excel tábla. A kérdéseidre a válasz:

    1: az egyes részlegek száma kötött, vagy tetszőleges lehet?

    Kötött.
    2: az egyes "szempontok" (bár nevezzük inkább tételeknek) száma kötött vagy tetszőleges?

    Kötött.
    3: minden részlegnél van minden tétel kitöltve, vagy nem kötelező?

    Nagyon nem kötelező Elképzelhető, hogy a tábla 75%-a üres!
    Mutasd a teljes hozzászólást!
  • Nem tudom, nálatok hogy megy, de szerintem senki sem szereti, ha ügyféltitkokat adnak ki!


    Így.

    De ha elmész egy orvoshoz, akkor elvárhatod, hogy ha elmondod a gondod, akkor titokban tartja, pontos diagnózist kapsz.
    (Ha meghívsz a munkára, akkor ez a titoktartási nyilatkozat)

    De ha egy nyilvános forumon teszed fel a kérdést, akkor vagy nem mondod el a gondod, és akkor ne lepődj meg, hogy nem kapsz használható választ, vagy elmondod az információkat (pl. átírva a valós adatokat), és akkor van esélyed.

    1. tábla: részlegek (RészlegID, Nev)
    1, Bp
    2, Győr
    3, Szeged
    ...

    Ha több Cég van, akkor 0. tábla cégek és az 1-esben van egy CégID

    2. tábla: Indokok (IndokID, Megnevezes, tipus)
    1,Készletértékesítés, 1
    2,Eszközértékesítés, 1
    3, Szolgáltatások, 1
    4, Készletbeszerzés, -1
    5, Eszközbeszerzés, -1
    6, Rezsiköltségek, -1
    7, Egyéb kiadások, -1

    3. tábla
    RészlegID, IndokID, összeg 1, 1, 1000.000 3, 1, 250.000 2, 2, 350.000 // Győr eszközért. 1, 4, 800.000 // Bp, Készletbesz

    Ha az év.hó is érdekes, akkor azt is ide veszed fel.
    (Ez úgy kb a te 2. megoldásod)

    ----------------

    De ha ennyi az összes mező, akkor egyszerűbb 1 tábla
    Részleg, készletért., eszközért, ......

    Még akkor is, ha "sok" a null.

    De ez az adatmennyiségtől is függ. Ha pl. 50%-nál több a null, akkor érdemesebb, de macerásabb a több táblás.
    Ha 50% alatt van, akkor sokat nem nyersz a több táblával, csak több a munka.
    Mutasd a teljes hozzászólást!
  • 1: az egyes részlegek száma kötött, vagy tetszőleges lehet?
    2: az egyes "szempontok" (bár nevezzük inkább tételeknek) száma kötött vagy tetszőleges?
    3: minden részlegnél van minden tétel kitöltve, vagy nem kötelező?

    ha ezekre válaszolsz érdemben, sokkal közelebb jutunk a megoldáshoz...
    Mutasd a teljes hozzászólást!
  • OXY, Micu!

    Nem tudom, nálatok hogy megy, de szerintem senki sem szereti, ha ügyféltitkokat adnak ki!

    Azért próbálok írni egy példát, hátha világos lesz, bár ha eddig nem volt, ezután sem valószínű! Mindenesetre megkérek mindenkit, hogy ne a példába kössön bele, és ne szedje ízekre!

    Tehát a példa: Nemistudomhogyhívják Kft. 2007. januári bevételei és kiadásai, az egyes alegyeségek tekintetében.

    Excel címe: Nemistudomhogyhívják Kft., 2007. január

    ........................Budapesti részleg...Győri.....Szegedi
    Bevételek:
    Készletértékesítés.........1000.000....................250.000
    Eszközértékesítés..........................350.000.....120.000
    Szolgáltatások.............1250.000.......80.000

    Kiadások:
    Készletbeszerzés............800.000........230.000.....180.000
    Eszközbeszerzés.............450.000
    Rezsiköltségek..............320.000.........100.000.....100.000
    Egyéb kiadások..............120.000

    Tehát ezt értettem több szempont alatt. Nem jó, amit OXY írt, mert ott csak az oszlopokat tekinti mezőneveknek!!! Holott a sorokat, az ügyfeleket és az időszakot is figyelembe kell venni.

    Ezért írtam a példát, és kérdeztem, jó-e:

    ügyfél_id
    időszak
    sor_megnevezés
    oszlop1
    oszlop2
    ...
    oszlop10

    Nemrég jöttem rá, hogy talán mégsem jó, mert sok lehet a táblában a NULL érték. Talán inkább így kellene:

    ügyfél_id
    időszak
    sor_megnevezés
    oszlop_megnevezés
    érték

    Vagy így sem jó?
    Mutasd a teljes hozzászólást!
  • Persze írhatnád erre, hogy pl. php-vel is kezelhető az Excel, de mindenféle képpen adatbázis kellene, pl. MySQL.


    Nem értelek bazze... Csinálsz egy mysql táblát aminek ua. oszlopai vannak mint az excel tábládnak. Ezután szépen irsz egy import script-et. Googlezz rá a php excel reader kulcsszavakra! ;)
    Mutasd a teljes hozzászólást!
  • Ha már van a "tábládnak" (Excelnek) tartalma, akkor vegyél elő egy Access-t. Abba importáld be és mond meg az Access-nek, hogy analizálja a tartalmat.

    De ettől eltekintve QXY-nak igaza van. Tényleg nem mondtál semmi érdemlegeset.


    Én is szeretnék egy kertes házat, tudom kb, hogy hol, és hogy nézzen ki, valaki megtervezné?
    Persze kell fürdőszoba, konyha, ... szobák.
    Mutasd a teljes hozzászólást!
  • Miért? Ez esetben ott van az excel-es formátum, 1 tábla. :)


    Igen, de webes programot szeretnék csinálni. Persze írhatnád erre, hogy pl. php-vel is kezelhető az Excel, de mindenféle képpen adatbázis kellene, pl. MySQL.

    Akkor mégis hogyan vitassuk meg, ha mi azt sem tudjuk miről van szó?


    A tábla szerkezete kellene, nem a konkrét megoldás!Viccesen fogalmazva: hülye vagyok, de nem béna!
    Írtam egy példát is, azt lehet kritizálni. Vagy lehet más ötlet is.
    Mutasd a teljes hozzászólást!
  • Megvitatni akarom a dolgot és nem megoldást kérni.


    Ettől függetlenül rakhattad volna a tudástárba, egy jó ötlet is megérhet 50 pontot. Van erre megfelelő kategória szerintem, ha más nem a játékok és fejtörők! :D

    A tábla egy ügyfél egy időszakbeli adatait tartalmazza, mégpedig úgy, hogy az oszlopok és a sorok is különböző szempontokat tartalmaznak.


    Ez nulla információ! :)

    jó lenne, ha egy tábla lenne


    Miért? Ez esetben ott van az excel-es formátum, 1 tábla. :)

    Bocs, hogy ilyen rejtélyes vagyok, de nem akarom pontosan leírni a táblázat tulajdonságait.


    Akkor mégis hogyan vitassuk meg, ha mi azt sem tudjuk miről van szó?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd