JólMegMondjad!

14 vélemény

1. The Hedgehog
   2008 augusztus 16. 11:20:09

   Talán a normalizálatlant egyszerűsíthetnéd úgy, hogy nem bontod évekre. Kevesebb tábla, kevesebb kérés és ugyanolyan mobil, mint az előző változat.

   Egy ilyen szoftver esetében a terheltség nem lehet nagy gond, ugyanis jó esetben is egyszerre csak egy könyvelő böngészi az adatbázist és generál lekéréseket.

   Logikai szempontból a normalizált a szép megoldás, viszont ha én csinálnám akkor mindenképpen a “minden cég külön tábla” módszert alkalmaznám. Pontosan azért mert ez nem egy szokványos webes alkalmazás és a mobilitása is fontos.

2. sandokanu
   2008 augusztus 16. 11:54:04

   Tök mindegy melyiket választod, inkább lépj tovább a kimutatások részhez, mert ott kell sok adatot összeválogatni (Abból megtudod, melyiket is válaszd.), és annál a résznél bizony az agyon normalizált struktúrával van szívás (mire az adatokat lekéred).

   Javaslom hogy elsőként lásd át az egész rendszer, ne ragadj le ennél a résznél.

   Adatmentés: “Ha az egyik cég egyik táblája megsérül”
   Naponta x időnként lemented az adatbázis akár saját szempontjaid alapján (cégekre bontva), ebből vissza is lehet állítani (akár gyengébb képességű emberkéknek is).

   Ha valami elromlik úgy is neked kell megcsinálni, ne aggódj ezeken, ha csak nem kv automatát akarsz csinálni.

3. Varsányi Martina (xSolutions)
   2008 augusztus 16. 14:14:08

   Ülj le egy könyvelővel. Az évenkénti tábla szintű bontás nem jó, mert bizonyos korábbi évekből származó tételek későbbi években kerülnek könyvelésre. Célszerű az ügyfélen kívül egy saját könyvelővel történő egyeztetés is, egyrészt több szem többet lát, másrészt a hibás igényből eredő kellemetlenségekért még véletlenül se neked legyen bajod.

4. rrd
   2008 augusztus 16. 14:48:33

   Martina: Én vagyok a könyvelő és másodsorban programozó Az igények pedig elég egyértelműek az elmúlt évek tapasztalataiból. Egyébként meg persze már átbeszéltem a többi könyvelőmmel

5. Ronyn
   2008 augusztus 16. 15:58:03

   Szerintem inkább az A változat (hacsak nem akkora tètelszám várható,amitöl lassúlhatnak a lekérdezések,akkor is csak cégekre bontani).
   Az meg nem sok idöbe kerül csinálni egy olyan scriptet,ami tetszöleges szempontok alapján készit mentést.(Nálam egy hasonlo backupscript be is zippeli,és egy példányt automatice elküld adott gmail-os cimre)

6. __tom_
   2008 augusztus 16. 17:01:39

   hali,

   az “A”-n alapuló verzió jóval könnyebben menedzselhető, ha bekúszik vmi új mező. Ha mindenképpen szeretnél egy “B”-hez hasonló leválogatást is, arra meg ott vannak a view-k (én egy külön sémába raknám őket, mert gondolom itt azért fog generálódni egy pár tábla).

7. HTML Info
   2008 augusztus 16. 19:27:19

   Néhány offline könyvelőprogram ismeretében könnyű szívvel javasolhatom a redundanciát. Minden cégnek saját táblákat!

8. Varsányi Martina (xSolutions)
   2008 augusztus 18. 12:50:29

   rrd: akkor nem is értem miért gondoltál az évenkénti bontásra. Elvileg a cégenkénti bontás egyszerűbben megoldható, viszont összesített kimutatást (összes cégre) az is csak egyedileg létrehozott select-tel old meg.

   Én mindenkepp az A-t választanám, alá egy erős adatbázisszervert, és persze logikus felépítésű indexeket.

9. Fakabát
   2008 augusztus 18. 21:10:30

   Igényfüggő.
   Ha kevés cég vagy méginkább kevés adat, akkor az A verzíó, viszont ha sok adat lesz, akkor inkább cégenként külön tábla vagyis a B verzíó.

   Kicsibe jók a normalizált megoldások, de a büntetés sok adatnál bizony kell egy csepp kis redundancia és inkább a több táblába felosztogatás.

   Belefutottam én már olyanba, hogy írtam egy “hozzászolások” modult, ahova az elején éppeghogy írogattak az emberek. Eltelt 3 év és pikk-pakk belejöttek a srácok, jelenleg másfél milliónál tart a tábla rekordszáma. Még ha rommá is van indexelve egy ilyen tábla, akkor is egy durván 200mb-s filet kell a szervernek tekernie, hogy kiszedegesse belőle az adatokat. Nem túl egészséges ez már így, át is lett csinálva hülyén megfogalmazva “friss” és “archivum” táblákká a cucc, de ennél kicsit bonyolultabban persze.

   Szóval én azt vallom, igényfüggő hogyan csináljuk. Olyan ez mint az autógyártás. Ha a verda 180km/h-ra képes, akkor elég hozzá a normál fék is, hogy X méteren belül megálljon. De ha 300km/h-ra képes, akkor bizony már kerámiafék kell, hogy az X méteres határon belül legyünk. Mindkét fék megállítja a kocsit, de az egyik már kevés a igényeknek
   Ezt a példát most vonatkoztasd át X user Y időn belüli kiszolgálására

10. Varsányi Martina (xSolutions)
    2008 augusztus 20. 15:04:04

    Persze lehet alá komoly szervert is pakolni, és nem PC-n, mysql alatt file szinten futtatni az adatbázis.

    Több milliós adatoknál érdemesebb komolyabb adatbázisrendszerben gondolkozni, mind hardware, mint szoftver szinten (adatait raw formában tároló DB, szerver hardware, cluster stb). Több milliós adatoknál még pénz is lesz rá

11. mondat
    2008 augusztus 20. 18:22:06

    én egyértelműen A megoldást választanám. tegyük fel egy cég egy évi könyveléséhez használsz 4 táblát (pl. bizonylat fej, biz.tétel, folyószámla, számlatükör, a törzs jellegű adatokat nem kell évenként tárolni), egy könyvelőirodának lazán lehet 50 cége, ami ugye évente 200 táblát jelent. vért fogsz izzadni pl. ennél az igénynél: mutassuk ki, eddigi működésünk során melyik vevőnktől mennyi bevételünk származott, és ez egy egyszerű kérdés.
    azt meg tapasztból javaslom, hogy a numerikus sorazonosítók helyett – de mellett mindenképp – használj valami rendszerek között is (elméletben) egyedi azonosítót, pl. mysql uuid()-t. ezzel megmenekítheted magad a különbözö programok közötti adatátadás gyötrelmeinek egy jó részétől.

12. TubySmith
    2008 augusztus 25. 15:05:57

    “A” változat definiálva a lekérdezés view-eket hozzá a cégekhez. Egy könyvelő nem könyvel annyi céget, amitől egy MySQL meghasalna akár még PC localhost-on is.
    Több könyvelőnek meg nem kell egy adatbázisba dolgozni. szerintem.

13. deejayy
    2008 szeptember 12. 09:44:38

    Évekre semmiképpen nem bontanám. Cégekre is elég határeset, hiszen mi van, ha valamiért bővíteni szeretnéd az adatbázisszerkezetet, akkor minden cég esetében végig kellene játszani, esetleg scripteket írni a konverzióra.
    Ha mindenképpen a bontás mellett döntesz, akkor az éveket nem javaslom, hiszen egy cégnek szüksége lehet arra, hogy az elmúlt években hogyan alakultak a pénzügyi dolgai, de hogy a másik céghez képes hogyan, az nem is érdekelheti.

14. rrd
    2008 szeptember 12. 18:06:13

    Zárszóként: a normalizált változat nyert.