Poslední příspěvky

Stran: 1 [2] 3 4 ... 10
11
Obecné / Re:xmldokument problem
« Poslední příspěvek od pf1957 kdy Dnes v 09:34:49 »
Pre XML súbory do cca 100MB je aká najvhodnejšia (rozumej najrýchlejšia) jednosmerná metóda na prečítanie dát z XML a uloženie do DB.
(doteraz používam transformácie cez TXMLTransformProvider - je to super univerzálne na rôzne štruktúry dát (mám ku každemu *.xtr) ale predpokladám, že vyššie popisovaná metóda (DOM?) by mohla byť rýchlejšia, a čítal som dačo o SAX, ale neporozumel som)
DOM znamena, ze se text rozlozi na prvky a sestavi se ve stejne strukture v pameti, takze je tam cely naraz. Jak je to rychle oproti transformaci nevim, protoze tu jsem nikdy nepouzil. SAX je prubezny parser, ktery vyvolava udalosti OnXXX na lexikalni prvky a je na tobe, jak si z toho obsah poskladas. Takze vlastni zpracovani byva velmi rychle.

Kdysi, kdyz jsem potreboval zpracovavat XML soubory, ktere nejak rucne vyprasili PHP strikaci jako kdyz prasili HTML na webu, tak jsem si napsal prubezny parser a pomoci nej se ten XML upravoval do validniho stavu. Teoreticky bych to mohl poskytnout, ale prakticky to nebude k nicemu, protoze je to jeste v ANSI a je to napsane pro nas proprietarni framework a knihovny
12
Obecné / Re:xmldokument problem
« Poslední příspěvek od František kdy Dnes v 09:22:10 »
ešte jedna záludná otázka.
Pre XML súbory do cca 100MB je aká najvhodnejšia (rozumej najrýchlejšia) jednosmerná metóda na prečítanie dát z XML a uloženie do DB.
(doteraz používam transformácie cez TXMLTransformProvider - je to super univerzálne na rôzne štruktúry dát (mám ku každemu *.xtr) ale predpokladám, že vyššie popisovaná metóda (DOM?) by mohla byť rýchlejšia, a čítal som dačo o SAX, ale neporozumel som)
13
Získam na USB mesačne 6000 malých CSV a jeden veľký.  Asi tak pol na pol. Tie malé zlučujem do jednoho csv.
Nakoniec mám dva zdrojové CSV, cca po 3+ Giga. Nie som inak správcom dát. Nemám žiadny vplyv na prípadné havárie zdrojového systému. Ani neviem, čo sa v zdrojovom podniku s dátami rieši. Pracujem pre kontrolujúci podnik.
Mnou hore popísané riešenie, v originál maile, bod 10, (ohľadne rýchlosti) z CSV do SQLite trvá tušim 5 minút. Je to od testov nejaký ten mesiac, ale myslím, to určite nebolo viac. Takže spokojnosť s rýchlosťou importu až nad mieru.

A to jeste vypada, ze jsi nepouzil nativni, ale emulovany rezim array DML :)

Pokud jde jen o import dat do jine databaze, vyhral za me TFDBatchMove. Interne pouziva taktez array DML techniku a pomerne jednoduse umoznuje konfiguraci zdrojovych-cilovych sloupcu a mapovani datovych typu, stejne tak zvlada konverze typu (da se pripadne napsat manualni konverze). Zdroje a cile jsou pak dataset, SQL i textove soubory; tedy vcetne CSV (staci si jako zdroj patricne nakonfigurovat TFDBatchMoveTextReader).

Pro takovy pripad bych si vytvoril "mapovaci" utilitu (se sablonami mapovani pro firmy i jednotlive studenty) a nechal TFDBatchMove zaridit zbytek. Minimum prace a pri rozdeleni zdroju CSV napr. do adresaru moznost automatizace (s tim ze by zdroje pouzivaly stale stejne pojmenovani sloupcu i datovych typu). Pak uz by zbyl jen krok k tomu abys vytvoril sluzbu ktera bude cekat na notifikace zmen v adresarich a data automaticky exportovat do cizi databaze, samozrejme pokud bude souhlasit nastavene mapovani (na ty notifikace zmen existovala pekne napsana trida TDirectoryWatch).
14
Delphin ďakujem aj za "náhradný" link na DocWiki
P.S. docwiki si muzes pro Berlin prohlizet na http://web.archive.org.
Je to trochu zložitejšie vnútri pri klikaní na linky, ale ako náhradné riešenie super.
15
Ad Stano:
Vážim si Tvoje odpovede, iba vychádzam z daných okrajových podmienok. To neznamená, že práve také predstavujú môj pohľad na ideálne riešenie databázy. Tiež mám nejaký ten zdravý úsudok. Iba pracujem v rámci mantinelov.

Ad Delfin:
1.
Táto citácia vyzerá nádejne, preskúmam:
Ohledne vlastnich funkci, staci(lo) dropnout komponentu TFDSQLiteFunction, prilinkovat driver, nastavit Name a ArgumentsCount, komponentu aktivovat a v OnCalculate handleru pristupovat k AInputs.Inputs a AOutput pomoci patricnych As<T> accessoru, napr:
2.
Jinak, pokud jde o presun dat, zvazil bych pouziti TFDBatchMove. Ma moznost mapovani sloupcu i datovych typu, a vytvorit rozumne schema (bez pohadek) by snad stalo v tomto pripade za uvahu. Porad si ale nejak nemuzu zaradit, co maji ty funkce spolecneho s "Tu sa jedná iba o kópiou živých dát." :-[
Získam na USB mesačne 6000 malých CSV a jeden veľký.  Asi tak pol na pol. Tie malé zlučujem do jednoho csv.
Nakoniec mám dva zdrojové CSV, cca po 3+ Giga. Nie som inak správcom dát. Nemám žiadny vplyv na prípadné havárie zdrojového systému. Ani neviem, čo sa v zdrojovom podniku s dátami rieši. Pracujem pre kontrolujúci podnik.
Mnou hore popísané riešenie, v originál maile, bod 10, (ohľadne rýchlosti) z CSV do SQLite trvá tušim 5 minút. Je to od testov nejaký ten mesiac, ale myslím, to určite nebolo viac. Takže spokojnosť s rýchlosťou importu až nad mieru. Dokonca sa bude dať asi ešte zlepšiť.. Taká rýchlosť sa asi nijak nebude dať prekonať. Ale ani nie je treba.
Samozrejme TFDBatchMove mám v merku. Na iné účely určite neraz použijem.
Uvedené CSV data majú svoje názvy polí od profi firmy, takže názvy sú "db korektné".
Kompatibilitu s Excelom naopak riešim v inej kategórii, v tej čo je pre študentov.
Ale aj pre svoj nástroj ako taký, chcem s MS Access kompatibilné funkcie. Na to som za roky zvyknutý.

Uff, toto som prehnal v mojom predošlom maile, opravujem:
Napríklad Format. Aby vyhovela tej z Accessu, dalo to dosť práce. U nej napríklad záleží na na type vstupných údajov. Access to zvláda komplexne (napríklad aj mimo mesiacov z rozashu 1..12, ale to nie je všetko).
Mesiace ( aj dni ), mimo bežný rozsah, zvláda fn DateSerial, nie Format.
Inak je citovaný výraz pravdivý
16
Budiz, opustme co je a neni spravne a vratme se k tematu. Cilem je tedy simulace Access pro SQLite DBMS (se zachovanim SQL syntaxe Access, vcetne funkci)?

Jinak, pokud jde jen o presun dat, zvazil bych pouziti TFDBatchMove. Ma moznost mapovani sloupcu i datovych typu, a vytvorit v cilove DBMS rozumne schema (bez nudnych pohadek v nazvech objektu) by snad stalo v tomto pripade za uvahu. Porad si ale nejak nemuzu zaradit, co maji ty funkce spolecneho s "Tu sa jedná iba o kópiou živých dát." :-[
17
FireDAC / Re:SQLite + FireDAC + UDF nevracajú nadefinovaný dátový typ v rámci SELECT
« Poslední příspěvek od mibainfo kdy 22-11-2017, 22:22:11 »
7 GB dát mesačne sa zdá byť závažné, ale je to trochu inak.
Ide len o kontrolu určitých vybraných výkonov nad podriadenou firmou.
Tu sa jedná iba o kópiou živých dát.
Údaje sú dodávané v tisíckách text súborov.
Zásadné operácie a hospodárenie však nad nimi vykonáva niekto úplne iný.
Predtým riešené v Exceli. Limit 1 000 000 riadkov bol dosiahnutý cca za 6 dní.
Teraz zvládneme rok..
18
Som amatér, ale jednu poznámku skúsim
Citace
A áno, užívatelia v Exceli vyrobia tabuľky s tými najnemožnejšími názvami polí. Veru ešte aj iné veci.
Ako som čítal Tvoj príspevok, tak pre Teba nemôže byť problém vyrobiť si nejakú funkciu na prevod názvov polí v Excel-y na korektné názvy pre DB.
Citace
Nestačí sa len rozhorčiť, čo všetko by nemali robiť. To nezmeníme. Oni zamestnávajú stovky, ba tisíce študentov, ktorí riešia aj 12 hodinové úlohy formou Copy/Paste.
Žiaľ zostáva len súhlasiť.

K bodu A len taká poznámka: tak to s tými vedúcimi pracovníkmi (vyhlásil som osobný boj anglickým výrazom v slovenčine, ak máme zodpovedajúce výrazy :) ) a inými absolventmi VŠ v praxi aj vyzerá.
19
FireDAC / Re:SQLite + FireDAC + UDF nevracajú nadefinovaný dátový typ v rámci SELECT
« Poslední příspěvek od mibainfo kdy 22-11-2017, 22:00:18 »
Delfin, veľmi kvalifikovaná odpoveď. Ďakujem.
Problém je trochu zložitejší na jednu výmenu názorov.
Tak aspoň rýchlo:
A.
Kompatibilita SQL a Excel je moja priorita. Už roky učím tieto predmety manažérov na Fak. manazmentu Univ. Komenského, BA.
Žiadna databáza, ktorá nejde z USB kľúča, ich neprinúti študovať nejaké ďalšie technické problémy. Ak sa majú naučiť nejaké funkcie, tak maximálne raz, určite už nie dvakrát.
SQL Access má 98% funkcií zhodných s Excelom. Excel ich má asi 375, SQL Acces z toho využíva asi 100. Sandobox je trochu problém. Niektoré fn sú tým blokované.
Ak majú tí moji pracovať doma, musí to šlapať. Hneď. Žiadne inštalácie. Žiadna blokácia.
B.
Kde som definoval funkcie?
Trochu Harakiri: priamo v "FireDAC.Stan.ExprFuncs".
Mám ho modifikovaný pod iným menom priamo v rámci projektu.
Odsledoval som ako je to tam pôvodné. Niekde som len pridal svoje Aliasy a pár funkcií som založil nanovo. Napríklad Format. Aby vyhovela tej z Accessu, dalo to dosť práce. U nej napríklad záleží na na type vstupných údajov. Access to zvláda komplexne (napríklad aj mimo mesiacov z rozashu 1..12, ale to nie je všetko). V Delphi potrebujem poznať vstupný formát. Podľa toho použijem buď FormatFloat, alebo FormatDateTime. Takže nie je iná cesta. Absolútne záleží na type Double, alebo DateTime.
Ale to nie je jediný prípad. Potrebujem to korektne a presne aj vo viacerých ďalších prípadoch. Nie je problém, aby som čokoľvek zamenil. Viď bod D.
C.
K UDF kódu. Nie, že by som ho nechcel sem poslať, ale sú to trochu dlhé texty.
Teraz som doučil. Dlhých 6 hodín. Som už nejak unavený na modifikácie. Ale spoľahlivo to ne/funguje v každej akokoľvek a kdekoľvek nadefinovanej funkcii.
Myslím, že pokiaľ som funkcie nepoužil v rámci SELECT, tak to nejak šlo. Teda ak by mali fungovať len ako math parser.  Akonáhle sú súčasťou SELECT, zabúdajú na typ DATETIME a tvária sa vo výsledku ako Double. To je veľký problém.
Zajtra v priebehu dňa môžem poslať jednoduchý vzor.
Je to obrovská škoda, lebo SQLite je inak prekvapivo šikovný nástroj.
Podotýkam, že som robil roky s Access enginou (ADO). Nie priamo v MS Access, ten som nikdy nepotreboval, ďalej v MS SQL Server, MS SQL Server Compact (na prvý pohľad sľubné, ale nepoužiteľné), MS SQL Server Local DB (nádejné, ale limitované na 11 GB), nanovo som skúšal FB local, dobre rozbehnuté, ale limit z názvami objektov je fatálny. Skúšal som aj Nexus DB, ale má limity podobne ako FB.
K prípadným limitom SQLite: Napríklad FULL JOIN som schopný simulovať. Trochu horšie je to s náhradou Transform, to chce analýzu dát a potom nagenerovať CASE .. WHEN. Ale to dám tiež. Ak by Access engina nemala hlúpe limity, tak by to bola dobrá databáza. Asi pred 12-timi rokmi som porovnával výkon Access a MS SQL. Fifty:Fifty. Boli to série SQL, čo bežali cca 20 minút. Niečo rýchlejšie v jednom, niečo v tom inom. Obe bežali na PC. Lenže ten s MS SQL bol dedikovaný. Veľká nadnárodná firma. Nešetrili. Ono sa to akoby nezdá, ale PC majú len jedného užívateľa. Ich výkon je preto ozaj dostatočný.
Mimochodm v SQLite je veľmi limitovaný aj UPDATE .. SET. Nemá možnosť JOIN, čo je drsné, ale také veci viem prekonať.
D.
Mám absolútne rozparsovaný vstupný text SQL. V dictionary mám podchytený každý jeden string/funkciu/pole/tabuľku/zátvorku, či znak, ktorý by nebol nejako inak pokrytý. Spolu 40 rôznych typov, takmer po každom stlačení klávesy.. Dosť výkonnejšie a rýchlejšie ako to robí fireDAC. Len to vedieť využiť. V tých typoch som lokálne narazil. Zatiaľ jediná vec, čo ma ozaj zradila.
E.
Pre môj prípad nemenné požiadavky kladené na databázovú enginu:
Excel kompatibilné funkcie (zabezpečím sám), očakávané typy polí a ich neobmedzené názvy.
Stačí, keď engina bude robiť, čo sľubuje. Čo sa dá od nej oprávnene predpokladať.
A áno, užívatelia v Exceli vyrobia tabuľky s tými najnemožnejšími názvami polí.
Veru ešte aj iné veci. Lenže na báze excelu stále pracujú stovky firiem, vrátane IT gigantov.
Nestačí sa len rozhorčiť, čo všetko by nemali robiť. To nezmeníme. Oni zamestnávajú stovky, ba tisíce študentov, ktorí riešia aj 12 hodinové úlohy formou Copy/Paste.
20
Obecné / V sekci FireDAC chybi hvezdicky
« Poslední příspěvek od Delfin kdy 22-11-2017, 21:57:12 »
Stala se hroziva vec ;D V podsekci FireDAC (mozna i dalsich, neprochazel jsem je vsechny) chybi hodnotici hvezdicky. Daly by se tam pridat (pripadne zkontrolovat i ostatni)? Ta sekce byla pridana teprve nedavno...

Dekuji
Stran: 1 [2] 3 4 ... 10