Poslední příspěvky

31

Server / Re:Používá se ještě databáze Firebird?

« Poslední příspěvek od Kriegel kdy 27. 04. 2025, 10:38:20 »

Co si vzpomínám, tak třeba MRP-K/S nebo Smartmedix a určitě spousta dalšího sw... Na první ohmatání velmi příjemná databáze, kdysi jsem pro někoho dělal nějaké psí kusy s daty ze skladu právě z MRP a zanechalo to na mně velmi dobrý dojem...

32

Vývoj / Re:SQL: vypis susedov

« Poslední příspěvek od Filip Jirsák kdy 27. 04. 2025, 09:06:32 »

Vim ze je to nevyzadana rada, ale strankovani je spatne z mnoha duvodu. Vykon databaze je jen z nich.
Mnohem lepsi a modernejsi pristup je "inifine scolling". Je to mnohem jednodusi a pro uzivatele je to i prehlednejsi.

hmm... ako to funguje s niecim, co je potencialne tabulka o 1000+ riadkoch?

K čemu by bylo zobrazení tabulky, která má víc než 1 000 řádků? Bude to nějaký uživatel procházet očima řádek po řádku? Pokud chcete uživateli zobrazit tabulku s více než tisíci řádky, není potřeba řešit, jak mu to zobrazit, ale jak mu umožnit zadat takové filtrovací či vyhledávací podmínky, aby našel, co hledá.

33

Server / Re:Používá se ještě databáze Firebird?

« Poslední příspěvek od Pavel Stěhule kdy 27. 04. 2025, 08:28:00 »

Jestli nedošlo ke změně, tak nad Firebirdem běží Pražská Městská knihovna. Osobně Firebird nepoužívám, a zrovna tak neznám nikoho, kdo by ho používal, ale po očku sleduji vývoj. Je to databáze, která má relativně stabilní letitý vývoj, který je stále živý, a má to svojí niku. Je to databáze vhodná pro embedding - nakopírujete 2 soubory a jedete, má to vlastnosti, které zjednodušují vývoj v embeddingu. V tom je to stejná databáze, jako je SQLite. Oproti ní je to ale databáze - s plnohodnotným SQL, s vestavěným skriptovacím jazykem, monitoringem. SQLite (i podle vlastního vyjádření jejího autora) je spíš transakční filesystém s SQL API. SQLite je primitivní (ale pro řadu použití dostačující) jednouživatelská velice malá databáze. Oproti tomu je Firebird úplná více uživatelská databáze (i když se spíš jen výjimečně používá pro větší počet uživatelů), která je ale stále velmi malá a kompaktní (vhodná pro embedding), což Postgres nebo MySQL třeba určitě není.   Pokud bych předpokládal, že s nějakým hw budu distribuovat i databázi, tak pravděpodobně bych šel do Firebirdu (zvlášť pokud bych měl někoho, kdo s ním umí).

34

Vývoj / Re:SQL: vypis susedov

« Poslední příspěvek od Pavel... kdy 27. 04. 2025, 03:03:19 »

Vim ze je to nevyzadana rada, ale strankovani je spatne z mnoha duvodu. Vykon databaze je jen z nich.
Mnohem lepsi a modernejsi pristup je "inifine scolling". Je to mnohem jednodusi a pro uzivatele je to i prehlednejsi.

hmm... ako to funguje s niecim, co je potencialne tabulka o 1000+ riadkoch?

35

Server / Re:Používá se ještě databáze Firebird?

« Poslední příspěvek od Buldr kdy 27. 04. 2025, 00:03:33 »

Pouziva sa este Firebird databaza, ak ano, kde? A na co je dobra?

Proč by se nepoužívala? Na uzavřených systémech, nebo embedded (řídící terminál - okruh) se bude používat ještě hodně dlouho. Spolehliva, robustní a především nenáročná, tedy má všechný základní předpoklady fungovat na kritickch systémech s minimálním výkonem (např.: řízené okruhy).

36

Studium a uplatnění / Re:Jak se zbavit problémového kolegy?

« Poslední příspěvek od CPU kdy 26. 04. 2025, 23:05:37 »

Problémový kolega teď jezdí Fabkou za 2litry na sto? Toho bych se nezbavoval, ten bude cajk.Dementi jezdí frantíkem nebo starým bávem. Feldou jezdi socky na pracák a geekové do Kaufu. A podle spotřeby to je klidný a vyrovnaný člověk.

37

Studium a uplatnění / Re:Jak se zbavit problémového kolegy?

« Poslední příspěvek od xyz kdy 26. 04. 2025, 22:56:45 »

Že se s jedničkovou Fabií 1.4MPI dalo při troše snahy přiblížit ke 3 litrům můžu potvrdit.
Sám jsem před cca 25 lety za podobnou spotřebu jel třeba z Litomyšli do Poděbrad (o půlnoci a totožnou rychlostí jako jely kamiony), nebo z Vrchlabí do Mladé Boleslavi v neděli odpoledne (plynule jedoucí kolona 70-80, vlastně pořád mírně s kopce)
S mým současným dieslovým Citroenem C5 1.6HDI 2006 (pohotovostní hmotnost 1500 kg) jsem jednou dokázal na jednu nádrž ujet 1580 km se spotřebou 3,8 litru.
Ale nikdy nešlo o podtáčení jako spíš o plynulou jízdu mimo město na nejvyšší rychlostní stupeň rychlostí 80-90 km/h.

Typicky Cech pije pivo, nosi ponozky v sandalech a chlubi se, ze jeho auto zere 2 litry na 500 km )

38

Server / Re:Používá se ještě databáze Firebird?

« Poslední příspěvek od MalyTomi kdy 26. 04. 2025, 22:50:12 »

Uz dlhsie nesledujem jej vyvoj, ale urcite bezi na sw, ktory vznikal v case jej najvacsej slavy a ako sa vravi, ked to funguje, nesahaj na to.
jej dost velkou vyhodou bolo, ze instalacku si vedel okresat na par MB a je celkom rychla a nenarocna. Aj ked velke firmy postupne (aspon v mojom okoli) presli na interbase, viem si ju realne predstavit aj dnes v nejakych mensich projektoch.

39

Vývoj / Re:SQL: vypis susedov

« Poslední příspěvek od Kit kdy 26. 04. 2025, 22:26:26 »

No, co chce hknmtt nevíme, protože to tají. Z původního dotazu to vypadalo spíš že nechce pouštět celý dotaz (pravděpodobně se spoustou joinů) na získání dat pro detail, ...

Obávám se, že OP bude mít v tom dotazu ± jeden join, jinak by se o jeho složitosti zmínil.

40

Vývoj / Re:SQL: vypis susedov

« Poslední příspěvek od Filip Jirsák kdy 26. 04. 2025, 21:24:38 »

Session je jedna pre všetky taby. Implementuje sa ako ID-čko uložené v cookies, a cookies sú naviazané na adresu webu, nie na tab. Alebo máte na mysli nejakú inú formu session?

Nikoli. Session jsou data uložená na serveru pod nějakým identifikátorem, přičemž identifikátor je v prohlížeči. Identifikátor session může být klidně v URL, v paměti aplikace, v Session/Local Storage, i v té cookie.

Práve ste povedali, že pri prechode sa načíta nová trojica => musí sa nanovo spustiť stránkovacia query. Tomu sa predsa OP chce vyhnúť, to je podstata tejto diskusie.

No, co chce hknmtt nevíme, protože to tají. Z původního dotazu to vypadalo spíš že nechce pouštět celý dotaz (pravděpodobně se spoustou joinů) na získání dat pro detail, když potřebuje znát pro předchozí/následující stránku jen id. A dotazy jsou pravděpodobně nějak automaticky generované a hknmtt buď neumí nebo nemůže upravit jejich generování tak, aby vracely jen id. Ale ono je to celkem jedno, hknmtt nechce vyřešit svůj problém, proto ho nepopsal, takže je to tady spíš takové nezávazné povídání o tom, co všechno se může skrývat za pojmem „stránkovaný dotaz. Přičemž je dost možné, že hknmtt o žádné stránkované dotazy nestojí, protože za stránkované dotazy se obvykle označuje něco, co velké množství záznamů zobrazuje postupně po stránkách (v databázové terminologii se tomu říká spíš okna), zatímco hknmtt psal o tom, že zobrazuje jen jeden záznam. Takže jde spíš o master–detail zobrazení, kdy chce na detailu zároveň zobrazovat odkazy ne sousední záznamy (vzhledem k masteru).

Jinak kdyby hknmtt opravdu nechtěl znovu spouštět dotaz na celou sadu záznamů (master), jediná možnost by byla zapamatovat si celý výsledek v nějaké cache a procházet tu. Protože ať uděláte to okno sebevětší, vždy se uživatel může doklikat až na konec a pak nezbyde než ten dotaz udělat znovu. Jenže to je právě problém, že my nevíme, jaký problém hknmtt řeší a proč by nechtěl provádět dotaz znovu (a který dotaz, protože u master–detail jsou dotazy dva).