Portál AbcLinuxu, 2. května 2025 05:39
Vyšla první veřejná verze klienta pro relační databáze SQL-DK. Program je určen pro příkazovou řádku a použití v shellových skriptech nebo k ručnímu spouštění SQL dotazů. Podporuje číslované i pojmenované parametry dotazů. Díky formátovacím modulům může produkovat výsledky databázových dotazů v libovolném formátu. Viz oznámení verze 0.8.
Tiskni
Sdílej:
Zkoušel jsi to spustit? Jak dlouho to trvalo? Kolik ms. by pro tebe bylo přijatelných?
Mne to zaujalo jako pěkný vhled do javího mindsetu...No ty argumenty v druhém odstavci jsou ukázkou nekonstruktivní kritiky. Pokud píšu desátý jednoúčelový skript, může se hodit nástroj, který ty jednoúčelovky zastřeší. Použité meziformáty (xml atd.) opět nejsou žádným argumentem - jejich použití může být přesně to, co se mi z nějakého důvodu hodí. Není to spíš tak, že přínos programu může zhodnotit spíš ten, kdo ho pro své účely napsal (byť by tím účelem byl třea jen tréning)? A pokud se program hodil mě, může se hodit i někomu jinému.
…protože v určitém případě může být java nejvhodnější řešení…Jo, jenže tohle je velice určitý případ ve kterém Java velice určitě není nejvhodnější řešení.
Například pokud je java hlavní vývojová platforma týmu, na produkci běží vše v javě a nic jiného pořádně nikdo neumí…A nechce umět. A to je přesně "Javovský mindset". Všude jinde je normální že programátor který není idiot používá ty nástroje které jsou pro daný účel vhodné. Ne ty které jsou v jeho oblíbeném jazyce.
Naopak pro někoho, kdo umí python, má ho nainstaovaný atd. je vhodná volba python. A někdo, kdo potřebuje sql pro embedded zařízení s uClibC, zvolí třeba C.Omyl. Kdokoliv není javista, (nebo trubka) si v první řadě všimne že ten program je z 90% shodný s klasickým řádkovým klientem. A že zbytek se dá zařídit nějakým tím awkem, sedem a podobně. Správný javista nejspíš řádkového klienta v životě neviděl, natož awk.
Nekonstruktivní je tedy to, že se hodnotí za použití skrytých předpokladů (předpokládám, že ostatní jsou ve stejné situaci jako já) ale závěry se prezentují jako obecně platná realita (na toto je java nevhodná).Můj "skrytý" předpoklad je, že komplikovanější věci (na co nestačí mysql cli) dělám rovnou v pythoním interpretru, protože nabouchat připojení do databáze a spuštění dotazu je natolik triviální že to nestojí za nějaké programování. Můžu debatovat s rubisty nebo perlisty jestli se na tom dá ubrat pár písmen, ale vsadím koláč proti psímu sucharu že v každém z těch jazyků je to jednodušší než ten pitomý xml konfigurák, ani nemluvě o matlání se s JDBC. Takže ano, troufám si tvrdit že na tohle je Java obecně platně pitomá. Jestli mi nevěříš (a budiž varován že jsem se javou nějakou dobu živil) tak nemusíš filozofovat o realitě, předpokladech a konstruktivitě. Stačí když vymyslíš nějaký případ kde to nebude platit. Něco co ten nástroj zvládne lépe než pár řádku skriptu. Do toho.
Všude jinde je normální že programátor který není idiot používá ty nástroje které jsou pro daný účel vhodné. Ne ty které jsou v jeho oblíbeném jazyce.+1
Všude jinde je normální že programátor který není idiot používá ty nástroje které jsou pro daný účel vhodné. Ne ty které jsou v jeho oblíbeném jazyce.
A platí to i obráceně? Je správné mít panický strach z programů v Javě a odmítat je bez toho, aby člověk zjistil, jak rychle fungují a zda je to pro jeho potřeby dostatečné nebo se zabýval poskytovanou funkcionalitou?
A že zbytek se dá zařídit nějakým tím awkem, sedem a podobně. … mysql cli
Prvotní motivací pro napsání SQL-DK byly dvě věci:
a k tomu se začaly nabalovat další věci – důležitá je mj. abstrakce – oddělení formátování od samotného provedení dotazu → výstup v libovolném formátu
dělám rovnou v pythoním interpretru, protože nabouchat připojení do databáze a spuštění dotazu je natolik triviální že to nestojí za nějaké programování
Tenhle přístup taky někdy používám, ale časem zjistíš, že děláš pořád dokola to samé a že už tě to nebaví. Jde taky o ta nakonfigurovaná připojení (jména a hesla), která nejsou rozházená všude možně po kódu nebo v mnoha různých konfiguračních souborech… A taky to má trochu jinou cílovou skupinu – SQL-DK není určen jen pro programátory, cílem je nabídnout i pokročilejší funkcionalitu, aniž bys musel něco programovat, psát kód.
A platí to i obráceně? Je správné mít panický strach z programů v Javě…Takže, jestli tomu dobře rozumím, když umím více než jeden programovací jazyk a vyberu si ten ve kterém to zbastlím nejsnáze, tak je to projev strachu? Tak to budu těžkej případ pro Chocholouška. BTW nevykládej si tuhle debatu jako znevážení tvého těžce vydřeného kódu. Naopak, vypadá to rozumě a bez javistických úchylek (až na ty konfiguráky v xml
). Ale to nic nemění na tom co pravil o javistické sebestřednosti Brambor výše: ubastlit to v pythonu je snažší a výsledek bude lepší. Což tu zatím nikdo nedokázal věrohodně rozporovat.
Zde si dovolim pohled do XXX prostredi. I kdybych nakrasne ovladal YYY, jako ze trochu ovladam, v zadnem pripade si v nem neudelam pomocne nastroje na projektu vyvijenem komplet v ZZZ. Duvodem je, ze 90% ZZZ programatoru YYY neumi, nebude se ho ucit a nebude tedy schopna takove pomocne nastroje udrzovat nebo integrovat a pripadne je rozbije. Coz me trapi mnohem vice, nez zda je to reseni pametove efektivni, elegantni atd.
Dosaď si tam libovolné proměnné. Málokterá firma si může dovolit programátory, kteří umí padesát jazyků.
15.1.2014 22:10
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Málokterá firma si může dovolit programátory, kteří umí padesát jazyků.Na druhou stranu základní znalost GNU / Linux je leckde považována za standard.
Mně tady trolling žere jen paní ze Slovenska 
Tady ale nejde o to, jaký jazyk si vybral autor (to je jeho věc), ale jak se na to dívají uživatelé – někteří bohužel mají z programů v Javě panickou hrůzu a bojí se takové programy i nainstalovat. Chápu, že někdo může mít špatné zkušenosti s nějakými obludnými a špatně napsanými GUI aplikacemi, ale přijde mi to prostě hloupé mít takové předsudky ke každému programu v Javě.
15.1.2014 12:49
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Omyl. Kdokoliv není javista, (nebo trubka) si v první řadě všimne že ten program je z 90% shodný s klasickým řádkovým klientem. A že zbytek se dá zařídit nějakým tím awkem, sedem a podobně. Správný javista nejspíš řádkového klienta v životě neviděl, natož awk.
+1
Já jsem se do diskuse moc nechtěl zapojovat, protože nemám ve zvyku kritizovat cizí práci, kterou mi ani nenutí (takže je mi to jedno), ale když jsem si četl ten web, tak jsem si říkal, proč bych měl používat tohle, když psql zvládne totéž (+ se tomu dá pomoci standardními nástroji GNU).
nejspíš řádkového klienta v životě neviděl
Tohle se bohužel týká poměrně hodně lidí. Bez phpmyadmina, adminera, pgadmina apod jsou úplně bezradní a někteří dokonce tyto programy považují za tu db samotnou.
16.1.2014 16:05
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Na druhé straně nevidím důvod, proč nepoužít phpmyadmin, pgadmin, atd. Co je na tom špatného?
Když se zeptáš takhle, tak na tom není špatného asi nic. Já jsem mluvil o něčem jiném. A to o stavu, kdy programátor tyto klienty považuje za tu DB samotnou a v hlavě si kolem toho vytvoří špatný model, jak věci fungují. S tímto se, bohužel, setkávám v praxi častěji než bych chtěl. Ti lidé často vůbec nevědí nic o klient server, nevědí nic o SQL apod. DB se nejlépe navrhují s tužkou a papírem, úplně bez kompu. A potom hezky poctivě ručně nahrkat create table v klientu. Až tohle ten člověk zvládne, tak si může vzít na pomoc pomocníka. Protože ví, co má dělat.
Někdy nechápu, proč účetní nedělají rovnou v řádkovém klientu, ale používají nějakou aplikaci typu účetní program.
Ale ta účetní by měla být schopná to spočítat kompletně bez programu. To je prostě základ. Ten program samozřejmně pomůže, ale člověk musí vědět v čem.
Jenom proto, že si plácáte játra a boucháte se do prsou, že používáte za každou cenu řádkového klienta?
Za každou cenu ne. Já jsem si tím prošel taky. V jedné chvíli, před spousty let (2006), jsem zjistil, že bez grafickýho udělátka nejsem schopný založit ani uživatele. Což se samozřejmě ukázalo v tom nejhorším okamžiku, kdy jsem toho klienta neměl a musel jsem něco udělat. Takže jsem prostě zatnul zuby, vyhodil všechny klienty a poctivě se to prostě naučil. Tehdy mysql. A zjistil jsem, že DB je úplně něco jinýho, než jsem si do té doby myslel. A toto byl ten zásadní krok, kterej mi pomohl se v tomto oboru dostat o dost nahoru. A přesně toto, na základně vlastní zkušenosti, radím ostatním.
Všude jinde je normální že programátor který není idiot používá ty nástroje které jsou pro daný účel vhodné. Ne ty které jsou v jeho oblíbeném jazyce.vysledok je dolezitejsi ako nastroj, ktorym sa k nemu dospeje
ovšem pro interaktivní práci to příliš nedoporučuji (na běžném desktopu ale není potřeba se toho bát)
Díky. Ta unixová filosofie, že program má dělat jednu věc, je otázka granularity – co je to ta „jedna věc“? Někdo tu psal, že by radši udělal jednoúčelový skript v pythonu, který udělá všechno od přípravy dotazů přes dotázání databáze až po naformátování finálního výsledku. Já jsem to rozdělil na víc částí – dotazy si můžu připravit zvlášť, přes rouru nebo soubor je předat SQL-DK, ten se dotáže databáze a formátování řeší až formátovací modul nebo externí program napojený přes rouru.
Co se týče XML jako meziformátu – XML je první, protože k němu mám nejblíž, ale budou i jiné1 formáty a formátovače – mám v plánu např. formátovač, který pro každý řádek spustí zadaný příkaz. Tedy něco jako xargs, ale bude to pracovat s řádky z databáze, ne s řádky textu, což má výhodu v tom, že uvnitř hodnot můžou být klidně znaky konce řádku a taky že se řádek neslije do jednoho textového řetězce – zachovají se hranice mezi hodnotami jednotlivých sloupců (předají se jako pole argumentů tomu příkazu) a půjde tam líp pracovat se vstupními a výstupními proudy (nasměrování do souborů nebo naopak STDIN načtený z hodnoty určitého sloupce) a s proměnnými prostředí (můžou být odvozené z hodnot sloupců).
K tomu stránkování: to právě není problém delegovat na jiný program, dá se to použít v rouře:
sql-dk … | less -R
(včetně barev) Možná doplním do toho shellovského obalovacího skriptu volbu, která tam to | less -R přidá, aby ho uživatel nemusel psát. Ale v samotném programu (v té javovské části) tohle řešit nechci, přijde mi to zbytečné.
[1] už takhle bylo první vydání docela velké, musel jsem to utnout, protože jinak bych to nevydal nikdy a pořád přidával nové a nové věci
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
12.1.2014 10:30
13.1.2014 14:39
15.1.2014 12:23
15.1.2014 14:35