Segítség! Adatbázist tervezek

Most kezdek el összerakni egy böngészőben futó könyvelőprogramot. Ehhez tervezem az adatbázis szerkezetét. Elkelne ebben némi elvi segítség. Kérem SQL szakértők ne kíméljenek.

Két változaton rágódok és nem tudok dönteni. A két leegyszerűsített séma a kovetkező.

“A” változat:

Egy tábla a cegek: id, ceg
Egy tábla a kodok: id, ceg_id, kod
Egy tábla a tetelek: id, kod, datum, osszeg, stb

Ez ugye egy átlagos, normailzált séma.

“B” változat:

Ennél a változatnál az “A” séma ismétlődne cégenként és évenként.
ceg1_2008_kodok: id, kod
ceg1_2008_tetelek: id, kod, datum, osszeg
ceg2_2008_kodok: id, kod
ceg2_2008_tetelek: id, kod, datum, osszeg

Ez viszont egy normalizálatlan séma.

A normalizált sémának nyilvánvaló előnyei vannak, erről nem akarok írni, úgyis mindenki tudja. Viszont van pár olyan dolog amiben a normalizálatlan verzió kap plusz pontokat.

Hordozhatóság
könnyeden leválasztható az AB-ból egy cég egy éve, könnyű cégenkénti mentést csinálni.
Adatbiztonság
Ha az egyik cég egyik táblája megsérül akkor a többi cég könyvelése nyugodtan tud tovább menni, a hiba nem befolyásolja a többieket.

Egyenlőre eddig jutottam a gondolkodásban. Bárminemű ötletet, javaslatot, tapasztalatot szívesen fogadok.

14 thoughts on “Segítség! Adatbázist tervezek

  1. 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. 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. Ü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. 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. 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. 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. 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.

  8. 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 🙂

  9. 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á 🙂

  10. é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.

  11. “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.

  12. É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.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.