Autor Téma: Sklamanie z "bohyne"  (Přečteno 9806 krát)

Offline Radek Červinka

  • Administrátoři
  • Padawan
  • *****
  • Příspěvků: 2973
  • Karma: 108
    • Verze Delphi: D2007, DXE + 2 poslední
    • O Delphi v češtině
Re:Sklamanie z "bohyne"
« Odpověď #30 kdy: 15-07-2016, 10:55:37 »
no ja za to nemôžem, ale musel som vám to ukázať, aj ked je to len polovica dat (cele to ma 50kB), to je údaj z cenníka o kompatibilite danej baterky ... ale tu informaciu potrebujem..aby som vhľadal tu správnu
Hmm, a kde je napsano, ze s nim mas zachazet jako s jednim zmolkem  dat :o

Proste takhle s daty pracuje snad nejaka sekretarka ev. PHP strikac, kteri si pod pojmem databaze dokazi predstavit max. excelovskou tabulku...

Od jiste doby si myslim, ze na takovy typ dat je idealni NoSQL databaze, ktera presne odpovida zadani: tj. nekanonizovane data ruzneho obsahu jako popisy a charakteristika zbozi, nebo napr. popisy projektu na SF.NET.
Ale zatim jsem si to nestihl vyzkouset, takze nejsem si jist jak moc je to idealizovana predstava autoru.

Embarcadero MVP - Czech republic

Offline František

  • Guru
  • *****
  • Příspěvků: 704
  • Karma: 7
    • Verze Delphi: primárne v XE5, občas 10.2.3 comunity
Re:Sklamanie z "bohyne"
« Odpověď #31 kdy: 15-07-2016, 12:41:11 »
radek, NoSQL databaze som po tovojom prispevku tiez omrkol... ale zatial nic

stanislav, nemusim nic pre precovat a ni prekonvertovat
kazdy den to robi import  nanovo (delete all -> insert)

jedna sa o jeden stlpcek z 36 ... ktory tam vlastne zostane, len mi pribudnu dve tabulky a nejaka logika
v tomto momente ma este zaujima ci je rozdiel ukladat 50.000 varchar alebo pouzit blob, ma to nejake vyhody?

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 5976
  • Karma: 43
    • Verze Delphi: W10 + D11
Re:Sklamanie z "bohyne"
« Odpověď #32 kdy: 15-07-2016, 16:09:27 »
Vychádzam z diskusie. S blobom nevieš robiť a bude to problém. Riešenie by asi bolo komplikované. Ktovie či aj nie pomalé.
Uložiť 50 000 záznamov nie je až taká záťaž. Nemám osobnú skúsenosť, ale nepredpokladám viac ako nejaká tá minúta. Práca potom bude lahoda.
W10 64b, Delphi 10.4, FireBird 3.05
Expert na kladenie nejasne formulovaných otázok.

Offline našinec

  • Hrdina
  • ****
  • Příspěvků: 423
  • Karma: 5
Re:Sklamanie z "bohyne"
« Odpověď #33 kdy: 15-07-2016, 18:34:19 »
Hloupá reakce na hloupé téma:
Františka zklamal 'Ohnivý pták' na 'bohyni', ale 'Ohnivého ptáka' 'bohyně' zklamal naopak František.  ;)  ;D

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3287
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Sklamanie z "bohyne"
« Odpověď #34 kdy: 16-07-2016, 10:21:06 »
Od jiste doby si myslim, ze na takovy typ dat je idealni NoSQL databaze
No, s myslenkou vyzkouset nejakou NoSql DB si pohravam uz leta, rad bych nejakou objektovou jako Db4o ci Cache, ale nenasel jsem odvahu jit do toho po hlave v nejakem realnem projektu a na hrani nemam cas ani prostor k alternativnimu reseni v pripade, ze bych se dostal do slepe ulicky.

Me uplne ke stesti staci, ze jsem se pro posledni velky projekt odhodlal pouzit na vsechno ORM nad MSSQL s nativnim MS Entity Frameworkem a musim rict, ze jsem si tim dost nadrobil (a to ten EF uz je ve verzi 6, takze netrpi detskymi neduhy). Kdyz jsem se rozhodoval, tak jsem vedel, ze v projektu budou operace, pro ktere neni ORM vhodny, ale predpokladal jsem, ze je dokazu obejit.  A obesel jsem (za cenu napr. rozbiti bulk operaci do davek, extra zpusobem prace s change trackerem, pouzitim raw sql operaci na kriticke operace a obchazeni change trackeru aj).
Intuitivne citim, ze se pohybuji lehce za hranici aplikovatelnosti technologie ORM v danem typu projektu, nehlede na pracnost a narocnost pri vymysleni, proc neco nefunguje a jak to obejit.

V mych pocatcich s DB me desne stvala rigidita ER modelovani, tak jsem zkousel nad ER RDBMS udelat entity-attribute model. Flexibilni to bylo, to ano, takze cil zbavit se rigidity byl dosazen, ale vykon velmi mizerny a v praxi nepouzitelny a generator SQL hnusne slozity. Tenkrat jsem mel ale prostor pro nejake protypovani, ktere skoncilo nezdarem a ja se pokorne zaclenil do sveta relacnich DB.

V prakticke aplikaci tech NoSql vidim hlavni problem v tom, ze jsou vetsinou docela uzce specializovane na pomerne malou mnozinu operaci. No a byt donucen pouzit vice RDMDBS v jednom projektu, to taky neni zadna slava a je to dost pracne na udrzbu (meli jsme rodinu aplikaci, kde klienti pouzivali Sqlite a ta byla synchronizavana s nejakou obecnou DB na serveru a byl do docela humus to udrzovat a delat v tom zmeny, dopady do navrhu (clovek musel zapomenout na integer coby klic)).

Zkratka, ja uz se zrejme k NoSql nedostanu, i kdyz bych to chtel docela videt nasazene na nejakem problemu, o kterem bych mel jasnou predstavu, co se musi resit a srovnat si to s NoSql pristupem.





Offline František

  • Guru
  • *****
  • Příspěvků: 704
  • Karma: 7
    • Verze Delphi: primárne v XE5, občas 10.2.3 comunity
Re:Sklamanie z "bohyne"
« Odpověď #35 kdy: 17-07-2016, 22:54:36 »
stastanislav, to nie  je 50.000 zaznamovale 50.000 char jeden zaznam, zaznmov j ecca 280.000

Offline František

  • Guru
  • *****
  • Příspěvků: 704
  • Karma: 7
    • Verze Delphi: primárne v XE5, občas 10.2.3 comunity
Re:Sklamanie z "bohyne"
« Odpověď #36 kdy: 18-07-2016, 10:57:06 »
to snáď nie je možné, ďalšie obmedzenie FB, max varchar 8.000 (unicode 4.000), takže musim do blobu

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3287
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Sklamanie z "bohyne"
« Odpověď #37 kdy: 18-07-2016, 11:34:34 »
to snáď nie je možné, ďalšie obmedzenie FB, max varchar 8.000 (unicode 4.000), takže musim do blobu
To neni omezeni FB ale TDatasetu viz unit DB:
Kód: Delphi [Vybrat]
  1.   dsMaxStringSize = 8192; { Maximum string field size }
  2.  

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 5976
  • Karma: 43
    • Verze Delphi: W10 + D11
Re:Sklamanie z "bohyne"
« Odpověď #38 kdy: 18-07-2016, 11:35:25 »
Citace
stastanislav, to nie  je 50.000 zaznamovale 50.000 char jeden zaznam, zaznmov j ecca 280.000
To som si neuvedomil. Presnejšie, nepoznám štruktúru DB. Tak som urobil zlú úvahu. Ale my stále nevieme, či sa jedná o jednorázovú akciu, alebo opakovanú.
Podľa všetkého sa jedná o denne opakovanú akciu. Jedna možnosť je to všetko vymazať a znova nahrať, ako to máš teraz.
Druhá možnosť je to komplet prekopať a robiť to poriadne. To znamená ukladať parsované údaje do samostatných tabuliek - nie dlhý text do Blob-u. V tom prípade by si ukladal iba zmeny.

Lenže mi máme mizerné informácie na to, aby sme mohli akokoľvek pomôcť. Myslím, že sa tu za daných podmienok urobil už maximum.
W10 64b, Delphi 10.4, FireBird 3.05
Expert na kladenie nejasne formulovaných otázok.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3287
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Sklamanie z "bohyne"
« Odpověď #39 kdy: 18-07-2016, 11:37:43 »
to snáď nie je možné, ďalšie obmedzenie FB, max varchar 8.000 (unicode 4.000), takže musim do blobu
Jinak to neni nic neobvykleho: string je string a ne text/blob. Z tech beznych DB nebude prostestovat akorat Sqlite, protoze ta si na staticke typy nehraje a vsechno ma ulozeno jako ASCIIZ string tudiz bez deklarovane velikosti pole.

Offline František

  • Guru
  • *****
  • Příspěvků: 704
  • Karma: 7
    • Verze Delphi: primárne v XE5, občas 10.2.3 comunity
Re:Sklamanie z "bohyne"
« Odpověď #40 kdy: 18-07-2016, 11:41:37 »
to pf1957: http://www.firebirdsql.org/en/firebird-technical-specifications/ opravujem ..obmedzenie na 32768...ale aj tak je to malo

to Stanislav: prosím ťa, prečítaj si diskusiu, je to tam

Citace
mam DB s cca 280.100 záznamov
s dĺžkou 1-5000 má cca 279.000 záznamov
s dĺžkou 5.000-10.000 má cca 1000 záznamov
s dĺžkou 10.000-50.000 má cca 100 záznamov
prehľadáva sa ešte názov produktu ale ten má do 150 znakov...

a

Citace
stanislav, nemusim nic pre precovat ani prekonvertovat
kazdy den to robi import  nanovo (delete all -> insert)

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3287
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Sklamanie z "bohyne"
« Odpověď #41 kdy: 18-07-2016, 11:45:50 »
Excellent
Rated 1 time
to pf1957: http://www.firebirdsql.org/en/firebird-technical-specifications/ opravujem ..obmedzenie na 32768...ale aj tak je to malo

Ne, to neni malo, akorat ty sis usmyslel, ze se budes neustale pokouset o p*coviny.

Offline pepak

  • Padawan
  • ******
  • Příspěvků: 1558
  • Karma: 37
    • Pepak.net
Re:Sklamanie z "bohyne"
« Odpověď #42 kdy: 18-07-2016, 14:52:19 »
Proboha, Františku. Už mě unavuje tu pořád znovu číst tvoje stížnosti na databázi, protože nechce přijmout tvůj špatný přístup. Ušetři sobě i nám nervy a použij SQLite, kterému to je z principu jeho implementace jedno a ty tvoje prasárny ti dovolí. Budeš spokojený, že ti to funguje, a my nebudeme muset číst hovadiny, protože si nedáš říct, abys to udělal správně. Díky.

Offline František

  • Guru
  • *****
  • Příspěvků: 704
  • Karma: 7
    • Verze Delphi: primárne v XE5, občas 10.2.3 comunity
Re:Sklamanie z "bohyne"
« Odpověď #43 kdy: 18-07-2016, 15:52:51 »
síce stále neviem čo je to to správne, ale dnes večer to skúsim implementovať a dám report ;)

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3287
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Sklamanie z "bohyne"
« Odpověď #44 kdy: 18-07-2016, 17:03:08 »
síce stále neviem čo je to to správne, ale dnes večer to skúsim implementovať a dám report ;)
Mas asi 3 moznosti:
  • pouzit nejakou nonSql DB (pokud mas cas a chut experimentovat)
  • pouzit fulltext (s ohledem na to, ze se nejedna o text, ale v podstate seznamy nejakych kodu, tak bych to nedoporucoval
  • porozumet obsahu polozek, navrhnout ER model, polozky rozparsovat a nacpat do toho modelu a vhodne sestavit SQL dotazy. To je tradicni postup.