Forum Delphi.cz

Databáze => Firebird a Interbase => Téma založeno: Stanislav Hruška 04-10-2020, 21:40:43

Název: Veľká tabuľka - ak na ňu
Přispěvatel: Stanislav Hruška 04-10-2020, 21:40:43
Nemám si o tom s kým pokecať. Tak to píšem tu. Počty sú jednoduché. Do tabuľky sa zapisujú údaje každý mesiac. Všetko nadhodnocujem, aby som mal rezervu. Ich počet je:
Počet služieb (32) x mesiace v roku (12) = 384
Všetko v jednej tabuľke
384 x počet bytov 20 000 = 7 680 000 x 10 rokov = 76,8 mil.
.
To ma vedie k myšlienke mať pre každé SVB samostatnú tabuľku. Predpokladám 100 SVB. Pri daných počtoch by to bolo 776 800(!) záznamov na SVB za 10 rokov.
Nemyslím si, že dôjde k takému nasadeniu. Predpokladám maximálne 500 bytov. Aj to som silný optimista.
Tým by nebol problém s výkonom. K tomu by pristúpila aj skutočnosť, že tie SVB budú rozdelené medzi viacerých pracovníkov. Pre jedného tak 10-20 SVB.
Mňa svedomie tlačí do toho. Jednoducho nerob odbabranú robotu, keď vieš o probléme a jeho riešení.
Robiť pre každý rok novú tabuľku spoločnú pre všetky SVB nie je dobrý nápad:
Prosím Vás o váš názor. Mám počúvnuť svoje svedomie? Ja si myslím, že mám.
.
Riešenie už mám v hlave. Spočíva v tom, že pri založení SVB sa v pozadí vygeneruje názov tabuľky (SVBAa) pre jeho predpisy (DSVBAa) a 2 x pre vyúčtovanie (BSVBAa a ASVBAa; podľa mesiacov a vlastníkov - kvôli dodatočným opravám/úpravam a prípadným štatistikám). A samozrejme dané tabuľky.
Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: Jirka 04-10-2020, 22:19:04
Nemám si o tom s kým pokecať. Tak to píšem tu. Počty sú jednoduché. Do tabuľky sa zapisujú údaje každý mesiac. Všetko nadhodnocujem, aby som mal rezervu. Ich počet je:
Počet služieb (32) x mesiace v roku (12) = 384
Všetko v jednej tabuľke
384 x počet bytov 20 000 = 7 680 000 x 10 rokov = 76,8 mil.
Jako  první bych si položil otázku:
Potřebuji u jednoho uživatele (tím myslím firmu která bude aplikaci používat) mít více než 1 SVB (tím myslím zda budu potřebovat pracovat s daty více SVB naráz )  . Tj. nemohu bez toho žít ?

Za druhou bych si položil otázku:
Potřebuji všechny sledovaná období (10 let !!) v jedné databázi ?

A až si to ujasním mohu pokračovat dál ..


Citace
Riešenie už mám v hlave. Spočíva v tom, že pri založení SVB sa v pozadí vygeneruje názov tabuľky (SVBAa) pre jeho predpisy (DSVBAa) a 2 x pre vyúčtovanie (BSVBAa a ASVBAa; podľa mesiacov a vlastníkov - kvôli dodatočným opravám/úpravam a prípadným štatistikám). A samozrejme dané tabuľky.

Podle mého to nejhorší řešení ..  a IMHO cesta do pekel
Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: vandrovnik 04-10-2020, 22:24:13
Určitě bych nepřidával tabulky pro další SVB, např. proto, že bude neskutečná otrava pak ve všech dotazech vždy dosazovat správnou tabulku, bude příšerné udělat nějaké souhrny za všechny SVB apod., ale především při správném použití indexů bych očekával, že rozdíl v rychlosti práce s tabulkou o 0,5 M záznamech a s 80 M záznamy bude skoro neměřitelný. Kladu ale důraz na to správné použití indexů.
Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: Jirka 04-10-2020, 22:35:09
Kladu ale důraz na to správné použití indexů.
Stačí abys vyhledával podle substringu v názvu firmy  , nájemce  atd.
A pak  stačí jedno natural vyhledávání přes 80M řádků ..
Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: vandrovnik 04-10-2020, 22:38:27
Kladu ale důraz na to správné použití indexů.
Stačí abys vyhledával podle substringu v názvu firmy  , nájemce  atd.
A pak  stačí jedno natural vyhledávání přes 80M řádků ..

Tak záleží, co od toho hledání očekává - pokud se má hledat jen v rámci jednoho SVB, tak to přidá do podmínky (nějaké SVB_ID), na tom bude mít index, takže se nedělá natural scan, ale prohlíží se jen v rámci toho SVB_ID. Pokud naopak opravdu chce hledat přes všechna SVB, tak s jednou tabulkou to má mnohem snazší, než skládat select, kde těch tabulek bude mít 100...
Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: Jirka 04-10-2020, 22:59:12
Tak záleží, co od toho hledání očekává -
Přesně tak , to nevíme přesně ani jeden.
Já  vycházím z toho, že je to hodně podobné ekonomickým softům, takže uzávěrky, vyučování měsíční a roční období atd. atd.

Citace
pokud se má hledat jen v rámci jednoho SVB, tak to přidá do podmínky (nějaké SVB_ID), na tom bude mít index, takže se nedělá natural scan, ale prohlíží se jen v rámci toho SVB_ID.
No jistě, ale opět natural scan v rámci toho substringu

Citace
Pokud naopak opravdu chce hledat přes všechna SVB, tak s jednou tabulkou to má mnohem snazší, než skládat select, kde těch tabulek bude mít 100...
Samozřejmě to už jsem psal v prvním příspěvku že je to cesta do pekel

Ještě bych dodal že plánovat držet databázi s 10 lety mě bude dost omezovat v systémových změnách v databázi a celé aplikaci .
Nehledě na to, že mě těžko bude každý den zajímat kolik zaplatil Fratišek Opršálek za plyn v roce 2010
Ale je pravda že někoho to zajímat může  :D

Ještě bych Stanovi doporučil - zkusit aplikaci nasadit alespoň  v poloprovozu a ne řešit cache , komplexní třídy vyjimek se slovníky , interfejsy a spoustu dalšího balastu.



Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: pepak 05-10-2020, 07:06:17
To ma vedie k myšlienke mať pre každé SVB samostatnú tabuľku. Predpokladám 100 SVB. Pri daných počtoch by to bolo 776 800(!) záznamov na SVB za 10 rokov.
I běžné databáze jsou stavěné na to, aby takovéhle počty záznamů zvládly za den.

Citace
ročne 7,68 mil záznamov. To už bude robiť problém
Nebude.

Citace
ak budem chcieť záznamy podľa jednotlivých SVB, tak to bude komplikované riešenie
Pokud už máš obavy z velikosti dat a jejich zpracování, tak by mi jako přirozené přišlo, mít pro každé SVB novou databázi. Moc si neumím představit, že by mezi nimi byl datový překryv, takže by rozdělení nemělo vést k duplikacím údajů.

Citace
Prosím Vás o váš názor. Mám počúvnuť svoje svedomie? Ja si myslím, že mám.
Podle mě YAGNI. Sám ho sice často porušuju, ale snažím se vždycky najít ospravedlnění, že to později skutečně bude potřeba, tak proč to neudělat pořádně rovnou.

Citace
Riešenie už mám v hlave. Spočíva v tom, že pri založení SVB sa v pozadí vygeneruje názov tabuľky (SVBAa) pre jeho predpisy (DSVBAa) a 2 x pre vyúčtovanie (BSVBAa a ASVBAa; podľa mesiacov a vlastníkov - kvôli dodatočným opravám/úpravam a prípadným štatistikám). A samozrejme dané tabuľky.
Souhlasím s Jirkou, i podle mě to je velmi špatné řešení. (Ne nejhorší možné, ještě bys to mohl dělit na více tabulek, ale prostě špatné.)
Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: Stanislav Hruška 05-10-2020, 09:12:17
Ďakujem všetkým za reakciu a vzácne zhodný názor na vec.
Ten natural sken pre bežnej činnosti veľmi nehrozí. Všetky údaje zobrazujem pomocou VirtualStringTree. Ten je oddelený od DB. Tam riešim aj vyhľadávanie. Keď niečo potrebujem voči DB, tak vždy mám k dispozícii PrimaryKey (alebo FK).
Ak sa vôbec dostanem na trh, tak sa určite bude jednať o malých správcov (samosprávcov). Tí veľkí to už majú vyriešené.
Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: Stanislav Hruška 05-10-2020, 09:42:40
Je tu ešte jedna zrada, ktorá je proti tabuľkám pre každé SVB.
Pri tvorbe SQL textu by som konštantu názov tabuľky musel vymeniť za premennú. Tu sa nedá použiť parameter. Výsledkom by bolo, že text pre Query by som musel priraďovať pred každým použitím/spustením Query. To je práca navyše. A v drvivej väčšine prípadov zbytočná.
Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: Jirka 05-10-2020, 10:17:53
Je tu ešte jedna zrada, ktorá je proti tabuľkám pre každé SVB.
Pokud si umím představit tak každé SVB má svoji právní  subjektivitu  a není IMHO důvod je vést společně v jedné databázi.
Spíše bych doporučoval model  jedna aplikace - více databází (různé subjekty,  případně  hospodářské roky).
Nehledě jak Stano píše, bude se jednat o "samosprávce" ..
Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: Stanislav Hruška 05-10-2020, 11:37:27
Ako by som v takom prípade riešil situáciu, že jeden užívateľ spravuje viac SVB. To pri každej zmene SVB by som menil pripojenie k DB? Pre ilustráciu uvádzam kľúčové polia v tabuľke FOCS (SVB).
Kód: [Vybrat]
IDFOCS PK
FKUSERAPPS  ID užívateľa, ktorý má SVB na starosti
ISACTIVE
DELETED
YEARFOUNDED
Ostanem pri súčasnom riešení. Ťažko predpokladať, žeby veľký správca bežal na obyčajnom železe. Aj keď skúposť robí svoje.
Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: Jirka 05-10-2020, 12:26:09
Ako by som v takom prípade riešil situáciu, že jeden užívateľ spravuje viac SVB. To pri každej zmene SVB by som menil pripojenie k DB?
Proč se zabývat řešením situace když
Citace
Ostanem pri súčasnom riešení.


Citace
Ťažko predpokladať, žeby veľký správca bežal na obyčajnom železe.
Před chvilkou si psal že se bude určitě jednat o malé subjekty a že ty velké to mají vyřešené
Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: Stanislav Hruška 05-10-2020, 12:40:48
To áno. Ja som len zabŕdol to teoretickej možnosti ;D
Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: pf1957 05-10-2020, 12:41:04
Ako by som v takom prípade riešil situáciu, že jeden užívateľ spravuje viac SVB. To pri každej zmene SVB by som menil pripojenie k DB?
Jak pise Pepak: co te nepali, nehas. Osobne bych si v zive DB drzel vsechny SVB a az bych narazil na problemy, tak bych udelal presun starsich dat do do archivu a aplikaci upravil tak, aby mohla nahlizet do archivu.
Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: pepak 05-10-2020, 12:42:00
Ako by som v takom prípade riešil situáciu, že jeden užívateľ spravuje viac SVB. To pri každej zmene SVB by som menil pripojenie k DB?
No a proč ne? Mohl bys například konfigurační soubor dát jako parametr na příkazové řádce. Uživatel by měl na ploše hromadu ikonek, kde každá by používala jinou konfiguraci.

Nebo bys ukládal jedno spojení do speciální databáze, ve které by byla uložená připojení na dílčí databáze, ze kterých by si uživatel po spuštění aplikace vybral.

Nebo tisíc dalších možností.
Název: Re:Veľká tabuľka - ak na ňu
Přispěvatel: Stanislav Hruška 05-10-2020, 12:47:45
To sa mi viac páči pohľad pf1957. Tie DB by mi len zbytočne komplikovali život.
Z mojej strany je táto téma ukončená. A ďakujem.