Porovnání SQLite vs. MySQL

pb.

Re:Porovnání SQLite vs. MySQL
« Odpověď #45 kdy: 17. 09. 2016, 18:38:12 »
Ktory expert takto uklada data do tabulky? Ak sa stlpec nastavi ako kluc, podla ktoreho sa nasledne hladaju zaznamy, ako mozu mat 2 rozne riadky rovnaky kluc? Programator, ktory takto navrhol dizajn tabulky, je debil (to je to miernejsia nadavka).

Jinak souhlas. Na adresu toho člověka, který takhle zprasil CMS made simple, padaly velmi hrubé výrazy. A ještě hrubější výrazy jsme pak používali, když hotový patch odmítnul se slovy "u mě to funguje".


Re:Porovnání SQLite vs. MySQL
« Odpověď #46 kdy: 17. 09. 2016, 19:03:05 »
Jestli se používal MyISAM engine, tak není co řešit - ten transakce vůbec nepodporuje! Tudíž to, že po havárii jdou data přečíst je jen příjemná (nicméně negarantovaná) vlastnost. Fakticky netransakční engine (jako je např. MyISAM) vůbec negarantuje stav dat v případě havárie. To, že to programátoři zvesela používali, jen ukazuje jejich nevelké znalosti a nulovou odpovědnost.
Firebird transakce má a u nás po havárii většinou dopadne hůř než MyISAM.
A nemáte vypnutý  fsync? Pokud se fsyncuje, tak zrovna Firebird měl být ok

gl

Re:Porovnání SQLite vs. MySQL
« Odpověď #47 kdy: 17. 09. 2016, 19:11:23 »
... jsem se nikdy nesetkal s nekorektním výsledkem selectu...

create table abc (klic integer, jmeno text, hodnota integer);
insert into table abc (klic, jmeno, hodnota) values (1, 'A', 1);
insert into table abc (klic, jmeno, hodnota) values (1, 'B', 2);
select klic, jmeno, sum(hodnota) from abc group by klic;

Kterou hodnotu ve sloupci jmeno vrací náhodně vaše databáze?

Ktory expert takto uklada data do tabulky? Ak sa stlpec nastavi ako kluc, podla ktoreho sa nasledne hladaju zaznamy, ako mozu mat 2 rozne riadky rovnaky kluc? Programator, ktory takto navrhol dizajn tabulky, je debil (to je to miernejsia nadavka).

Ta tabulka je ok, blbec ten kdo od toho dotazu očekává něco smysluplného. Jaké jméno by to podle vás mělo vracet? To není chyba mysql ale vaší neznalosti.

gl

Re:Porovnání SQLite vs. MySQL
« Odpověď #48 kdy: 17. 09. 2016, 19:12:37 »
oprava:

blbec je ten kdo od toho dotazu očekává něco smysluplného

Kit

Re:Porovnání SQLite vs. MySQL
« Odpověď #49 kdy: 17. 09. 2016, 19:31:26 »
Ktory expert takto uklada data do tabulky? Ak sa stlpec nastavi ako kluc, podla ktoreho sa nasledne hladaju zaznamy, ako mozu mat 2 rozne riadky rovnaky kluc? Programator, ktory takto navrhol dizajn tabulky, je debil (to je to miernejsia nadavka).

Možná ten, kdo nepotřebuje mít splněnu 3NF. Takové databáze také existují a plní svůj účel.

Kromě toho si tam SQLite automaticky přidává sloupec "rowid", který funguje jako primární klíč.


N

Re:Porovnání SQLite vs. MySQL
« Odpověď #50 kdy: 18. 09. 2016, 07:36:27 »
V Inno(xtra)db nemuzete nemit transakce. To byla s nejvetsi pravdepodobnosti proste necommitnuta transakce. Kazdy command i v shellu je v transakci. Akorat v shellu nemusite psat commit, pokud predtim rucne nenapisete begin. V ruznych knihovnach pro pristup existuji ruzne nastaveni autocommitu,pripadne "rucnich" commitu knihovny po kazdem commandu, ruzne isolation levely, atd a pak se zda, ze to funguje pokazde jinak. Neni pravda. Mysql svoje nedostatky ma, ale rozhodne ne ve vyse popsanych pripadech.

pb.

Re:Porovnání SQLite vs. MySQL
« Odpověď #51 kdy: 18. 09. 2016, 09:54:03 »
V Inno(xtra)db nemuzete nemit transakce. To byla s nejvetsi pravdepodobnosti proste necommitnuta transakce. Kazdy command i v shellu je v transakci. Akorat v shellu nemusite psat commit, pokud predtim rucne nenapisete begin. V ruznych knihovnach pro pristup existuji ruzne nastaveni autocommitu,pripadne "rucnich" commitu knihovny po kazdem commandu, ruzne isolation levely, atd a pak se zda, ze to funguje pokazde jinak. Neni pravda. Mysql svoje nedostatky ma, ale rozhodne ne ve vyse popsanych pripadech.

To je mi celkem jasné. Dost intenzivně používám PostgreSQL (už od dob Ingres/Postquel přes Postgres95) a tam mají tyto záležitosti poněkud delší tradici. Jen by mě nenapadlo hledat tyto problémy v aplikaci, kde byly použité dohromady čtyři primitivní SQL příkazy a žádné transakce. Dnes už je to nakonec jedno. Ta aplikace je dnes přepsaná o dvě úrovně výš.

Pokud to bylo skutečně způsobené transakcemi, je to pro mě opět důvod se MySQL raději vyhýbat. Důvodem pak není databáze samotná, ale lidé, kteří po MySQL sáhnou:
- LAMP - to M je tam MySQL, kdo kdy slyšel o LAP(ostres)P nebo LAS(qlite)P
- Volbou MySQL žádnou chybu nemůžu udělat
- Proč bych tam měl dát něco jiného, když MySQL je nejpoužívanější?
- Jak zprovozním phpmyadmin?
- Innodb? Ale to by bylo pomalé!
- Nesmyslné select... group by... v aplikacích
- U mě to funguje
- Jak to myslíš, transakce?
- Jak to myslíš, spojit joinem dvě tabulky?
- Jak zprovozním MySQL na Rpi? A proč mi to žere SD karty?

MySQL bývá pro tyto lidi první a jediná volba. Mám s podobnými aplikacemi několik hodně špatných zkušeností a pokusy o nápravu (jednání s autory) bývá natolik frustrující, že použití MySQL je pro mě jedním z prvních filtrů při výběru aplikace.

Neumím pracovat s MySQL a nechce se mi v neznámém prostředí zjišťovat, co nezkušený autor v aplikaci zeslonil. Je možné, že MySQL je dobrá databáze, ale společným jmenovatelem aplikací, se kterými jsem měl nejvíce problémů a vysvětlování zákazníkům, byla právě MySQL.

Re:Porovnání SQLite vs. MySQL
« Odpověď #52 kdy: 18. 09. 2016, 10:36:02 »
Jen by mě nenapadlo hledat tyto problémy v aplikaci, kde byly použité dohromady čtyři primitivní SQL příkazy a žádné transakce.
Já bych naopak přesně v takovéhle aplikaci ty problémy hledal. Protože „žádné transakce“ přesně znamená „často se ta data uloží, ale nevíme proč“, z čehož právě plyne „a někdy se také neuloží, a nevíme proč“.

pb.

Re:Porovnání SQLite vs. MySQL
« Odpověď #53 kdy: 18. 09. 2016, 11:06:20 »
Jen by mě nenapadlo hledat tyto problémy v aplikaci, kde byly použité dohromady čtyři primitivní SQL příkazy a žádné transakce.
Já bych naopak přesně v takovéhle aplikaci ty problémy hledal. Protože „žádné transakce“ přesně znamená „často se ta data uloží, ale nevíme proč“, z čehož právě plyne „a někdy se také neuloží, a nevíme proč“.
Jestli se používal MyISAM engine, tak není co řešit - ten transakce vůbec nepodporuje!...
Proč se tady pořád řeší transakce?

Re:Porovnání SQLite vs. MySQL
« Odpověď #54 kdy: 18. 09. 2016, 11:22:36 »
Proč se tady pořád řeší transakce?
Protože transakce jsou způsob, jak zajistit bezpečné uložení dat. To, že ta aplikace „nepoužívala transakce“ je tedy nejpravděpodobnější příčina toho, proč se vám to chovalo divně.

pb.

Re:Porovnání SQLite vs. MySQL
« Odpověď #55 kdy: 18. 09. 2016, 11:40:35 »
Proč se tady pořád řeší transakce?
Protože transakce jsou způsob, jak zajistit bezpečné uložení dat. To, že ta aplikace „nepoužívala transakce“ je tedy nejpravděpodobnější příčina toho, proč se vám to chovalo divně.

Myisam transakce nepodporuje. 

Re:Porovnání SQLite vs. MySQL
« Odpověď #56 kdy: 18. 09. 2016, 12:13:47 »
Myisam transakce nepodporuje.
Což je nejpravděpodobnější příčina toho, proč se vám to chovalo divně.

pb.

Re:Porovnání SQLite vs. MySQL
« Odpověď #57 kdy: 18. 09. 2016, 12:47:25 »
Myisam transakce nepodporuje.
Což je nejpravděpodobnější příčina toho, proč se vám to chovalo divně.

Rozumím. Způsobila to nepodporovaná a nepoužitá vlastnost. Prostě divná databáze. Lépe se jí obloukem vyhnout.

Re:Porovnání SQLite vs. MySQL
« Odpověď #58 kdy: 18. 09. 2016, 13:01:01 »
Způsobila to nepodporovaná a nepoužitá vlastnost.
Způsobila to absence té vlastnosti.

pb.

Re:Porovnání SQLite vs. MySQL
« Odpověď #59 kdy: 18. 09. 2016, 13:16:22 »
Způsobila to nepodporovaná a nepoužitá vlastnost.
Způsobila to absence té vlastnosti.
Aha. Tohle je ovšem nahrávka na smeč. Jinými slovy říkáte, že v MySQL není atomární a zaručený ani primitivní update, že té databázi pro to chybí některé vlastnosti.

Ani tady nebudu psát, jaký mi z toho vychází závěr.