Firebird - Több adatbázis vagy egy?
2012-05-13T15:21:22+02:00
2012-05-21T18:57:11+02:00
2022-07-19T05:02:25+02:00
  • Valóban, ez több dologtól függ. Az is igaz, hogy nekem inkább kis- és középvállalkozásaim vannak.
    A lényeg viszont ugyanaz: Firebird esetén 1 adatbázisban célszerűbb megoldani a rendszert. Köszönöm mindenkinek a segítséget, amivel sikerült tisztáznom magamban, hogy pro és kontra melyik felé induljak el.
    Mutasd a teljes hozzászólást!
  • Beazonosítani adószám alapján fogja, ami rajta van a számlán. Az adószám alapján pedig a saját rendszerében már mindent megtalál. Elektronikusan nem kérnek többet.


    Dehogynem kérnek! Nagyon is gyakori, hogy a partnertörzsi adatokat összevetik a saját adatbázisukkal és ha mondjuk a cím adatok nem stimmelnek, akkor jön az a trükk, hogy az a számla nem is létező cégnek ment ki, szal a nekik fizetett áfával nem lehet csökkenteni a NAV-nak fizetendő áfát. Vagy csak keresik a számlagyárakat.

    A többit papíron kérték.


    A mi ügyfeleink többségénél kamionnal kéne jönniük, ha papíron szeretnének minden ilyen adatot, ezért inkább elektronikusan kérik el. Kisebb adózóknál folytatott vizsgálatnál lehet, hogy csak most kezedenek elektronikusan bekérni adatokat, de a kiemelt adózóknál már évek óta inkább az elektronikus forma dominál. Papír alapúakkal max egyeztetik a helyszínen az elektronikus dolgokat.
    Mutasd a teljes hozzászólást!
  • Mint idézted is, a papír alapú számlán van rajta az adószám.


    A vevő adószámát csak bizonyos esetekben kötelező feltüntetni a számlán (pl fordított adózás)!
    Mutasd a teljes hozzászólást!
  • Beazonosítani adószám alapján fogja, ami rajta van a számlán.
    Az ügyfél/vevő adószáma talán nem kell rajta legyen.


    Mint idézted is, a papír alapú számlán van rajta az adószám.
    Mutasd a teljes hozzászólást!
  • Beazonosítani adószám alapján fogja, ami rajta van a számlán

    Az ügyfél/vevő adószáma talán nem kell rajta legyen.
    Az adószám alapján pedig a saját rendszerében már mindent megtalál.

    Igen, ez úgy jellemző rájuk.
    Mutasd a teljes hozzászólást!
  • Én inkább az 1db-s megoldás felé hajlok, de szvsz vannak érvek a több db-s megoldás mellett is. Pláne, ha egy kicsit elvonatkoztatunk és esetleg más db kezelőt választunk, aminél nincs gond egy instancián belüli db-k között kommunikációnak.
    Mutasd a teljes hozzászólást!
  • E_Pluribus_Unum írta:
    Vannak további forgatókönyvek is. Pl. jön NAV, rendőrség, etc... szerv hogy az adott cég ellen eljárás indult és adjam át nekik az adatokat. Ilyen esetben mit csinálsz, ha egy adatbázisban van benne az összes céged adata? Viszi a többi cég adatait is mert integrát a rendszer?

    Úgyhogy ne folytassuk úgy hogy én találtam ki Én ebben veled értek egyet.

    Én amúgy a több adatbázis mellett egyetlen használható érvet hallottam eddig. Ez pedig a méret. Nyilván több ügyfél nagyobb méretűvé duzzasztja az adatbázist. De ez sem függ egyenes arányban az ügyfelek számától. Inkább az ügyfelek számláinak számától. Mondjuk könyvelek a Tesconak és a 3 sarki közértesnek, akkor talán érdemes a Tescot külön tenni a méret miatt? De így is lesz egy nagyon nagy adatbázisom és egy nagyon pici (vagy 3 nagyon pici). Tehát igazából nem oszt nem szoroz, hogy most kiemeltem a 3 kis ügyfelem a nagy mellől, mert a nagy miatt már így is használható sebességűre kell optimalizálnom a kódom. Esetleg ha könyvelek a Tesconak és a madaras Tesconak is, akkor talán őket érdemes külön tenni. De valószínűleg ekkora cégek esetén nem lesz túl sok közös adat, így a szinkronizáció is értelmetlen. Két évente felvinni az ÁFA változását, szerintem nem lehet megterhelő annak, akinek éves szinten milliós mennyiségű bizonylatokat kell könyvelnie. Azonkívül más közös adatot nem igen tudok elképzelni.
    Mutasd a teljes hozzászólást!
  • Pl. beazonosítani az egyes partnereket, megnézni, hogy azok valós tevékenységet végeznek-e,

    Beazonosítani adószám alapján fogja, ami rajta van a számlán. Az adószám alapján pedig a saját rendszerében már mindent megtalál. Elektronikusan nem kérnek többet. Lehet, hogy az ügyfeleidnél ez történt, de nekem 20 év alatt elég volt az analitika. A többit papíron kérték. Az elektronikus is csak mostanában terjed NAV körökben.

    De azért örülök, hogy megerősíted, hogy 1 db elég.
    Mutasd a teljes hozzászólást!
  • Az ügyféladatbázist nem kéri el a szerv, mert nincs rá szükségük.


    De, kérhetik, mert van rá szükségük. Pl. beazonosítani az egyes partnereket, megnézni, hogy azok valós tevékenységet végeznek-e, kapott áfá-t befizették-e, stb. Számlák ebből a szempontból nem biztos, hogy jók, hiszen a számlán lévő adatok már nem biztos, hogy érvényesek.


    valamint mit kezd egy adatbázissal, amihez nincs programja


    Adat táblákat kérnek re, amelyeket a mezők ismeretében akár excel-ben is simán lehet kezelni.

    @nova76:
    Igen, erre én hivatkoztam lejjebb, de ez egy komoly érv volt a több adatbázis irányában.


    Ez minden, csak nem komoly érv. Alkalmazás / db szintű jogosultságokkal a feladat remekül megoldható 1db db használata esetén is.
    Mutasd a teljes hozzászólást!
  • Igen, erre én hivatkoztam lejjebb, de ez egy komoly érv volt a több adatbázis irányában.
    Mutasd a teljes hozzászólást!
  • Ha ki akarom adni a cég adatait akár magának a cégnek, akár a SZERV-nek, akkor kiadom az összes cég összes ügyfelét?

    Nem. Az ügyféladatbázist nem kéri el a szerv, mert nincs rá szükségük. Kérhet pl. vevő/szállító analitikát, amiben benne van az ügyfél neve és kész. Több infót nem kérnek, mivel a számviteli/adó trv. ezt írja elő. Az ügyfélnek se kell kiadni, mivel szintén nem kérheti, mert többnyire nem erről szól a megállapodás, valamint mit kezd egy adatbázissal, amihez nincs programja?
    Sok év alatt nálam nem volt ilyen, illetve ha szükséges, akkor lehet egy szűrést készíteni, ami csak az adott cég által használt ügyfelek adatait gyűjti le és meg van oldva a probléma
    Mutasd a teljes hozzászólást!
  • Ezt nem is értem. Közös ügyféltörzs? Akkor pont a lényeg sérül. Ha ki akarom adni a cég adatait akár magának a cégnek, akár a SZERV-nek, akkor kiadom az összes cég összes ügyfelét? Persze én ezzel a külön adatbázissal az elejétől fogva nem értek egyet, és senkinek semmi köze a programhoz és a tárolt adatokhoz. Ha valakinek joga van elkérni adatokat, akkor csak azt amihez joga van, és nem ám az egész adatbázist.

    az adatbázis motorral az automatikus szinkronizálás
    Erről egyáltalán nem beszélhetünk, hiszen elképzelhető hogy épp valaki hazavitte Tehát valami magic metódus kell, ami ezt a problémát utólag feloldja.

    Amúgy ha elérhetőek lennének az adatbázisok, akkor akár egy udf-et is írhatsz rá. Valamikor évekkel ezelőtt én is írtam egyet, ami több telephely esetén rögzítéskor lekért egy közös adatbázisból egy új id-t egy webes felületről. Borzalmas volt, de ott nem volt más megoldás, akkoriban még telefonon keresztül mentek a dolgok, manapság viszont egy VPN és egyetlen adatbázis lényegesen leegyszerűsíti ezt a problémát. A VPN megoldás arra is, ha valaki otthonról akar dolgozni mondjuk GYES-en. Ahelyett hogy leprogramoznánk a csillagos eget, talán tekintsünk fel az égre...
    Mutasd a teljes hozzászólást!
  • Én is a több adatbázis felé hajlanék, de sajnos a FB adatbázisok közötti kapcsolati hiányosságai miatt nehezen oldhatók meg bizonyos dolgok.
    Az pedig, hogy a közös adatokat minden cég adatbázisában redundánsan tároljam úgy, hogy nem megoldható az adatbázis motorral az automatikus szinkronizálás, az kész rémálomnak tűnik. Az adatpocséklásról nem is beszélve. Pl. közös ügyféltörzs esetén ahány cég, annyiszor vannak letárolva az ügyféltáblák és ezeket egy-egy javítás vagy felvitel után szinkronba hozni kissé érdekes. Pl. az egyik cégben felviszik Kiss Jánost, majd elkezdi szinkronizálni a többi adatbázisban úgy, hogy elkerülje, hogy közben mások is elkezdjenek felvinni egy másik ügyfelet azonos azonosítóval. Háááát...
    Mutasd a teljes hozzászólást!
  • A "kell"-ekkel kicsit óvatosan célszerű bánni, ritkán olyan egyértelmű a dolog, mint amilyennek hinni szokták!

    Előnyök:
    - az adatintegritás így (is) megőrizhető


    Speciel ez nem előny, max nem hátrány.


    Eddigi tapasztalataim szerint 100 ügyfélre vetítve évente egy-nél javíthatatlan lesz az FDB winyó hiba miatt


    Lehet, hogy más vinyókat kéne használni.

    többmagos processzoroknál picit könnyebb a terhelés-szétosztás


    Ezt valamivel alá tudod támasztani? Mert a legtöbb esetben ez a db kezelőn úgy általánoságban múlik és nem azon, hogy most egy db van-e vagy több.


    kisebb a programozási-tévesztés (szűkítés)


    Miért lenne?

    - könnyebb az ügyfél-hiba-visszakeresés:
    Pl.: ha felhívnak, hogy a Kukutyim Kft-nél "ez és ez" a jelenség, akkor visszakérdezel, hogy más cégnél is ugyanezt csinálja ?


    Egy adatbázis esetén fel sem merülhet, hogy Kukutyim Kft-nél olyan hiba lép fel db miatt, ami más cégeknél nem.

    Szal, vannak érvek pro és kontra, mindenki dönthet saját belátása szerint.
    Mutasd a teljes hozzászólást!
  • Egyetértek E_Pluribus_Unum 2012.05.14. 13:58 összefoglalásával.

    Elmélet ide vagy oda, a praktikus megvalósítás szempontjából:
    - kell 1 db központi adatbázis,
    - kell minden céghez 1-1 adatbázis
    - és igen, "sajnos" érdemes a központiban tárolt adatokból az adott cégre vonatkozóakat "duplán" letárolni, és azokat a központival szinkronizálni.

    Előnyök:
    - az adatintegritás így (is) megőrizhető

    - adatbázis sérülés esetén (merthogy ilyen IGENIS VAN ! ) alapesetben csak 1 cég adatait kell visszaállítani a tegnapi mentésből, és egy nagyobb irodánál ez, bevallás határideje előtt nagyon nem mindegy, hogy minden alkalmazott összes munkája ugrott, vagy csak 1 céget kell újracsinálni.
    (Eddigi tapasztalataim szerint 100 ügyfélre vetítve évente egy-nél javíthatatlan lesz az FDB winyó hiba miatt.)

    - többmagos processzoroknál picit könnyebb a terhelés-szétosztás

    - kisebb a programozási-tévesztés (szűkítés)

    - gyorsabbak a lekérdezések

    - könnyebben átvihető egy-egy cég egy másik környezetbe
    (Pl.: GYES-re megy az egyik könyvelő, és otthon akarja csak azt a 3 céget csinálni, a többi 40 marad az irodában)
    - biztonsági mentések mérete minimalizálódik
    (az inaktív cégek differenciál mentés esetén nem foglalnak plusz helyet, ráadásul nem is kell az EGÉSZET menteni, csak ami változott, ami persze a központiban nyilvántartódik)
    - a mentések között lehet "szünetet" tartani, így tehát nem "akad le" a gép fél órára.
    - internetes FTP-feltöltés esetén ez nagyon fontos.
    (gyors hibajavítás, stb.)
    - könnyebb az ügyfél-hiba-visszakeresés:
    Pl.: ha felhívnak, hogy a Kukutyim Kft-nél "ez és ez" a jelenség, akkor visszakérdezel, hogy más cégnél is ugyanezt csinálja ?

    Igazándiból a nagy kérdés az, hogy jövőre kötelező lesz az "havi-analítikus" elszámolás, (vagy miafene) minden cégnél. De melyik program lesz majd erre képes ?
    Úgyhogy erre nyitok is gyorsan egy külön topic-ot.
    Mutasd a teljes hozzászólást!
  • Nyitottam egy külön témát erre --utólagos engedelmeddel --, mert ez egy önálló elvi kérdés, ami csak félrevinné a témádat.

    "PRO/CON generátorok száma"
    Mutasd a teljes hozzászólást!
  • Az eddigiekből nekem az 1 adatbázisos megoldás tűnik a jobbnak, annak ellenére, hogy a korábbi Clipperes/Harbour-os programjaimban külön könyvtárba pakoltam a cégeket. Persze SQL/Firebird alapon más szemlélettel kell gondolkozni, ezért is kérdezem a hozzáértőket.

    Ha lehet, nem nyitnék másik topikot a következő kérdésemnek:

    Mivel itt nincs RecNo() , ezért minden tábla elejére kell egy ID mező, amit generátorral töltök fel. A kérdés az, hogy elég egy adatbázisba 1 generátor erre a célra, vagy inkább minden táblához külön generátort hozzak létre? Vagy köztes megoldásként 1-1 generátort a táblák bizonyos csoportjaihoz?
    Mutasd a teljes hozzászólást!
  • "Mert egy külön adatbázisnál nem?"
    Nem mert, ha a tábla nevek fixek, akkor nem kell az összes SQL parancsot dinamikusan építgetni, és view/storedproc létrehozáskor kiderülnek a hibák, nem runtime jelentkezik a hiba először.

    "viszont nem tudsz hivatkozni egy másik adatbázisban lévő adatra." Ez már nem igaz, a 2.5-be lehet, igaz macerás.

    "Ezért a szinkronizációra fog elmenni a fejlesztési időd nagy része." Alapvetően nem írnék bele szinkronizációt, mert a több céget átfogó riport igény ritka mint a fehér holló. Egyedi igénkényt kell az ilyeneket lefejleszteni jó pénzért.

    "Nem hiszem hogy az nagy mennyiség egy Firebirdnek"
    Valóban nem nagy, a legnagyobb forgalmú cégünknél éves szinten most ~ 300K bizonylata van és (szumma ~ 2.5M bizoynlata jelenleg)
    gond nélkül ketyeg. Tesztként egyszer megtíszereztem ennek a bizonylatait és még azt is gond nélkül elvitte.

    "Szám szerint 1 forgalmi táblánál kell."
    Ez már szemléletbeli és business logic kérdés, erről nem érdemes vitatkozni.
    Mutasd a teljes hozzászólást!
  • Lehetséges hogy minden tábláról cégenként legyen egy másolat, de akkor a business logik kód horror lesz.

    Mert egy külön adatbázisnál nem? Egyébként pont a Firebird nagyon jó ebben. Még tárolt eljárásba is tehetsz Execute Statement utasítást, viszont nem tudsz hivatkozni egy másik adatbázisban lévő adatra. Ezért a szinkronizációra fog elmenni a fejlesztési időd nagy része. Ráadásul teljes jog kell az adatbázisokhoz. Létre kell tudnod hozni egy újat, módosítanod kell tudni a strukturát. Nem minden rendszergazda tűr meg ilyen rendszert.

    Éves szinten kb százezer bizonylatnál már határozottan érezni lehet
    Nem hiszem hogy az nagy mennyiség egy Firebirdnek vagy egy MySql-nek, és akkor a nagyobbakról már ne is beszéljünk. De tudod Te hogy 100e bizonylat az mekkora cég? Napi 300 számla hétvégén is. Aligha hiszem hogy labdába rúghat a kolléga egy olyan cégnél.

    OK nem az összesnél. De pont ott kell...
    Szám szerint 1 forgalmi táblánál kell. A bizonylat fej tábládban. Ezen kívül nyilván azokban a táblákban kell, ahol cégre vonatkozó alapadatokat tárolsz. Például főkönyvi számok összerendelése a szolgáltatás kódokkal. De ott sem csak olyan adatok lehetnek, amik egyetlen cégre vonatkoznak.
    Mutasd a teljes hozzászólást!
  • Összefoglalva: mindkét elgondolásnak vannak előnyeis és hátrányai. A pontos feladat ismeretében neked kell mérlegelni az előnyöket hátrányokat és az eredmény ismeretében dönteni. Lásd simi.2 hozzászólását.
    Mutasd a teljes hozzászólást!
  • Úgy látszik, a nagy jogi vita hevében elveszett a kérdés: Egy adatbázis vagy több?
    Mutasd a teljes hozzászólást!
  • Nagyon nagy tudása van, jelenleg is aktív fejleszéts alatt áll. Konkrétabban nem lehetne? Mi érdekel?
    Milyen nyelven készül az alkalmazás? Többrétegű architektúra?
    Mutasd a teljes hozzászólást!
  • No, akkor a vita lezárása után beszéljetek arról, amit mélyebben tudtok a Firebird adatbázis(ok)ról.
    Mutasd a teljes hozzászólást!
  • Ennyire mélyen már nem tudom, a jog nem az asztalom. Lehet hogy akkor a fogalmak eltérő értelmezése miatt beszélünk el egymás mellett.
    Mutasd a teljes hozzászólást!
  • A szerződés az nem jogi környezethez tartozik. A jogi környezet a különböző jogszabályok, illetve a jogi eljárásrend gyakorlata. Az egyes szerződéseknek van jogi környezete, azaz milyen jogszabályok határozzák meg a szerződés tartalmát és milyen úton-módon lehet a szerződéssel kapcsolatos jogorvoslati eljárásokat megindítani, lefolytatni.

    Továbbá attól nem lesznek fizikailag elkülönítve tárolva az adatok, hogy azokat egy db szerveren belül külön db-kbe teszed. Ez még mindig csak logikai elkülönítése az adatoknak.
    Mutasd a teljes hozzászólást!
  • "jogi környezet korlátozása miatt"
    Ez nem feltétlenül jogszabályból eredő kötelezettséget jelent. Kötelezettség jöhet pl szerződésből is : a cég akinek könyvelnek olyan adatkezelési irányelvet vár el ami fizikai szeparációt is megkövetel. (adatkezelési nyilatkozat a szerződésben, etc...)

    Mondjuk a teszt 5 éve volt még FB1.5 alatt és egy akkori átlag gépen. Az újabb vasakon és újabb FB valószínűleg jobban produkál.
    100 milliós rekordos adatbázisok alatt mint írtad van vas bőven.
    Mutasd a teljes hozzászólást!
  • pro és kontra is vannak érvek. azért jobb mindegyik ügyfél adatait egy adatbázisban tárolni, mert akkor minden egy helyen lesz, és a legtöbb ezköz ezt támogatja. pl. lehet constrainteket létrehozni, indexelni, van referenciális integritásod, stb. cserébe az üzleti logikádban bejön az a bonyolultság, hogy minden feltételedbe be kell tervezni az ügyfél szerinti szűrést is.

    az ügyfeleket külön adatbázisban tárolva megúszod ezt a szűrést, tudsz ügyfeleket külön-külön archiválni / visszaállítani, a constraintek és indexek ügyfélen belül ugyanúgy megmaradnak. cserébe viszont kelleni fog egy olyan hash logika, ami meghatározza, hogy melyik ügyfélhez melyik adatbázis tartozik (pl. egy master adatbázis, amiben az ügyfélnevek és a hozzájuk tartozó adatbázisok találhatók).

    persze, a redundancia elkerülése, a konzisztencia megőrzése meg a mindenféle teljesítményhelyzetek kezelése nagyon fontos szakmai elvek. de a szakmai követelményeket mindig az üzleti igények alá rendelve kell megvalósítani, azaz nem ők fogalmazzák meg a célt.

    találd ki, hogy milyen funkciók a fontosak a programodban. akár tegyél melléjük valami számszerű hasznot. aztán nézd meg az egyes megvalósításokat, hogy melyikben lesz kényelmesebb a leghasznosabb funkciókat megvalósítani (ha tanultál operációkutatást, akár olyan tudományos módszereket is használhatsz mint a hátizsák-probléma megoldásai - a kollégáim mindig vigyorognak mikor negatív léggömbökről kezdek beszélni). és ez majd kiadja, hogy a te problémádra melyik megközelítés lesz a jobb.
    Mutasd a teljes hozzászólást!
  • Bár értem az érvelésed logikáját, de nem véletlen, hogy mondjuk az SAP, Oracle és a JDE is egy adatbázisban kezeli az összes jogi entitás adatait és nem külön. Több 100 milliós rekordhalmaznál sem tart egy ügyfélnél sem másodpercekbe egy-egy tétel rögzítése. Persze, ilyen cégeknél van is vas a db alatt.

    Azért van szép anyanyelvünk hogy használjuk és értelmezzük is azt.

    érdemes != kötelező


    Hát, értelmezd előbb a teljes mondatot:
    ...a jogi környezet korlátozása miatt


    Arra mutattam rá, hogy a jogi környezetnek ilyen jellegű korlátozása nincsen! Semmilyen jogszabály nem írja elő azt, hogy az adatok elkülönítését úgy kéne megoldani, hogy külön db-be pakolod az egyes cégek adatait egy db szerver instancián belül. Ha csak annyit írtál volna, hogy
    Itt is érdemes bevállalni redundanciát (ami valójában adatbázis szinten nem is redundancia)
    , a jogi környezet korlátozásaira tett kitétel nélkül, akkor ez egy logikus érveléssel alátámasztható vélemény lett volna. A jogi környezet korlátozásaira való hivatkozással viszont elrontottad a dolgot.

    Teljesítménnyel kapcsolatos dolgokra lehet hivatkozni, arra is, hogy az egyes cégekhez tartozó adatok jobban elkülönülnek, ha külön db-kben vannak, csak a jogra való hivatkozást kell kerülni.
    Mutasd a teljes hozzászólást!
  • "Egy adatbázis egy tábla? Vagy hogy?"

    Nope. Pont azért lesznek nagy tábláid, mert egy táblába több cég adatia vannak benne (pl. egyetlen táblába van benne az összes cég összes számlájának fejadata)
    Lehetséges hogy minden tábláról cégenként legyen egy másolat, de akkor a business logik kód horror lesz.

    "Ott hogyan dolgoznak azokkal a hatalmas táblákkal? "
    Lassabban, mint a kis cégek.

    "Azért hogy ez a probléma szembe jöjjön nem kis adatmennyiséggel kell dolgoznod."
    Éves szinten kb százezer bizonylatnál már határozottan érezni lehet (1-2 másodperc csak az indexek karbantartása egy pár soros bizonylat rögzítésnél)

    "a cégazonosítóra minden select-be az összes táblára szűrni kell - mert hogy? Például az ÁFA táblát miért kéne szűrni cégazonosítóra? "
    OK nem az összesnél. De pont ott kell, és fontos ahol a komplexebb business logic van, és ahol sok tétel van a táblában.
    Mutasd a teljes hozzászólást!
  • Ha visszavonja, akkor a könyvelő köteles törölni.

    De nem. A könyvelés más. A könyvelő felel a könyvelésért. Ha céget megbüntetik, akkor a cég perelhet. Ha viszont elve hibás adatokat adott át, akkor azt a könyvelőnek meg kell találnia.
    Mutasd a teljes hozzászólást!
abcd