Kexi vs. LibreOffice Base

12.12.2017 19:15 | Přečteno: 2559× | GNU/Linux

Vážení přátelé, mám za úkol sestavit pro známého databázi s informacemi, týkajícími se provozu hospody. Počet jídel denně, tržba, sestavy s grafy a diagramy, výpočet výplat pro kuchaře atd. Data tam bude zadávat on. Výhledově, jak se bude projekt rozrůstat, se bude jednat o samostatnou GUI aplikaci. Prvních několik verzí bych ale chtěl udělat jako databázi nad LibreOffice Base, popř. Kexi z Calligra Suite.

Zajímalo by mě, jestli někdo máte větší praktické zkušenosti s jednou nebo nejlépe s oběma z těchto aplikací. Zatím obě testuji, ale nenashromáždil jsem dosud širší empirické informace. Někdy se mluví o tom, že LO Base je u rozsáhlejších, déle používaných databází nestabilní a dochází u ní k poškození dat v databázi. (Je to zmíněno i v jednom polooficiálním tutoriálu k OO Base, kde je to dáváno do souvislosti s tím, že ve výchozím nastavení Base ukládá celou databázi, t.j. data i strukturu, do jednoho souboru, což časem zvyšuje riziko inkonzistencí.) Je tomu tak?

Našel jsem názor, že Kexi je na tom se stabilitou lépe. Nevím ale, zda to lze považovat za objektivní tvrzení, nebo jde spíš jen o zaujetí nadšeného uživatele. Můžete to někdo potvrdit? A dá se vůbec o Kexi mluvit jako o alternativě k Base, nechybí mu nějaká zásadní funkcionalita?

Další věc je, že výsledek musí kromě GNU/Linuxu fungovat i na Windows. Lze provoz KDE aplikací na Windows vůbec považovat za dostatečně stabilní pro běžného uživatele?

Děkuji za reakce.        

Komentáře

Diskuse byla administrátory uzamčena

[xkomczax]

Přímo s Calligra Suite na Windows zkušenost nemám, ale nějakou dobu jsem takto používal digiKam a šlo to: pádů si moc nevybavuji.

Komentářů, které ti budou radit, abys to udělal v něčem pořádném, bude myslím ještě dost, netřeba přidávat ten můj...

[ehm]

databázi s informacemi, týkajícími se provozu hospody. Počet jídel denně, tržba, sestavy s grafy a diagramy, výpočet výplat pro kuchaře atd. Data tam bude zadávat on. Výhledově, jak se bude projekt rozrůstat, se bude jednat o samostatnou GUI aplikaci.

Na to nic hotového neexistuje?

[def]

Takových produktů je milion, jejich vývoj je dost drahý a amortizuje se přes mnoho instalací. Kéž se na tom autor aspoň něco naučí, komerční hodnota takového úsilí jde se započítáním ceny příležitosti restauratéra řešícího dětské nemoci záporná. Co takhle zkusit nějakou immutable DB jako Datomic? Hodně by mě zajímaly zkušenosti.

[deda.jabko]

Co takhle zkusit nějakou immutable DB jako Datomic? Hodně by mě zajímaly zkušenosti.

Tak si to vyzkousej, co ti brani? Myslis, ze evidence provozu v hospode opravdu potrebuje cloud a distribuovane uloziste, ktere dokaze horizontalne skalovat?

Kazdopadne davat do produkce neco, s cim autor nema zkusenosti a pravdepodobne nikdo v jeho okoli, je ten nejpitomejsi napad. Je potreba si uvedomit, ze pokud ten soft bude delat to, co ma, je dost pravdepodobne, ze tam pobezi bez problemu deset/dvacet let. Napriklad u nas v hospode jedou porad na systemu napsanem ve FoxPro v roce '95. Zajimalo by me, kdo se bude za dvacet let schopen postarat o technologicky vystrelek z dob davno minulych.

[def]

Jestli ten systém obstarává objednávky a rezervace z webu, plánování rozvozů, kontrolu zaměstnanců, je každej rok aktualizovaný podle změn v zákonech... tak samozřejmě nevadí, že je to FoxPro. Evidentně za tím stojí firma, která to nedělá pro jednu hospodu, takže se jí to vyplatí udržovat v rozumným stavu.

Pokud ten software prst na tepu doby nedrží, tak majiteli hospody nevadí, že nevydělává tolik, kolik by mohl, což je samozřejmě jeho věc. Jen to asi není moc dobrej zákazník pro softwarovou firmu, co vydělává na optimalizování a zefektivňování.

Argument byl (a upřímně řečeno mi přijde, že byl dost jasnej už napoprvé), že vzhledem k tomu, že se autor chystá dělat něco evidentně ekonomicky neživotaschopného, měl by si z toho odnést aspoň co nejvíc zkušeností. Nakonec z toho bude mít výhodu i ten restauratér, páč to autora nepřestane bavit za osm měsíců, ale až za deset.

Od Datomicu bych si BTW nesliboval horizontální škálovatelnost, ale pravdu o světě. Překvapuje mě, že jsou lidi ochotní udržovat informace o penězích v mutable databázích. Schopnost vidět historii všeho je zásadní.

[Rezza]

Je potreba si uvedomit, ze pokud ten soft bude delat to, co ma, je dost pravdepodobne, ze tam pobezi bez problemu deset/dvacet let.

Ano!

Výhledově, jak se bude projekt rozrůstat, se bude jednat o samostatnou GUI aplikaci

Protoze tohle je nejvetsi lez v IT svete :D.

[ghibulo]

Jestli nedošlo u LibreOffice Base k radikálnímu zvýšení stability za poslední rok, tak na základě vlastní zkušenosti odrazuji od pokusů dělat v tom něco vážnějšího. Dle mého to byla/je nejméně stabilní aplikace z celého balíku LibreOffice. S Kexi osobní zkušenost nemám.

[Bedňa]

Nato že je komentár v Maďarštine, aj tak má nulovúhodnotu.

[Petr]

Felvidek je soucasti, ne?

[Bedňa]

LO funguje celkom dobre, aby si neprišiel o dáta, tak si to deene zálohuj, to platí všade.

[PetrHL]

Pokud to má fungovat všude, doporučil bych to spíše jako webovou apku. Klidně nějaký php framework + bootstrap a bude se Vám to programovat lépe než kdybyste použil OO Base a za měsíc narazil na nějaký limit.

[kovyyy069]

+1, ale nebuď dinosaur a udělej to v nodejs + angular2/react

[PetrHL]

Klidně dinosaur budu. Předpokládám, že ta aplikace pojede roky a nebude čas/nálada přepisovat každý měsíc kvůli změnám v těch desítkách knihoven, které to celé potřebuje.

Hlavně to celé záleží na něm, co umí, jak dalece se mu v tom bude chtít hrabat.

[kovyyy069]

Ty jsi viděl npm jenom z rychlíku, co? Nebo na co je podle tebe "^" ? Neochota se učit už se u tebe projevuje, máš to za pár...

[PetrHL]

Neochota učit se nové věci se u mne fakt neprojevuje . Jen jsem ke světu Javascriptu trochu skeptický. O pár věcí jsem se v Node.js snažil a zkušenost dobrou nemám.

Jo, mám to za pár desítek let :D.

Záleží na budoucím autorovi, co ho baví, kterou technologii zná atd. Čeká jej hodně práce. A je jen na něm, co si vybere.

[kralyk z abclinuxu]

Klid, je to jen troll, co píše tyhle rádobytechnický kydy do každý druhý diskuse...

[ehm]

A člověk by byl řekl, že záleží spíš na vlastnostech programu rozpoznatelných uživatelem než na použitém jazyce a frameworku.

[regine2]

Pokud databáze z pohledu stability, tak SQL s grafickým rozhraním. Stačí si zagooglit - MySQL, RazorSQL, Postgresql. Pak jsou některé neOpen zadara do určité velikosti záznamů.

10 of the Best Free Linux Relational Databases

[Vladimír]

Nechceš jako základ pro databázi použít ZIMA-CAD-parts?

[Vinicius]

Problém s integritou dat by se dal vyřešit kombinací LO Base + Externí databáze (MySQL, Maria). Na interní databázi LO Base (říkají tomu HSQL) bych se moc nespoléhal.

Pokud se později odkloníte od LO Base jak poskytovatele GUI, zůstane vám databázová část, která se dá propojit s novým GUI (ať už to bude web, nebo klasická aplikace pro desktop).

Jo LO Base je sice zdarma, ale MS-Access to zrovna není.

[Josef Kufner]

Jak Kexi, tak LibreOffice Base umí prcovat s externí aplikací. Nahoď mu někde PostgreSQL, nastav přístup a LO Base používej jen jako klienta, který se po síti připojí k databázi. Výhodou bude možnost souběžného přístupu z více počítačů, případně snadné doplnění webového rozhranní (např. na reporty se to může hodit).

[Josef Kufner]

… externí databází.

[alfonz]

Zdravím, pokud máte zájem o informace, co jsme testovali my, když jsme chtěli řešit databázi pro Pripravto.cz (správa zakázek, příprava výroby, návrh nábytku, nářezové plány atd - prostě informační a výrobní systém)

Tak jsme začali právě zde http://www.abclinuxu.cz/poradna/programovani/show/362608 a pak tady http://www.abclinuxu.cz/blog/truhlarina/2014/9/pripravto-databaze-a-vystupy

Poznamenám, že jsme s první verzí fungovali 2 roky na OO/LO Calc. Objevili se tam také nějaké problémy, ale určitě to bylo lepší než LO Base - nestabilita, často rozbité nastavení atd.

Kexi jsme také zkoušeli a také to nedopadlo > jednoduše to stále není Access. OO Calc se mu blíží možnostmi mnohem více. Také mezi tím bylo něco jako Glom > mělo to být obdobné ale také to nevyhovovalo. Všechny mají společný problém v podobě stability a následně použití. Pokud tedy chcete začít s nějakým rozvržením a testy vzal bych CALC.

Nakonec máme http server s webpy a data v pickle/shelve či pickleshare a json. Možná bych někdy v budoucnu vybral Postreges pokud bych měl jednoduchá data. Doporučuji se podívat na Odoo > možná by to pro Vás mohl být zajímavý základ.

[kralyk z abclinuxu]

Možná bych někdy v budoucnu vybral Postreges pokud bych měl jednoduchá data.

Postgres podporuje json (včetně třeba indexování et al.).

[bhy]

Díky všem za reakce a omlouvám se, že jsem na ně neodpovídal, nakonec jsem toho měl tolik, že jsem nevěděl, kde mi hlava stojí.

V každém případě, jako celkem radikálního zastánce open source mě to dost mrzí, ale LO Base se ukázalo být naprosto nedostatečným řešením. Kromě nestability (vyloženě pády při běžných operacích, zejména při návrhu formulářů a sestav - trochu pomohl upgrade 5.2 na 6.0, ale ne úplně) byl problém v nedostatku dokumentace a s tím spojenou nutností řešit řadu poměrně triviálních záležitostí metodou pokus omyl, a taky nešlo nijak rozumně odstínit uživatele od interních věcí, aby neměl tendence klikat do tabulek a dotazů.

Ve výsledku jsem se rozhodl udělat to poctivě jako desktopovou aplikaci v PySide (Python + Qt). Aspoň se toho víc naučím. (Uživatel je konzervativní a chce vyloženě klasickou desktopovou aplikaci, žádnou online javascriptovou věc, co by jela i na Androidu. Ale možná si to v rámci rozšiřování obzorů zkusím udělat pro sebe i takhle.) O výsledek se pak samozřejmě podělím.