abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 02:22 | IT novinky

CZ.NIC ODVR (Otevřené DNSSEC Validující Resolvery) nově podporují vedle DNS-over-TLS (DoT) také DNS-over-HTTPS (DoH). DoH lze vyzkoušet ve Firefoxu od verze 62, Chrome od verze 66 nebo Bromite od verze 67.

Ladislav Hagara | Komentářů: 0
dnes 01:11 | Nová verze

Po čtyřech letech od vydání verze 2015.03 byla vydána verze 2019.05 nástroje pro tvorbu 3D modelů OpenSCAD (Wikipedie). Přehled novinek v oznámení o vydání.

Ladislav Hagara | Komentářů: 0
včera 19:44 | IT novinky

Americké společnosti omezují spolupráci se společností Huawei, protože Ministerstvo obchodu Spojených států amerických přidalo Huawei na černou listinu. Omezení již oznámili Google, Qualcomm, Intel, Xilinx nebo Broadcom. Google omezí přístup k Androidu a Google Play. Existujících zařízení by se to nemělo týkat. Prohlášení společnosti Huawei.

Ladislav Hagara | Komentářů: 13
včera 16:47 | Nová verze
Vyšla nová verze Strongswan 5.8.0, multiplatformní implementace ipsec řešení. Mezi hlavní novinky patří podpora nového virtuálního interface XFRM, který je součástí kernelu od verze 4.19. Dále přibyla podpora IPv6 do backendu i pluginu aplikace NetworkManager, nebo např. podpora zašifrovaných hesel v utf-8 přes EAP-MSCHAPv2. Kompletní seznam změn viz changelog.
Max | Komentářů: 0
19.5. 00:22 | Pozvánky

Richard Stallman, zakladatel hnutí svobodného softwaru, projektu GNU a Free Software Foundation, vystoupí 6. června od 17:30 v Brně v kině Scala se svou přednáškou Free Software Movement and GNU/Linux Operating System. Přednášku organizuje Ústav práva a technologií Masarykovy univerzity.

Ladislav Hagara | Komentářů: 34
17.5. 21:11 | IT novinky

Hewlett Packard Enterprise (NYSE:HPE) kupuje společnost Cray Inc. (Nasdaq:CRAY) za přibližně 1,3 miliardy dolarů. Výrobce superpočítačů Cray má v seznamu 500 nejvýkonnějších superpočítačů na světě TOP500 aktuálně 52 superpočítačů. S Intelem staví další superpočítač Aurora. S AMD staví superpočítač za 600 milionů dolarů s názvem Frontier. Ten by měl v roce 2021 převzít vedení v TOP500.

Ladislav Hagara | Komentářů: 4
17.5. 19:44 | Zajímavý projekt

Ondřej Kokešpodcastu Dataři představuje projekt Česká otevřená data. Jedná se o sadu skriptů, které stahují především finanční data poskytovaná státními institucemi. V rozhovoru vysvětluje, že ke správné interpretaci dat jsou potřeba doménové znalosti, a popisuje zkušenosti, jak získat dokumentaci, která u datových sad často chybí.

Fluttershy, yay! | Komentářů: 0
17.5. 10:11 | Zajímavý projekt

Nadace XPRIZE vyhlásila před pěti lety soutěž Global Learning XPRIZE o nejlepší open source výukový program nebo inovativní způsob výuky, který umožní dětem v rozvojových zemích samostatně se naučit číst, psát a počítat. Tento týden byly vyhlášeny výsledky (YouTube). O první místo a 10 milionů dolarů se podělili Kitkit School a onebillion. Pět vítězných výukových programů bylo zveřejněno na GitHubu.

Ladislav Hagara | Komentářů: 19
17.5. 06:00 | Komunita

Dalších šest produktů od společnosti ThinkPenguin získalo certifikaci RYF (Respects Your Freedom, Respektuje vaši svobodu) udělovanou Nadací pro svobodný software (FSF). Certifikaci RYF má nově například také převodník z USB na paralelní port (LPT). Certifikace RYF byla představena v říjnu 2012.

Ladislav Hagara | Komentářů: 9
16.5. 23:11 | Pozvánky

Dnes je Světový den přístupnosti, anglicky Global Accessibility Awareness Day (GAAD, Wikipedie). Světový den přístupnosti vznikl v roce 2012. Jeho smyslem je šířit osvětu v této oblasti mezi širokou veřejností a motivovat ji k diskusím, přemýšlení a chuti dozvědět se o tématice přístupnosti webu, dokumentů, software, mobilních aplikací, asistivních technologiích či potřebách lidí s nejrůznějším postižením něco nového. O víkendu

… více »
Ladislav Hagara | Komentářů: 0
GPU kterého výrobce aktuálně preferujete pro provoz Linuxu?
 (49%)
 (25%)
 (25%)
 (2%)
Celkem 309 hlasů
 Komentářů: 27, poslední včera 15:36
Rozcestník

none

18.6.2014 12:31 | Linux | poslední úprava: 5.2. 17:56

none        

Hodnocení: 60 %

        špatnédobré        

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

18.6.2014 12:41 Pošli kvety
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Další poňomrd.
18.6.2014 12:55 gsnak | skóre: 20 | blog: gsnak
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Preco nepouzit tu hashovaciu tabulku/funkciu rovno v programe? Preco robit to ako samostatnu databazu?
DOGE: DE7q1kxqvoFek7UGWBWBt47QWJTRBqVNLL
18.6.2014 12:57 noo | skóre: 3 | blog: Kvazilog | Praha
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Však ta funkce bude v programu. Nikde o databázi funkcí nic nepíšu. Snad :)
AbcLinuxu.cz je jen velká skupina lidí, co se navzájem dohadují o tom, kdo si umí líp vyhonit.
18.6.2014 13:00 gsnak | skóre: 20 | blog: gsnak
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Pises o client-server architekture. Preco klient-server pre tak jednoduchu vec? Preco nie tak ako to ma napr glib, proste kniznica.
DOGE: DE7q1kxqvoFek7UGWBWBt47QWJTRBqVNLL
18.6.2014 12:59 noo | skóre: 3 | blog: Kvazilog | Praha
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Jo takhle. Už vím jak si to myslel. Databáze makes things cooler.
AbcLinuxu.cz je jen velká skupina lidí, co se navzájem dohadují o tom, kdo si umí líp vyhonit.
18.6.2014 13:01 gsnak | skóre: 20 | blog: gsnak
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Tak potom mam uz len jednu otazku. Bude to web-scale?
DOGE: DE7q1kxqvoFek7UGWBWBt47QWJTRBqVNLL
18.6.2014 13:05 noo | skóre: 3 | blog: Kvazilog | Praha
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Pokud to není jen rozlejvání benzínu kolem táboráku :D Tak ano. Měla by být web-scale, ale tak daleko ještě nejsem.
AbcLinuxu.cz je jen velká skupina lidí, co se navzájem dohadují o tom, kdo si umí líp vyhonit.
Josef Kufner avatar 19.6.2014 11:02 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Tak, tak. Udělat něco jako sqlite. Tedy knihovnu pracující nad jedním souborem. Jak sám píšeš, velké databáze na tohle už existují a takovou databázi nenapíšeš sám v rozumném čase. Malou knihovnu dohromady dáš v pohodě a postavit nad ní velký server později je vcelku přímočaré. Sice také už existuje spousta takových, ale nejsou moc mediálně profláklé.
Hello world ! Segmentation fault (core dumped)
Fluttershy, yay! avatar 18.6.2014 13:54 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Už aby sis začal vyjednávat s Hasbrem, aby v logu mohl být Derpy.
AsciiWolf avatar 18.6.2014 14:24 AsciiWolf | skóre: 39 | blog: Blog
Rozbalit Rozbalit vše Re: PoniDB - Úvod
:-D
18.6.2014 14:29 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Jinak řečeno, někdo chce založit pouhé jednorozměrné pole (single table), na které chce navěsit indexy přes hašovací funkce.

Název „databáze“ to má čistě z reklamních důvodů. Tím spíše je mimo srovnávání s jinými dbms.

„Problém rychlého čtení“ znamená co? Protože hašování neřeší rychlost čtení a ani k tomu není a nikdy nebylo určeno. Hašování řeší POUZE A JEDINĚ rychlé VYHLEDÁNÍ podle hodnoty. Pokud budete mít databázi uloženou na děrných štítcích, pak rychlost čtení je rovna max. rychlosti čtení řádku z děrného štítku. Když budete mít data v paměti, bude to mnohem rychlejší.

Naučte se nejdříve přesně se vyjadřovat, chcete-li dělat revoluce.

Zřejmě nemáte matematický skill ani na to, abyste odlišil rychlost čtení od rychlosti vyhledání dat.

Pro jistotu, až budete hledat data podle jiných kritérií, než hodnota, bude vám hasovací tabulka na dvě věci, které ze zdvořilosti nejmenuji. Takový požadavek vrať data s number > 7, a hašovací funkce je zcela bezmocná.

Obávám se, že kdyby se vzala normální běžná SQL relační databáze, nad tabulkou se vytvořily příslušné indexy a dostala dostatek paměti pro cache, bude to číst mnohem rychleji, než cokoli stvoříte. Ony ty databáze nejsou dělány tak špatně a neefektivně, jak si myslíte. Jsou dělány velmi velmi dobře. I na Váš případ, který uvažujete.

Miloslav Ponkrác
18.6.2014 22:40 kůň
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Hlavně největší síla relačních databází je v systémech s hodně požadavky na čtení a málo požadavky na zápis (prakticky všechny databázové systémy co si člověk představí). NOSQL se začali používat právě kvůli tomu, že tzv. big data všichni pořád zapisují, ale čtou se jenom jednou za čas, když je někdo analyzuje. Takže autor blogu si chytře vybral use case, který bez problémů pokryjí relační databáze (po 40 letech vývoje) a snaží se to udělat jinak a lépe, jenom protože SQL je nad jeho síly.
xkucf03 avatar 19.6.2014 00:18 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Hlavně největší síla relačních databází je v systémech s hodně požadavky na čtení a málo požadavky na zápis (prakticky všechny databázové systémy co si člověk představí).

Tohle se spíš uvádí jako výhoda LDAP serverů (často ve srovnání právě s relačními databázemi). Samozřejmě jde hlavně o to, jak se konkrétní systém nastaví (nemluvě o tom, že ty LDAPy pod sebou taky někdy mají relační databázi).

tzv. big data všichni pořád zapisují, ale čtou se jenom jednou za čas, když je někdo analyzuje

A souvisí tohle až tak s relačním uspořádáním dat? Podle mého je to spíš o spolehlivost – jestliže chci mít transakce a chci mít jistotu, že vložená data se neztratí, tak je potřeba počkat, až se zapíší na disk a pak teprve potvrdit jejich vložení. A tady je úplně jedno, jestli ta data jsou uspořádána relačně, nebo objektově nebo třeba jako XML – ten kus dat prostě musí prolézt skrze systém a zapsat se fyzicky na disk – takže to limituje rychlost disku resp. IOPS.

Když oželíme spolehlivost (zapsaná data budou chvíli jen v RAM, kde se můžou v případě výpadku ztratit) nebo použijeme asynchronní zápis (data se uloží nejdřív do fronty, která není indexovaná a může být rozložená přes hodně disků), tak můžeme mít rychlé zápisy i nad tou relační databází.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
20.6.2014 00:05 kůň
Rozbalit Rozbalit vše Re: PoniDB - Úvod
O tomhle přesně mluví CAP. Když zahodíš transakce, tak bude všechno rychlejší, jenom v některých případech nebudou data dávat smysl. Cachování dat v RAM bez problémů dnešní relační databáze zvládají.
19.6.2014 15:40 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Základním problémem není ani požadavek na zápis/čtení, ale také na konzistenci dat.

Řada NoSQL databází rezignuje na bezpečnost dat zcela, a vlastně ani není jisté, zda se data skutečně zapsala, či zda jsou alespoň v zásadě konzistentní.

Nemluvím ani o tom, že NoSQL jsou velice různorodých typů a konceptů.

V zásadě ve všech sw projektech, tedy nejen databázových strojích, funguje krásná úměra: Čím větší bezpečnost, spolehlivost, konzistence funkce a dat, tím nižší propustnost, rychlost a menší elegance technologických prostředků na to použitých.

---

Linux by byl mnohem jednodušší, kdyby nezajišťoval uživatele a práva a kdokoli by s ním mohl cokoli i bez přihlašování, třeba.

A zcela jistě by se zvýšiula i rychlost zápisu leckam.
xkucf03 avatar 18.6.2014 15:03 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Nechci ti kazit radost, zvlášť když je to tvůj první zápisek tady (jsem rád, že přibývají aktivní uživatelé), ale mám pár převážně kritických připomínek.

Uplně v první fázi to byl opravdu klasický model relační databáze. Tabulky, SQL a všechno, ale už od začátku se mi to nelíbilo, tak jsem všechno smazal, zavřel to a začal přemýšlet znova a hlavně nad tím, co mi vadilo na tom kódu co už jsem měl. Ten kód byl v pohodě a na mě i celkem čistý. Kód mi nevadil, vadilo mi to, že se to zvrhlo v relační databázi.

Pokud možno bych nepsal kód, dokud nemáš jasnou vizi, co to má být, návrh. Vím, že je to těžké, programátor rád píše kód + může být efektivní si připravit něco předem, i když návrh ještě není hotový. Většinou to řeším tak, že píšu kousky komponent nebo bloky kódu, o kterých vím, že tam budou – ale ne nic, co by souviselo s návrhem celého systému, to by byla zbytečná práce, když ještě není jasné, jak ten systém má vypadat. Příklad: vím, že v aplikaci budu potřebovat šifrování, tak si vyzkouším, jak se v daném jazyce/platformě šifruje, tím uspokojí svoji potřebu napsat nějaký kód, ale zároveň nepíšu nic, co bych pak zahodil nebo musel totálně předělat.

Co zahrnuje vytvoření dobré databáze tu popisovat nebudu, protože od toho tu nejsme, jen v rychlosti shrnu všechny kroky. Návrh databáze, jak mnozí vědí, zahrnuje vytvoření reality, návrh relačního schématu, vytvoření podle něj E-R diagramu a pak samotné vytvoření databáze, což zahrnuje víc kroků než jen prosté CREATE DATABASE. Je jedno jak velká je ta databáze, touhle cestou musím projít pokaždé, když něco databázuju.

Existuje tzv. Princip tří architektur (P3A), postupuje se od nejabstraktnějších modelů ke konkrétním:

  • konceptuální
  • technologická
  • implementační

Konceptuální je úplně nejobecnější, nejabstraktnější. Až v té technologické se rozhodneš, zda použít např. relační model nebo objektovou databázi atd. A v té implementační teprve vybereš (případně navrhneš vlastní vývoj) konkrétní software (např. PostgreSQL, eXist).

Tu realitu nevytváříš, ale jen modeluješ – vytváříš nějaký koncept, model, který jí bude přiměřeně přesně a přiměřeně kompletně odpovídat.

Značně frustrující je potom cokoliv měnit

Se změnami bys měl počítat od samého začátku – vývoj softwaru nekončí tím, že vydáš první verzi 1. Nauč se dělat inkrementy, nauč se testovat…

přidání cizího klíče pak může všechno rozbít a já tak utvrzuju zažité klišé, že databázisti jsou nerváci. Minimálně já při tom dost nervní jsem.

Návrh databáze je čistá radost, setkání s dokonalostí. Na rozdíl od jiných činností ve vývoji, kde musíš bojovat s různě nevyzrálými technologiemi/frameworky/knihovnami obsahujícími chyby a různé zákeřnosti.

Jestli jsi nervní, tak patrně proto, že jsi v minulosti udělal špatný návrh a teď to musíš předělávat. Zaměř se na normální formy a jednoduchost, v databázi měj jen čistá data a jen ta, která skutečně potřebuješ. Pak nebudeš mít takové nervy se změnami.

rychlé čtení z databáze

S tímhle relační databáze nemají problém. Stačí správně navrhnout model, nastavit indexy, případně použít materializované pohledy nebo si jinak předem napočítat data, která budeš potřebovat.

není nutný rychlý zápis, ať si dá klidně na čas

Viz výše – během zápisu si můžeš data převést do vhodné struktury pro čtení. Resp. uložit si je jak normalizovaná, tak vedle ještě jednou denormalizovaná pro rychlé čtení. Navíc můžeš mít i rychlý zápis (resp. jeho potvrzení a bezpečné uložení na disk), pokud ti nevadí, že se změny projeví asynchronně – zápisy můžeš rychle řadit do fronty (která bude ovšem transakční a bezpečně uložená na disk) a v jiném procesu je teprve denormalizovat a převádět na tvar vhodný pro čtení. To všechno nad relační databází.

single table, protože to chci co nejjednodušší

Tím ale jen přesuneš tu složitost do aplikace, která má s takovou databází pracovat.

To je ostatně jeden z důvodů vzniku DBMS – aby ta společná složitost byla v databázovém systému (kterých je jen pár) a nemusela být v každé aplikaci (kterých jsou spousty). Znovupoužitelnost.

mohutnost … zbytečně rozsáhlý backend kvůli prkotině, to možná souvisí s tou mohutností

Toho kódu u dnešních (R)DBMS je opravdu celkem hodně, to si člověk jen tak nepřečte (leda sem tam nějakou část, která ho zajímá). Na druhou stranu co se týče rychlosti startu a náročnosti při běhu: i tak robustní systémy se spoustou funkcí jako je PostgreSQL běží velmi rychle a jsou celkem nenáročné.

SQL

Nějaké konkrétní výhrady?

Jak už jsem řekl, data budou uložena do hashovací tabulky perfektním hashováním, protože přepočet kolizí stojí čas a čas je to o co se tu hraje.

Primitivních nerelačních databází/úložišť pro struktury typu klíč/hodnota jsou spousty. Měl by sis udělat nějakou analýzu. Např. si spočítej, kolik řádků kódu tyhle systémy obsahují a za jak dlouho bys to byl schopný napsat ty. A o kolik by to bylo lepší. Jestli to vůbec stojí za to.

Pokud budu chtít opravdu, ale opravdu vysokou rychlost čtení, nezbývá mi nic jiného, než celou databázi držet v paměti, nebo to provozovat na SSD disku.

Celou v paměti můžeš držet i relační databázi a bude to pekelně rychlé.

Protože nejsem jeden z těch majetných, zvolil jsem si jako optimální první možnost

To jako že GB v RAM vyjde levněji než GB na SSD?

a druhou třeba přidat časem, pokud o to bude zájem ze strany uživatelů, if any.

Co znamená přidat podporu SSD? Na jaké úrovni abstrakce se chceš pohybovat? Budeš pracovat se souborovým systémem nebo přímo s blokovým zařízením? Jak vůbec tvoje aplikace pozná, že je to SSD a ne HDD? Bude tam nějaký principiální rozdíl nebo to pro aplikaci bude prostě jen rychlý disk?

Zápis bude ta nejpomalejší věc na tom všem a veškerá úspora rychlosti při čtení se klidně může na zápisu odrazit. Takže asi nebudu vyloženě hrotit nějakou složitost zapisování, nebo počet hashování.

Zvaž ten asynchronní zápis, co jsem popisoval výše – příchozí data uložit nejdřív do logu (bezpečné – už se neztratí, můžeš potvrdit jejich přijetí) a až asynchronně je hashovat a dále zpracovávat a „publikovat“ pro čtení. Parametrem zápisu by mohlo být zda má být synchronní (čtecí operace uvidí nová data hned po potvrzení zápisu, ale bude to pomalejší) nebo asynchronní (rychlejší potvrzení, viditelnost později).

Ano, nepůjdou vytvářet relace, ale od toho tu nejsme, tím bych současnou argumentaci tohohle bodu uzavřel.

Co myslíš slovem relace?

V argumentech zadávat přímo dotaz a výstupem budou čistá data pro snadné parsování v programech.

Takový nástroj jsem si napsal pro SQL/LDAP: SQL-DK.

ale cílem není použít něco existujícího, ale vytvořit něco vlastního.

Takže to má být jen cvičení?

[1] možná tak u webů, kde je často zvykem nasadit nějaký super-moderní-cool web, pak nějakou dobu trpět, pak to celé zahodit a začít znova – ale normální software se takhle nedělá

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
Heron avatar 18.6.2014 15:57 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Takže to má být jen cvičení?

Což je asi ten nejlepší start. Zkusí si to napsat, pochopí, že některé věci jsou mnohem složitější, než se zdá (paralelní čtení, no to ještě jde, ale co takhle paralelní zápisy), zjistí, že hash není všechno a že je daleko podstatnější způsob, jakým je to uloženo na disku (a nakonec i v paměti). Apod. A potom se dostane k již desítky let hotovým projektům, které to mají vše dávno vyřešené (a hlavně bude vědět jak a proč). Takže za mě palec nahoru.

xkucf03 avatar 18.6.2014 15:59 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Což je asi ten nejlepší start.

To je, ale mohl to napsat dřív než v P.S. :-)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
Bystroushaak avatar 18.6.2014 16:15 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: PoniDB - Úvod
To jsem mu psal taky (na IRC), protože to bylo přesně to první, co mě napadlo.
18.6.2014 19:21 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
SQL
Nějaké konkrétní výhrady?
Treba...

nebo

respektive (od 29 minuty)

Jinak je to podrobne rozebrane snad v kazde Datove knizce.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
Fluttershy, yay! avatar 18.6.2014 19:37 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Datove knizce

Chvíli jsem přemýšlel, jestli to mělo být podle vzoru Datová schránka, nebo podle spoluautora Třetího manifesta. @_@

xkucf03 avatar 19.6.2014 10:32 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Jenže ty problémy jsou často už vyřešené (či alespoň řešitelné v rámci SQL) nebo ta Datova kritika spočívá v tom, že SQL nedostatečně využívá potenciálu relačního modelu. Spíš mě zajímala odpověď od toho, kdo chce zavrhnout relační model jako takový. Tyhle výhrady se nedají vyřešit tím, že místo něj začneš používat nějakou hashovací tabulku.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
19.6.2014 11:21 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Datova kritika spočívá v tom, že SQL nedostatečně využívá potenciálu relačního modelu
SQL != relacni databaze. Datova a Darwenova kritika SQL spociva v tom, ze (1) neobsahuje veci z rel. modelu, jak rikas, (2) ma veci mimo rel. model.
Jenže ty problémy jsou často už vyřešené
Nejsou a ani nebudou, protoze jsou nedilnou soucasti jazyka, z tech nejzjevnejsich, napr. NULL, SELECT majici ruzne vyznamy, duplicitni radky, ...
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 19.6.2014 12:19 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Někde tam vytýkají věci, které se týkají jen některých implementací – např. že 'A' = 'A ' ale length('A') < length('A ')

V MySQL:

# sql-dk --db mysql --sql "SELECT :a1 = :a2, length(:a1) = length(:a2)" --data-named a1 'A' a2 'A '
 ╭─────────────────────┬─────────────────────────────────────╮
 │ 'A' = 'A ' (BIGINT) │ length('A') = length('A ') (BIGINT) │
 ├─────────────────────┼─────────────────────────────────────┤
 │                   1 │                                   0 │
 ╰─────────────────────┴─────────────────────────────────────╯
Record count: 1

Ale v PostgreSQL:

# sql-dk --db postgres --sql "SELECT :a1 = :a2, length(:a1) = length(:a2)" --data-named a1 'A' a2 'A '
 ╭─────────────────┬─────────────────╮
 │ ?column? (bool) │ ?column? (bool) │
 ├─────────────────┼─────────────────┤
 │           false │           false │
 ╰─────────────────┴─────────────────╯
Record count: 1

A že když si někdo předefinuje operátor pro rovnost, aby vracel něco jiného než rovnost, a pak to dělá blbosti – tak to bych opět nepovažoval za vadu jazyka, ale za chybu toho, kdo si ten operátor předefinoval.

Ten NULL může být trochu záludný, ale svůj smysl to má – když ho chápeš jako nedefinovanou/neznámou hodnotu, tak nemůžeš říct, že dvě nedefinované hodnoty jsou si rovné – a nemůžeš ani říct, že jsou různé → výsledkem je opět NULL (neznámá hodnota).

# sql-dk --db postgres --sql "SELECT null::text = 123::text, null::text = null::text, null, 123::text"
 ╭─────────────────┬─────────────────┬────────────────────┬─────────────╮
 │ ?column? (bool) │ ?column? (bool) │ ?column? (unknown) │ text (text) │
 ├─────────────────┼─────────────────┼────────────────────┼─────────────┤
 │ null            │ null            │ null               │ 123         │
 ╰─────────────────┴─────────────────┴────────────────────┴─────────────╯
Record count: 1
# sql-dk --db mysql --sql "SELECT null = 123, null = null, null, 123"
 ╭─────────────────────┬──────────────────────┬─────────────┬──────────────╮
 │ null = 123 (BIGINT) │ null = null (BIGINT) │ NULL (NULL) │ 123 (BIGINT) │
 ├─────────────────────┼──────────────────────┼─────────────┼──────────────┤
 │ null                │ null                 │ null        │          123 │
 ╰─────────────────────┴──────────────────────┴─────────────┴──────────────╯
Record count: 1

Maximálně se z té neznámé hodnoty někdy po přetypování na boolean stane false:

# sql-dk --db postgres --sql "SELECT CASE WHEN null THEN 1 ELSE 2 END"
 ╭─────────────╮
 │ case (int4) │
 ├─────────────┤
 │           2 │
 ╰─────────────╯
Record count: 1

Ale to je takový obecný problém: co udělat při převodu ze třístavové hodnoty (true/false/null) na dvoustavovou (true/false). Buď by to mohlo vyhodit výjimku nebo se null převede na false. Možná by ta výjimka byla vhodnější – a pak by bylo potřeba explicitně uvádět, jak chceme null interpretovat – třeba jako true:

# sql-dk --db postgres --sql "SELECT CASE WHEN coalesce(null, true) THEN 1 ELSE 2 END"
 ╭─────────────╮
 │ case (int4) │
 ├─────────────┤
 │           1 │
 ╰─────────────╯
Record count: 1
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
Fluttershy, yay! avatar 19.6.2014 13:00 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Ten NULL může být trochu záludný, ale svůj smysl to má – když ho chápeš jako nedefinovanou/neznámou hodnotu, tak nemůžeš říct, že dvě nedefinované hodnoty jsou si rovné – a nemůžeš ani říct, že jsou různé → výsledkem je opět NULL (neznámá hodnota).

Což je, ehm, ten problém (sémanticky). How to Handle Missing Information without Using NULL

xkucf03 avatar 19.6.2014 13:42 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Tohle jsem teď zrovna četl :-)

Ano, je to sémantický problém – nakonec se ale s tím nějak musíš poprat, bez ohledu na to, zda jsi v jedné tabulce našel atribut s NULL hodnotou, nebo zda jsi v jiné nenašel odpovídající záznam.

NULL má výhodu v tom, že můžeš relativně snadno měnit model a povinnost/nepovinnost určitých atributů (stačí přidat/odebrat NOT NULL u sloupečku). Zatímco bez NULL bys musel zásadně změnit strukturu – tabulka s atributem vs. tabulka bez atributu + atribut v samostatné tabulce – což by vyžadovalo větší změny v kódu aplikací. Nebo bys musel od začátku dávat prakticky každý atribut do samostatné tabulky – ale s tím by asi nikdo nechtěl pracovat…

A někdy je problém, když chceš popsat více stavů/atributů jednou atomickou hodnotou.

Např. máš čtyři stavy:

  • bere určitý plat (pracuje)
  • pracuje, ale má nulový plat
  • nepracuje (není zaměstnaný)
  • nevíme, zda pracuje

ale jen tři možné hodnoty (resp. druhy hodnot):

  • nějaké číslo, XX XXX
  • nula (nebo alternativně prázdný řetězec v případě textu)
  • NULL (případně chybějící záznam)

Nepročetl jsem to ještě úplně důkladně, ale zatím jsem nepochopil, proč jsou SALARY_UNKUNSALARIED samostatné tabulky a ne jen booleovské atributy osob. Jen doufám, že tím důvodem nebylo to, aby mohli v závěru zkritizovat SQL za to, že neumožní vložit jednotlivě záznamy do tabulek (resp. je potřeba použít odložené kontroly integrity – až při dokončení transakce). Aby měla každá osoba uvedený plat nebo příznak SALARY_UNK či UNSALARIED (právě jednu z těchto tří možností), jde zajistit i omezením na úrovni tabulky – není potřeba to rozbít na několik tabulek (a dokonce je to i uživatelsky přívětivější).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
Fluttershy, yay! avatar 19.6.2014 13:51 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
což by vyžadovalo větší změny v kódu aplikací. Nebo bys musel od začátku dávat prakticky každý atribut do samostatné tabulky – ale s tím by asi nikdo nechtěl pracovat…

Úder hlavičky na hřebíček. Knocked out.

Nedávno jsem viděl infografiku, která "vysvětlovala" přirozené spojení a odvozené operace v SQL pomocí Vennových diagramů – úplně blbě. Dostalo to hodně přes tři tisíce upboatů v /r/programming.

20.6.2014 11:03 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Nic proti, ale uvedený příklad mixuje do jednoho pole dvě různé položky, které spolu mohou, ale nemusí souviset. Práce nezaručuje vyplácení mzdy a vyplácení mzdy nemusí být podmíněno prací. Je-li tedy taková tabulka podkladem pro vyplácení sociálních dávek, tak by mělo být primárním klíčem to, jestli někdo dostává nějaké peníze a teprve sekundárním jestli je zaměstnaný, nebo ne.
19.6.2014 15:21 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Tady je základní filozofický problém, týkající se relačních databází, SQL i NULL.

Ten základní problém je, že zkritizovat jde všechno. DOkonalé (ve významu všem vyhovující) věci jsou jenom tehdy, pokud neexistují, či jsou pouze v plánu, ale ne realizované.

Navíc řada lidí je nesoudná natolik (asi tak 99,9999 % lidí), že i v existujících věcech zaměňuje koncept i implementaci. Což se často děje při kritice relačních databází, stejně jako SQL.

Když budete chtít, já vám zkritizuji úplně všechno a na všem najdu mouchy, pokud to reálně existuje. A je jedno, jestli je to SQL nebo NoSQL, relační koncept databází či jiný koncept, atd. Cokoli si vyberete.

Na otázku „Co je špatné na (reálně existujícím) X?“, lze vždy najít nějaký dokument či ho napsat.

Smiřte se s tím, že dokonalé věci v realitě neexistují.

---

SQL jednoduše umožňují mít NULL hodnotu, kterou si můžete interpretovat a použív v jakémkoli významu chcete. A nebo nepoužít vůbec.

Stejně tak SQL jazyk je takový jaký je, ale nikdo nic lepšího masově neimplementoval (záměrně nepoužívám sloveso nevymyslel).

Nic není dokonalé. A nikdy nic dokonalé nebude.

Takže je třeba se spíše ptát, zda je dobře implementované, praktické, a zda to umí, vše co potřebujeme. A to stačí.

Kdokoli může udělat a prosadit něco lepšího, ale jakmile to zrealizuje, pak zjistí, že to není dokonalé, a někdo proti tomu píše dokumenty, proč je to špatné.
22.6.2014 02:18 pavel
Rozbalit Rozbalit vše Re: PoniDB - Úvod
+1
19.6.2014 15:05 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Ale v PostgreSQL:
Typ text neodpovida standardu SQL. Ten problem se tyka typu char.
Ten NULL může být trochu záludný, ale svůj smysl to má – když ho chápeš jako nedefinovanou/neznámou hodnotu,
Tady uz mas problem hned na zacatku. Jaky je vlastne smysl NULL? Je to NULL nedefinovana, nebo neznama hodnota?
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
19.6.2014 15:29 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Ač normálně na deda.jablko nereaguji, a pokud se dozvím nějakou ujetinu opět nebudu dále reagovat:

„Tady uz mas problem hned na zacatku. Jaky je vlastne smysl NULL? Je to NULL nedefinovana, nebo neznama hodnota?“

NULL je další možná hodnota dat. Tečka. Nic více, nic méně. Jejím smyslem je v první řadě být další možnou hodnotu v datech. Konec definice NULL.

Podle praktického použití se může NULL použít jako neinicializovaná proměnná, nedefinovaná hodnota, neznámá hodnota, nebo prostě jen jako jedna z možných hodnot.

19.6.2014 16:48 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
NULL je další možná hodnota dat. Tečka. Nic více, nic méně. Jejím smyslem je v první řadě být další možnou hodnotu v datech. Konec definice NULL.
Joooo... kdyby byl svet tak jednoduchy... S touto definici by nesouhlasil ani E.F.Codd ani kdokoliv, kdo do databazi trochu vidi. Ve skutecnosti NULL neni hodnota, ale priznak absence hodnoty, tedy nemuze to byt hodnota. Fakt, ze NULL neni hodnota, lze overit treba pomoci NULL = NULL.

Doporucuji si rozsirit obzory a precist treba: C.J.Date: SQL and Relational Theory: How to Write Accurate SQL Code
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
19.6.2014 17:08 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Vidím, že jste na velmi tenké půdě, když svou pravdu potřebujete podepřít „autoritou“ a knihou.

Jenže já s Vámi ostře nesouhlasím. A budu s Vámi nesouhlasit i když si přečtu nejen Vámi doporučenou knihu. A pokud kniha budete tvrdit, že NULL není hodnota, budu ostře nesouhlasit i s knihou.

1) NULL je hodnota, a proti tomu můžete protestovat jak chcete, kde chcete, protože je to hodnota.

2) Výsledky různých operací s hodnotami mohou být jakékoli hodnoty, protože jde jen o to, jak se to nadefinuje.

Nic na tom nemění fakt, že binární operace „=“ není ekvivalencí v matematickém smyslu, protože tato binární operace není reflexivní.

Miloslav Ponkrác
19.6.2014 17:58 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Vidím, že jste na velmi tenké půdě, když svou pravdu potřebujete podepřít „autoritou“ a knihou.
Nikoliv, narozdil (treba od astrologu) jsem schopen dokladat skutecnosti i na zaklade relevantnich zdroju.

Mimochodem, s tou autoritou v uvozovkach se jen ztrapnujete.

Nic na tom nemění fakt, že binární operace „=“ není ekvivalencí v matematickém smyslu, protože tato binární operace není reflexivní.
Tak tohle je fakt konecna. Co bude dal? Komutativni implikace?
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
19.6.2014 20:01 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Jděte se zdroji do háje. Já Vám na každou ptákovinu, i sebevětší blbost najdu zdroj, který bude tvrdit, že je to ta největší pravda. Papír snese všechno.

Já jsem ve svých příspěvcích nepoužil žádný odkaz, neskrýval jsem se za žádnou knížku, za žádného třetího člověka, vše bylo samovysvětlující. Nepotřebuji se za nikoho skrývat, buď vím, proč věci tvrdím, nebo lžu. Nic jiného neberu a dělám to tak roky.

Pochopil jsem Vaše argumenty, proč NULL ne, zvážil jsem je, a nesouhlasím s Vámi.

NULL je jednoduše speciální hodnota, nic jiného. V rámci SQL existuje předem daná algebra, zahrnující i NULL hodnotu. Protože NULL je asymetrická, i některé párové funkce dávají jiné výsledky, pokud se připletou do toho NULL hodnoty, tak je algebra definována. Tedy „+“ a „SUM“, které bylo v jiném výsledku, atd.

Můj názor je, že pro PRAXI je existence NULL mnohem lepší, než její neexistence. Je úplně egál, jestli se někomu líbí či ne. Jediné, co se počítá, zda někdo vymyslí lepší algebru (třeba bez NULL), která ovšem neztratí dobré vlastnosti a bude jednodušší a praktičtější. A tady zatím všichni narazili. Stejně jako Vy, stejně jako Codd a další – akademicky debatují, jak NULL je ošklivé, ale nikdo nikdy ještě praktičtější algebru nad relačními databázemi neimplementoval. Kdokoli to může udělat a konkurenčně lepšími vlastnostmi současnou SQL algenbru vyšachovat.

Teorie i papír jsou krásné věci, nažvanit se toho dá mnoho. Jenže už jsem viděl mnoho „čistých a dokonale konzistentních věcí“ počínaje „dokonalým SQL bez NULL“, „dokonale čistým OOP“, „dokonale čistými programovacími OOP jazyky“ atd. atd. – a všechno to v praxi selhalo. Protože praxe je nemilosrdná.

Zdrojů můžete napsat kolik chcete, protože papír je jenom ta teorie.

Howgh.

Miloslav Ponkrác
19.6.2014 20:30 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Jděte se zdroji do háje.
Ano.
vše bylo samovysvětlující.
Ne, nebylo. Rekl jste, ze NULL je hodnota a basta.

V rámci SQL existuje předem daná algebra, zahrnující i NULL hodnotu. Protože NULL je asymetrická, i některé párové funkce dávají jiné výsledky, pokud se připletou do toho NULL hodnoty, tak je algebra definována. Tedy „+“ a „SUM“, které bylo v jiném výsledku, atd.
Tady hazete pojmama, ktere nedavaji smysl. V astrologicke poradne to mozna zabira, na me ne.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 19.6.2014 15:36 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

To je v tomhle kontextu celkem jedno – tak ani tak nemůžeš null interpretovat jako true nebo false, může to být potenciálně obojí. Asi by bylo lepší, se toho držet a za žádných okolností takovou interpretaci/přetypování nepřipustit → mělo by to vyhodit výjimku, pokud nelze jinak – v opačném případě explicitně uvedeš, co null znamená: coalesce(null, jeho_hodnota).

Vím, že těch významů může být víc (neznámá hodnota vs. nic atd.), musíš si prostě jeden vybrat a tak se k tomu NULL v aplikaci chovat.

Nebo by bylo lepší mít vedle NULL ještě další symboly jako ?, * atd.?

Pořád mi přijde pro uživatele stravitelnější, když mají v nějakém sloupečku sem tam NULL, než kdyby měli model rozpadlý na milion tabulek a museli je neustále propojovat. BTW: co by se v těch sloupečcích po propojení tabulek zobrazovalo v případě neexistence odpovídajícího záznamu v druhé tabulce, když bychom neměli NULL? Bylo by takové spojení nemožné a bylo by potřeba položit víc dotazů a data si poskládat až v aplikaci?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
19.6.2014 16:02 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
NULL je to samé, co ve floating point číslech NaN.

NULL i NaN je jednoduše speciální hodnota, kde operace nad ní jsou voleny tak, aby tato hodnota propagovala skrze výrazy a výpočty do popředí, je-li to možné.

Díky tomu, že existuje NULL (v databázích) a NaN (ve fpu) má každá – i chybná operace – definovaný výsledek. Díky těmto speciálním hodnotám jsou všechny funkce a operace vždy dobře definované a vždy dávají výslednou hodnotu.

A díky dobře definovaným funkcím a operacím je možné vždy pokračovat, a není nutné neustále vše považovat za chybu.

Hlavně v hromadných operacích nad množinou dat se chyby indikují a vracejí dost špatně, protože část dat je ok, část má indikovat chybu. Dosazení speciální hodnoty je ideální řešení.

Nemluvě o tom, že je jednodušší vrátit NULL hodnotu, než nutit a znásilňovat programátory do if/then/else chybové kontroly po každé operaci. Zrovna u procedurálních jazyků tahle chybová kontrola to celé dost zatemní, a také velmi zpomalí celé zpracování.

Takže je možné používat i nepoužívat NULL/NaN dle chuti každého soudruha. Nikdo nikomu násilím nenutí ve své databázi použít byť jediné NULL.

Stejně tak je to neocenitelné v relacích (což je také druh operace), kde je lépe něco vrátit.

Díky hodnotám NULL a NaN jsme dosáhli situace, kdy na celém prostoru možných hodnot v databázi se všechny operace zobrazují pouze do prostoru možných hodnot v databázi a nikdy jinak. Což je obrovská deviza pro celé zacházení s daty.

Díky tomu, co jsem popsal v předchozím odstavci, se to celé matematicky velmi výrazně zjednodušilo. Stejně tak jako všechny operace.

A to je důvod, proč lidé opakovaně a opakovaně navrhují speciální hodnotu do mnohých standardů. Proč je v SQL hodnota NULL, proč je v IEEE 754 hodnota NaN, a proč to ještě v tisíci dalších standardech udělají.

Miloslav Ponkrác
19.6.2014 17:05 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
NULL je to samé, co ve floating point číslech NaN
Neni. Viz vyse;
Díky tomu, že existuje NULL (v databázích) a NaN (ve fpu) má každá – i chybná operace – definovaný výsledek. Díky těmto speciálním hodnotám jsou všechny funkce a operace vždy dobře definované a vždy dávají výslednou hodnotu.
Vazne?
SELECT 1 + NULL; -> NULL

CREATE TABLE foo (a int);
INSERT foo VALUES (1);
INSERT foo VALUES (NULL);

SELECT sum(a) FROM foo; -> 1
Díky tomu, co jsem popsal v předchozím odstavci, se to celé matematicky velmi výrazně zjednodušilo. Stejně tak jako všechny operace.
Nerekl bych, protoze 3VL rozbiji rel. model, na kterem jsou rel. db postaveny. Treba neplati (R JOIN R) = R.

Lze overit treba na vyse uvedene tabulce:
SELECT * FROM foo f1 NATURAL JOIN foo f2;
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
19.6.2014 17:21 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Nějak jsem nepochopil, v čem se mnou nesouhlasíte. Protože nevidím jediný rozpor s tím, co jsem napsal výše.

Prostě to, že máte neflexibilní mozek, který Vám říká, že operace „+“ a skupinová funkce „SUM“ musí počítat to samé, za to já opravdu nemohu.

Jednoduše některé operace mají záměrně vlastnosti jaké mají, protože se tím sleduje nějaký konkrétní cíl a konkrétní vlastnosti celé algebry nad hodnotami.

„Problém s SQL a NULL“ je politicko-korektní název pro Váš subjektivní názor, že byste rád jinou algebru, kterou považujete za lepší (tedy Váš subjektivní názor, který se neobtěžujete nějak průkazněji dokázat, pouze ho předkládáte jako fakt).

---

Každé zvolené řešení, tedy každá algebra, bude v něčem šikovnější, a v něčem drhnout. S důrazem na slovo každá.

Osobně si myslím, že existence i chování typu NULL je zvoleno v databázích velmi dobře po praktické stránce použití. Upřímně řečeno si nedokáži představit, jak by se řada situací řešily prakticky rozumně (s důrazem na slova prakticky a rozumně) situace, kdy operace nemá žádný výsledek, protože jde o chybu.

Miloslav Ponkrác
19.6.2014 18:13 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Nějak jsem nepochopil, v čem se mnou nesouhlasíte.

Nesouhlasil jsem s:

operace vždy dobře definované a vždy dávají výslednou hodnotu.

máte neflexibilní mozek, který Vám říká, že operace „+“ a skupinová funkce „SUM“
Omlouvam se, priste uz zadna cisla scitat nebudu.

Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 19.6.2014 18:49 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Omlouvam se, priste uz zadna cisla scitat nebudu.

Je přece rozdíl, když a) sčítám celou tabulku, kde jsem si definoval, že sloupec není NOT NULL a tudíž v něm můžou být chybějící hodnoty, a tím, když b) explicitně říkám, že chci sečíst dvě čísla/proměnné a jedno z nich je NULL.

V případě a) čekám, že se chybějící hodnoty přeskočí, zatímco v případě b) je fakt divné, že bych chtěl sčítat třeba 1 a NULL a je dobře, že výsledkem je NULL a všimnu si toho – dostanu nedefinovanou hodnotu.

Pokud ti tohle chování přijde divné nebo ho nechápeš, nikdo ti přece nebrání si všechny sloupce nadefinovat jako NOT NULL a/nebo používat coalesce(potenciálně_null_proměnná, hodnota_pro_případ_null).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
19.6.2014 19:05 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Pokud ti tohle chování přijde divné nebo ho nechápeš,
To neni podstatne.

Jde o to, ze ani v tak banalni situaci jako je scitani cisel se SQL nechova konzistentne.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
19.6.2014 19:36 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Chová se to naprosto konzistentně.

Všechny agregované funkce v SQL berou v úvahu pouze nonNULL hodnoty. (A to včetně agregační funkce COUNT(*), protože zde se za každý existující řádek bere hodnota 1, takže zde NULL hodnota nemůže nastat.) Pokud budete tedy sčítat pomocí SUM, či pomocí binární operace +, dostanete stejný výsledek.

Jinak řečeno, je to naprosto konzistentně a přesně definované.

xkucf03 avatar 19.6.2014 19:52 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Jsou to jiné funkce/operace, tak je i výsledek jiný:

$ sql-dk --db blog --sql "SELECT sum(hodnoty) FROM (SELECT unnest(array[1,2,null,3]) AS hodnoty) AS x"
 ╭────────────╮
 │ sum (int8) │
 ├────────────┤
 │          6 │
 ╰────────────╯
Record count: 1

$ sql-dk --db blog --sql "SELECT 1 + 2 + NULL + 3"
 ╭─────────────────╮
 │ ?column? (int4) │
 ├─────────────────┤
 │ null            │
 ╰─────────────────╯
Record count: 1

Jestli chceš sečíst jen neNULLové hodnoty a NULL přeskakovat, tak to dělej tím prvním způsobem. Jestli chceš jen sečíst čísla, tak to dělej tím druhým. Tam by naopak bylo velmi zákeřné, kdyby se NULL chovalo stejně jako 0 a v tichosti se to na ni převedlo.

V obou případech je kdesi uvnitř obyčejné sčítání, ale funkce sum() je i něco víc než jen pouhé a + b + c + ….

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
19.6.2014 20:21 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Jsou to jiné funkce/operace
To ja pochopitelne vim. Ukazal jsi ten muj priklad jen s vice hodnotami. Mne vadi, ze ty dve operace se nechovaji vzajemne konzistentne. Konzistentni by bylo, aby SUM pri vyskytu NULL vracelo taky NULL jako scitani.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 19.6.2014 21:21 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Konzistentni by bylo, aby SUM pri vyskytu NULL vracelo taky NULL jako scitani.

Taková funkce by klidně mohla existovat, akorát by se asi moc nepoužívala. Stejně tak by mohl existovat operátor pro sčítání, který by NULL nahradil nulou a v tichosti přičetl. Opět by to asi nikdo nepoužíval. Ale můžeš si takové funkce/operátory vytvořit. Standardně tam máš prostě věci, které dávají smysl a které se budou používat.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
19.6.2014 22:02 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Jsou to jiné funkce/operace, tak je i výsledek jiný:

sum(a, b) != a + b ? Sorry, ale to při nejlepší vůli není konzistence, to má deda.jabko naprostou pravdu...
xkucf03 avatar 19.6.2014 22:28 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Přesně tak, jsou to jiné funkce. Když si dáš tu práci a ručně vyjmenuješ a + b + c + d + …, tak proč bys tam cpal NULL? Leda omylem! A pak je správně že i na výstupu vyleze NULL.

Něco jiného je, když sčítáš hodnoty z celé tabulky, kde můžou některé hodnoty chybět – to je legitimní stav a předpokládá se, že chceš sečíst jen ty, které tam jsou a prázdná místa přeskočit.

Co se týče konzistence – tu tady nemá cenu řešit – je to jako kdybys řešil (ne)konzistenci sčítání a násobení a divil se, že dávají jiné výsledky – ano, protože to jsou jiné funkce. Konzistenci smysl řešit v otázkách typu: chovají se všechny agregační funkce k NULL stejně? Nebo: chová se +,-,*,/ k NULL stejně?

Když se vrátím ještě k tomu a + b + c + d + …, pokud víš, že tam budeš dávat i NULL hodnoty a chceš je přeskakovat, tak to tomu SQL řekni:

SELECT 1 + coalesce(NULL, 0)

nebo třeba:

SELECT sum(hodnoty) FROM (SELECT unnest(array[1,null]) AS hodnoty) AS x
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
Fluttershy, yay! avatar 19.6.2014 22:35 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
O_o°
xkucf03 avatar 19.6.2014 22:53 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Co je to za smajlíka? Magnetofon s tlačítkem?

BTW: co ti dá za výsledek 1 + ∞ ?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
Fluttershy, yay! avatar 19.6.2014 23:50 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Vytřeštěné zraky a kapička potu, objevivší se na spánku. To byl přesně můj výraz, když jsem to četl. Ještě mi spadla čelist a vzduch byl proťat zděšeným výkřikem: "INŽENÝR!!!1!"
Fluttershy, yay! avatar 19.6.2014 23:57 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
A abych to doplnil, tak
Něco jiného je, když sčítáš hodnoty z celé tabulky, kde můžou některé hodnoty chybět – to je legitimní stav a předpokládá se, že chceš sečíst jen ty, které tam jsou a prázdná místa přeskočit.

Agregační funkce. Funkce. Zobrazení.

xkucf03 avatar 20.6.2014 01:10 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Tak znovu: co ti dá za výsledek 1 + ∞ ? Podobné je to s tím NULL.

Kdyby byla funkce sum() jen primitivní sčítání, tak by taky měla vracet NULL, pokud by se někde mezi výsledky objevilo. Ale taková funkce by byla na nic a téměř nikdo by ji nepoužíval – když agregujeme nebo třeba počítáme průměr, zajímají nás známé hodnoty a ty chybějící přeskočíme. Dosadit za neznámé hodnoty nulu by byla chyba – např. ten průměr by nám vyšel úplně jinak, blbě.

Oproti tomu sčítání pomocí operátoru + propaguje NULL hodnotu do výsledku. Dejme tomu, že máme tabulku platů a u některých lidí máme NULL – nevíme, kolik berou. A teď někdo rozhodne, že všem přidá deset korun. Kdyby výsledkem 10 + NULL bylo totéž co 10 + 0, bral by teď ten člověk jen 10 Kč, místo přidání by si patrně hodně pohoršil. Zmizela by ta informace „nevíme kolik bere“ a místo ní bychom zapsali určitou, ale nesmyslnou hodnotu. Pravda je ale taková, že stále nevíme, kolik ten člověk bere – proto je výsledkem takového součtu NULL – jen víme, že má mít teď o 10 víc, ale to je celkem irelevantní, protože nevíme, kolik měl předtím → takže prostě stále NULL, neznámá hodnota.

To SQL je navrženo i s ohledem na praktické použití – není to jen teoretické cvičení, byť by se to některým líbilo. Někdo by třeba chtěl funkce pro medián a průměr vracející nesmysly nebo třeba zákeřný operátor + požírající informace o tom, že hodnota chybí, a dosazující v tichosti nuly… ale naštěstí to funguje jinak.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
20.6.2014 01:35 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Kdyby byla funkce sum() jen primitivní sčítání, tak by taky měla vracet NULL, pokud by se někde mezi výsledky objevilo. Ale taková funkce by byla na nic a téměř nikdo by ji nepoužíval – když agregujeme nebo třeba počítáme průměr, zajímají nás známé hodnoty a ty chybějící přeskočíme.
Proc by ji nepouzival? Ono v SQL nejde udelat:
SELECT sum(x) FROM foo WHERE x IS NOT NULL? 
Jasne to rika, co se ma udelat a nemusi se predpokladat, ze sum se chova jinak nez bezne scitani.
Oproti tomu sčítání pomocí operátoru + propaguje NULL hodnotu do výsledku. Dejme tomu, že máme tabulku platů a u některých lidí máme NULL – nevíme, kolik berou. A teď někdo rozhodne, že všem přidá deset korun. Kdyby výsledkem 10 + NULL bylo totéž co 10 + 0, bral by teď ten člověk jen 10 Kč, místo přidání by si patrně hodně pohoršil.
Někdo by třeba chtěl funkce pro medián a průměr vracející nesmysly nebo třeba zákeřný operátor + požírající informace o tom, že hodnota chybí, a dosazující v tichosti nuly…
Tohle je straw man, tohle tady nikdo nechce.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 20.6.2014 01:55 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod
SELECT sum(x) FROM foo WHERE x IS NOT NULL?
Jasne to rika, co se ma udelat a nemusi se predpokladat, ze sum se chova jinak nez bezne scitani.

Vedle toho sum(x) můžeš chtít počítat i jiné agregace (jiné funkce nebo nad jinými sloupci, které jsou děravé v jiných místech). Se současnými funkcemi to zvládneš na jeden průchod tabulkou. V tom „čistějším“ řešení bys musel položit víc dotazů, bylo by to nepraktické.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
20.6.2014 09:37 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Se současnými funkcemi to zvládneš na jeden průchod tabulkou.
Nedava smysl zaobirat se timto problemem, jelikoz SQL nikde nerika, jak ma byt dotaz zpracovan.
V tom „čistějším“ řešení bys musel položit víc dotazů, bylo by to nepraktické.
Tak bys mel vic poddotazu, ktere pocitaji presne to, co chces, misto toho, co si nekde myslel, ze asi budes chtit. Optimalizator si to uz prebere.

Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 20.6.2014 09:55 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Takže bych napsal třeba:

SELECT
    (SELECT sum(sloupec1) FROM tabulka WHERE sloupec1 IS NOT NULL),
    (SELECT sum(sloupec2) FROM tabulka WHERE sloupec2 IS NOT NULL);

místo:

SELECT sum(sloupec1), sum(sloupec2) FROM tabulka;

Myslíš, že o takové „zlepšení jazyka“ někdo stojí?

IMHO by velice rychle někdo napsal funkci sum_skip_nulls() a ten původní sum() by nikdo nepoužíval. Což asi autory napadlo hned na začátku, takže napsali funkci sum_skip_nulls() a pojmenovali ji sum().

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
20.6.2014 12:53 dementni.lojzik | skóre: 19 | blog: ze zivota na vsi
Rozbalit Rozbalit vše Re: PoniDB - Úvod

BTW: co ti dá za výsledek 1 + ∞ ?

ja teda tu diskuzi moc pozorne necelt, ale nespocivala kritika dedy.jabka mimo jine v tom, ze NULL je jakysi specialni objekt/hotnota/whatever, prave neco jako ∞?
xkucf03 avatar 20.6.2014 13:44 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Ano, je speciální, ale matematici taky pracují s ∞.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
20.6.2014 10:14 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Přesně tak, jsou to jiné funkce.
Co jsem se koukal naposled, tak suma a sčítání je jedno a totéž. Rozumím tomu, že v SQL tomu tak není, ale to neznamená, že to nekonzistetní není a že to není bordel. Je to bordel :-D

Ten bordel vznikl pochybným přejmutím NULL z programovacích jazyků jako C, kde NULL = 0, tzn. např. 'null character' a 'null pointer', vždy ale platilo, že NULL = 0. V SQL se NULL přisuzuje různý "magický" význam citlivý na kontextu, což není zrovna štastné řešení.

Pdobně ne-moc-smysluplné je použití null v Javě, kde v žádném případě pointery nemají (pointer? fuj!), ale null a null pointer, pardon, referenci mají :-D

Imho docela hezkým příkladem, jak se vyhnout použití null, je Option v jazyce Rust (případně Result a další, podle kontextu).
xkucf03 avatar 20.6.2014 11:18 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Rozhodně nelze předpokládat, že NULL = 0. To by nevadilo možná tak u toho sčítání, ale jakmile začneš počítat průměry, mediány atd., máš problém.

Možná by se někdy hodilo, kdyby ty agregační funkce vracely složenou hodnotu, která by obsahovala:

  • samotný výsledek (součet, průměr atd.)
  • míru nejistoty (podíl NULL hodnot na vstupu)

ale to spíš tak pro zajímavost.

Ono to konzistentní je, v rámci skupin: agregační funkce vs. matematické operátory. Že zrovna sum()+ mají k sobě blízko a někteří lidé si to pletou… to je okrajová záležitost – je to jedna z mnoha funkcí a jeden z mnoha operátorů. Spíš náhodná podoba.

Jak bys tu údajnou nekonzistenci chtěl vyřešit?

  1. matematický operátor bude požírat NULL a dělat z nich nuly
  2. agregační funkce bude vyhazovat NULL (jedna chybějící hodnota na vstupu ti zruší celý výpočet)
  3. NULL nebude vůbec existovat

Proč je špatně 1) je vysvětlené tady: #88 a proč 2) tady: #92. Dává dobrý smysl, proč je to tak, jak to je.

S tou 3) je to trochu složitější, ale v zásadě jde o to, že neexistence NULL by přinesla více problémů, než by vyřešila. Jednak by to bylo uživatelsky dost nepřívětivé, viz #29. A jednak by to byl v podstatě odklon od relací a příklon spíš k nějakým objektovým databázím, viz #62 – výsledkem dotazu by nebyla relace ale jakási stromová struktura…1 A znamenalo by to vlastně mít typované2 NULL hodnoty (kterým by se ovšem nesmělo říkat NULL) aneb prázdné zanořené relace, viz #62.

Nakonec se s tou prázdnotou (chybějící hodnotou) musíš nějak vyrovnat – bez ohledu na to, zda byla vyjádřena ve formě NULL hodnoty, nebo prázdné relace – např. když budeš počítat absolutní hodnotu a na vstupu dostaneš prázdnou relaci (místo NULL), co bude na výstupu? Opět prázdná relace? Nebo nula? Nebo vyhodíš výjimku? Jak je vidět, použití prázdných relací místo NULL nic neřeší. Naopak jen přidává další složitost – taková prázdnota může být navíc vnitřně strukturovaná, zatímco u těch NULL hodnot jsme omezeni více méně na primitivní datové typy.

[1] což přiznávám, je mi svým způsobem i trochu sympatické, protože by to umožnilo pracovat s vnořenými strukturami jednotným způsobem, zatímco teď musím používat různé funkce, podle toho, zda pracuji s polem, s XML, s JSONem atd.
[2] ve skutečnosti jsou typované už teď, ale těch typů je méně resp. nemívají tak složitou strukturu – např. SELECT null::int4 vrací sloupec typu int4 a NULL hodnotou

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
20.6.2014 13:42 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Rozhodně nelze předpokládat, že NULL = 0.
V kontextu SQL určitě ne - už z toho je IMHO vidět nešťastné pojmenování NULL.
Jak bys tu údajnou nekonzistenci chtěl vyřešit?
Tak, jak jsem naznačil těmi odkazy, tzn. nepoužít jeden NULL na všechny případy, kdy hodnota je neplatná, nemáme ji, není použitelná atd., ale použít zvlášť pro každý z těch případů typ s dobře definovaným chováním. Pro začátek třeba trojice NotPresent, NotApplicable a Invalid, s tím, že by se nepřetypovávaly automaticky na čísla.
xkucf03 avatar 20.6.2014 14:48 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Rozhodně nelze předpokládat, že NULL = 0.

V kontextu SQL určitě ne - už z toho je IMHO vidět nešťastné pojmenování NULL.

NULL != ZERO a vlastně nikde mi nepřijde dobré zaměňovat NULL a 0, jsou to úplně jiné věci. Např. když budu mít na skladě 0 položek, tak vím, že tam žádné nejsou; ale když tam budu mít NULL položek, tak vím, že nic nevím :-)

nepoužít jeden NULL na všechny případy, kdy hodnota je neplatná, nemáme ji, není použitelná atd., ale použít zvlášť pro každý z těch případů typ s dobře definovaným chováním. Pro začátek třeba trojice NotPresent, NotApplicable a Invalid, s tím, že by se nepřetypovávaly automaticky na čísla.

Takže vlastně problém není v tom, že SQL má speciální typ NULL navíc, ale že má těch speciálních typů málo? :-)

Na jednu stranu to zní dobře, umožňovalo by to popsat víc speciálních stavů a už se to celkem blíží výjimkám, ale na druhou stranu mám obavu, že by to systém příliš zesložitilo.

Ty speciální hodnoty by byly globální nebo by si je mohl definovat uživatel?

Ať tak či tak, co by bylo výsledkem operací:

SELECT 1 + 2 + NotPresent + 3 + NotApplicable + Invalid + 4;

nebo:

SELECT sum(unnest) FROM unnest(array [1, 2, NotPresent, 3, NotApplicable, Invalid, 4]);

? Jak bys sloučil více speciálních hodnot na vstupu do jedné hodnoty na výstupu?

Měly by tyhle speciální hodnoty nějaký společný nadtyp nebo bych je musel ve všech funkcích ošetřovat jednotlivě?

Pokud by byly uživatelsky definované, mohl bych vytvořit např. typ/doménu: „všechna kladná čísla + 0 + NotPresent + Invalid“, což by se mohlo někdy hodit. Ale jak bych s tím pak pracoval ve standardních funkcích – např. bych chtěl sečíst hodnoty nebo spočítat druhou mocninu? Jak by ta funkce věděla, co má dělat v případě NotPresent a co v případě Invalid?

Ten společný nadtyp by byl asi nutnost – a mohli bychom mu říkat NULL :-)

P.S. ještě k tomu Option v Rustu – je to zajímavé, ale řeší to trochu jiný problém – není to zrušení NULL (jen se mu říká None), ale užitečné je to pro signalizaci, zda hodnota může nebo nemůže být NULL. A k tomu se v SQL používá NOT NULL u sloupců nebo třeba anotace @NotNull v některých programovacích jazycích/frameworcích.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
Fluttershy, yay! avatar 20.6.2014 15:00 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Nebyla náhodou smyslem zavedení relačního modelu mj. eliminace ukazatelů? Nesmrdí NULL ukazateli?

Není náhodou agregační funkce v tom modelu zobrazení? Jak se hledá obraz, když vzor neexistuje?

Nemají náhodou podle toho modelu být hodnoty z dané domény, ve které ale NULL jaksi není?
20.6.2014 22:15 WNJ
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Nebyla náhodou smyslem zavedení relačního modelu mj. eliminace ukazatelů? Nesmrdí NULL ukazateli?
No, ani ne. NULL je hodnota, ktera neni znama/vyplnena/definovana. Mozna ze pro aplikacniho programatora nedava smysl (zvlast pokud jsi zvykly na C), ale treba v Haskellu nebo Ocamlu se bezne pracuje s tim, ze nektere hodnoty jsou volitelne, a ten jazyk na to ma konstrukty. SQL na to taky ma konstrukty.
Není náhodou agregační funkce v tom modelu zobrazení? Jak se hledá obraz, když vzor neexistuje?
Moc nerozumim, co se snazis rict. Obraz se hleda uplne stejne pro NULL jako pro jakoukoli jinou hodnotu.

Muzes to brat tak, ze agregacni funkce nahrazuji NULL za vhodny neutralni prvek podle sveho typu.
Nemají náhodou podle toho modelu být hodnoty z dané domény, ve které ale NULL jaksi není?
NULL v te domene byt muze nebo nemusi. "bla number not null" ho v domene nema. "bla number" ho v domene ma. Je to tvoje volba. Pokud reknes ze dany slopec povoluje hodnotu typu NULL, ma pak domenu jeho typ + NULL, podobne jako muzes rozsirit realna cisla o nekonecna, pokud se ti to hodi. Neni prekvapive, ze se to casto hodi.

Osobne se mi to, jak to delaji silne typovane funkcionalni jazyky libi vic, pokud je nejaka hodnota volitelna, musis ji explicitne vybalit a definovat co se stane. SQL je trochu dynamictejsi, takze dela nejaka pretypovani za chodu, coz je trochu zmatenejsi, ale zas praktictejsi na takove to bezne pouzivani.
Fluttershy, yay! avatar 20.6.2014 22:59 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Háček je, že jsem neměl na mysli SQL (jakožto implementaci).
20.6.2014 17:51 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Takže vlastně problém není v tom, že SQL má speciální typ NULL navíc, ale že má těch speciálních typů málo? :-)
No tak svým způsobem jo, resp. ten problém je, že NULL používá pro více specielních věcí, kde pokaždé má potenciálně jiné chování...
Ty speciální hodnoty by byly globální nebo by si je mohl definovat uživatel? Měly by tyhle speciální hodnoty nějaký společný nadtyp nebo bych je musel ve všech funkcích ošetřovat jednotlivě?
Nevím. Nemůžeš od jednoho mého komentáře chtít specifikaci nového SQL standardu ;-)
SELECT 1 + 2 + NotPresent + 3 + NotApplicable + Invalid + 4;
Protože Invalid signalizuje chybu, propagoval bych ho, takže Invalid. Pokud by tam nebyl, tak 10, řekl bych, ale je to jen návrh naprosto odboku. To samé pro sum().

Mimochodem, jakej je use case takovýhohle selectu?
A k tomu se v SQL používá NOT NULL
Mmmkay, a pak uděláš outer join a NULL se ti tam dostane stejně, pokud se nemýlím...
20.6.2014 18:02 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Mmmkay, a pak uděláš outer join a NULL se ti tam dostane stejně, pokud se nemýlím...
Nejenom v tomto pripade.

Hezke je i tohle:
select a from foo where false;
-> tabulka s 0 radky
select (select a from foo where false);
-> tabulka s jednim radkem majici jeden atribut majici "hodnotu" NULL
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
20.6.2014 22:01 WNJ
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Na jednu stranu to zní dobře, umožňovalo by to popsat víc speciálních stavů a už se to celkem blíží výjimkám, ale na druhou stranu mám obavu, že by to systém příliš zesložitilo.

Ty speciální hodnoty by byly globální nebo by si je mohl definovat uživatel?

Jako, musim rict, ze rozsirit relacni model o algebraicke datove typy by se mi hodne libilo. Jak pises niz, pro Option ze SML (Maybe z Haskellu, atd, pokud ho obsahuje i Rust, cobre pro nej) uz v SQL je nejaka podpora v ramci NOT NULL. Samozrejme by sis nad tim musel sam definovat logiku. Potgres umi jakesi vyctove typy (reknes, ze soupecek pohlavi muze byt "M", "F", "Petr Tomes", a nic jineho ti tam nedovoli vlozit) takze se to da i trochu udelat, ale prave ADT by byly trosku jinde. Souhlasim, ze to z predrecnika dela spis milovnika NULLu co by ho chtel rozsirit, nez jeho odpurce, i kdyz si to mozna nemysli. NULL v SQL je navic mnohem lepsi jak NULL treba v Jave, kde muze uplne cokoli byt uplne kdykoli null. V SQL muzu rict, ze nejaka hodnota musi byt vyplnena / definovana a ta databaze to zajisti, takze v tomhle je bliz Haskellu.
20.6.2014 22:25 WNJ
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Doprcic, to formatovani me nejak nema rado.
Jako, musim rict, ze rozsirit relacni model o algebraicke datove typy by se mi hodne libilo. Jak pises niz, pro Option ze SML (Maybe z Haskellu, atd, pokud ho obsahuje i Rust, cobre pro nej) uz v SQL je nejaka podpora v ramci NOT NULL. Samozrejme by sis nad tim musel sam definovat logiku. Postgres umi jakesi vyctove typy (reknes, ze soupecek pohlavi muze byt "M", "F", "Petr Tomes", a nic jineho ti tam nedovoli vlozit) takze se to da i trochu udelat, ale prave ADT by byly trosku jinde.

Souhlasim, ze to z predrecnika dela spis milovnika NULLu co by ho chtel rozsirit, nez jeho odpurce, i kdyz si to mozna nemysli.

NULL v SQL je navic mnohem lepsi jak NULL treba v Jave, kde muze uplne cokoli byt uplne kdykoli null. V SQL muzu rict, ze nejaka hodnota musi byt vyplnena / definovana a ta databaze to zajisti, takze v tomhle je bliz Haskellu.
20.6.2014 15:44 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Že zrovna sum() a + mají k sobě blízko a někteří lidé si to pletou… to je okrajová záležitost – je to jedna z mnoha funkcí a jeden z mnoha operátorů. Spíš náhodná podoba.
Takova argumentace stoji hodne na hlinenych nohach.
A jednak by to byl v podstatě odklon od relací a příklon spíš k nějakým objektovým databázím, viz #62 – výsledkem dotazu by nebyla relace ale jakási stromová struktura…
Nesmysl, vysledkem je opet relace, ktera bude mit jako hodnoty opet relace, plne v souladu s rel. modelem, na kterem DB stoji.

Priklad, ktery jsem uvadel, by v podstate mohl jit resit i prostredky SQL, protoze je pro to potreba jen projekce, restrikce a extenze, prip. sjednoceni, coz SQL umi. Ale neumi relace jako hodnoty. Z tohoto pohledu neni SQL dostatecne ortogonalni jazyk.
Nakonec se s tou prázdnotou (chybějící hodnotou) musíš nějak vyrovnat – bez ohledu na to, zda byla vyjádřena ve formě NULL hodnoty, nebo prázdné relace
NULL znamena absenci hodnoty. V pripade prazdne relace mas hodnotu, kterou je prazdna relace.
když budeš počítat absolutní hodnotu a na vstupu dostaneš prázdnou relaci
Coze?

Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
20.6.2014 22:30 WNJ
Rozbalit Rozbalit vše Re: PoniDB - Úvod
NULL znamena absenci hodnoty. V pripade prazdne relace mas hodnotu, kterou je prazdna relace.
To si moc neumim predstavit.

Rekneme, ze mas tahle data: titanic3.csv, jenom maji 150 000 000 radku, takze abys je mohl analyzovat, musis je nacpat do databaze.

Je zjevne, ze tam hromada dat chybi. Lide kteri neprezili treba casto nemaji clun na kterem se zachranili, protoze se nezachranili, u nekoho se nevi, kde mel kajutu, takove veci. Jak vypada "prazdna relace" jako hodnota sloupce pro takove pripady? Jakym zpusobem by vypadalo dotazovani nad takovymi relacemi?
Fluttershy, yay! avatar 20.6.2014 23:10 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Dekompozice a při rekompozici by se tam občas ukázala TABLE_DUM?
xkucf03 avatar 21.6.2014 00:53 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

A ty bys fakt chtěl takhle dekomponovaný1 model používat?

[1] v podstatě: co původní sloupec, to tabulka

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
21.6.2014 00:59 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Lide kteri neprezili treba casto nemaji clun na kterem se zachranili, protoze se nezachranili, u nekoho se nevi, kde mel kajutu, takove veci. Jak vypada "prazdna relace" jako hodnota sloupce pro takove pripady?
Cpat vsude prazdnou relaci misto NULL absolutne nedava smysl.

Dejme tomu, ze kajuty maji cisla od 1 do 1000. Zavedes si sloupec "kajuta integer CHECK ((kajuta >= 1) AND (kajuta <= 1000))" a kdyz kajutu neznam, dam tam NULL.

Vypada to rozumne, ze? Presto muzu udelat SELECT avg(kajuta) FROM titanic WHERE survived = 1 a dozvedet se, jake bylo prumerne cislo kajuty, kde lidi prezili. Takova pitomost neni bug ale feature SQL.

Koncepcne mnohem logictejsi by bylo zavest vlastni datovy typ ,,cislo_kajuty'' jehoz domena bude obsahovat hodnoty { 1, ..., 1000, neznama-kajuta, nemel-kajutu }, pro cez si definujes vlastni operatory, ktere davaji smysl.
Jakym zpusobem by vypadalo dotazovani nad takovymi relacemi?
Jako jakekoliv jine dotazovani.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
21.6.2014 01:26 WNJ
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Cpat vsude prazdnou relaci misto NULL absolutne nedava smysl.
S tim pojmem prisel kolega, takze moc netusim co to melo byt ;-)
Dejme tomu, ze kajuty maji cisla od 1 do 1000. Zavedes si sloupec "kajuta integer CHECK ((kajuta >= 1) AND (kajuta <= 1000))" a kdyz kajutu neznam, dam tam NULL.

Vypada to rozumne, ze? Presto muzu udelat SELECT avg(kajuta) FROM titanic WHERE survived = 1 a dozvedet se, jake bylo prumerne cislo kajuty, kde lidi prezili. Takova pitomost neni bug ale feature SQL.

Koncepcne mnohem logictejsi by bylo zavest vlastni datovy typ ,,cislo_kajuty'' jehoz domena bude obsahovat hodnoty { 1, ..., 1000, neznama-kajuta, nemel-kajutu }, pro cez si definujes vlastni operatory, ktere davaji smysl.
Jasne. Ale to si v zasade jenom stezujes, ze SQL je dynamicky typovane a pouziva normalni datove typy. To, ze cislo kabiny je cislo, neznamena, ze ma smysl pocitat z nej prumer, ale podobne jako v Pythonu nebo Lispu to neznamena, ze Ti to ten typovy system zakaze. Jak jsem rikal, DB s ADT by byla zajimava, ale aktualne nemam pocit, ze se tim nekdo zabyva.
xkucf03 avatar 22.6.2014 20:36 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod
když budeš počítat absolutní hodnotu a na vstupu dostaneš prázdnou relaci
Coze?
Když můžeš s relací pracovat jako s kterýmkoli jiným datovým typem, tak ji můžeš předat jako parametr funkce a ty funkce musí nějak řešit výjimečný stav (prázdná relace nebo NULL) a buď vracet totéž (prázdná relace nebo NULL) nebo vyhazovat výjimku, případně si něco domyslet, ale to není ideální.

Ano, když ta relace bude prázdná, tak se na ní ty funkce vůbec nepustí (není nad čím), ale to se týká případu, kdy funkci pouštíš nad jednotlivými záznamy/atributy, ale ne nad celou relací. (dá se to použít v případě, kdy tu novou vypočtenou hodnotu chci mít v té vnořené relaci)

Navíc ta relace má další nevýhodu (resp. vyšší složitost) v tom, že tam můžeš být a) žádná hodnota, b) jedna hodnota, c) několik hodnot - zatímco u toho sloupce s možností NULL máš jen a) a b).

Představ si např. že např. připojíš data z jiné tabulky tím tvým způsobem (ne klasický JOIN) a napojíš si tím k záznamu dvě další souvisejí hodnoty z jiné tabulky - tam ale nic nebude a místo NULL tam budeš mít prázdnou relaci. A ty pak z těchto dvou sloupců budeš chtít něco spočítat (absolutní hodnotu, maximum atd.) a mít to ve třetím sloupci.
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
23.6.2014 12:31 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Když můžeš s relací pracovat jako s kterýmkoli jiným datovým typem, tak ji můžeš předat jako parametr funkce a ty funkce musí nějak řešit výjimečný stav
Vtip je v tom, ze prazdna relace neni vyjimecny stav, ale bezna hodnota.
Navíc ta relace má další nevýhodu (resp. vyšší složitost) v tom, že tam můžeš být a) žádná hodnota, b) jedna hodnota, c) několik hodnot - zatímco u toho sloupce s možností NULL máš jen a) a b).
Vtip je v tom, ze je tam vzdy prave jedna hodnota a tou je ta relace. Kolik obsahuje n-tic, je podruzne.
A ty pak z těchto dvou sloupců budeš chtít něco spočítat (absolutní hodnotu, maximum atd.) a mít to ve třetím sloupci.
Nejak nevidim v cem je problem. Stejne jako mas funkce definovane pro normalni tabulky (tj. relace), tak je pouzijes na vnorene relace.
Představ si např. že např. připojíš data z jiné tabulky tím tvým způsobem (ne klasický JOIN) a napojíš si tím k záznamu dvě další souvisejí hodnoty z jiné tabulky - tam ale nic nebude a místo NULL tam budeš mít prázdnou relaci. A ty pak z těchto dvou sloupců budeš chtít něco spočítat (absolutní hodnotu, maximum atd.) a mít to ve třetím sloupci.
Pokud chces s tema hodnotama neco pocitat, nedava smysl, pouzit tuto "nahradu vnejsiho spojeni", ale dava smysl pouzit normalni spojeni.
absolutní hodnotu
Co myslis tou absolutni hodnotou?
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 23.6.2014 19:04 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Pokud chces s tema hodnotama neco pocitat, nedava smysl, pouzit tuto "nahradu vnejsiho spojeni", ale dava smysl pouzit normalni spojeni.

Ale to musí buď existovat NULL a použiješ RIGHT/LEFT JOIN nebo tam ten řádek bude úplně chybět - kvůli jedné chybějící hodnotě, bys přišel o další, které v pohodě spočítat šlo - takže bys musel pustit dva dotazy - místo toho, abys v některých sloupcích měl NULL a věděl, že tahle jedna hodnota chybí resp. nešlo ji vypočítat.
Co myslis tou absolutni hodnotou?

Matematicky, absolutní hodnota čísla - na tom celkem nesejde, prostě nějaká funkce.
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
20.6.2014 11:26 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Imho docela hezkým příkladem, jak se vyhnout použití null, je Option v jazyce Rust
Option je uz i v Jave. ;-] Jinak tahle feature ma prapuvod ve funkcionalnich jazycich, nevim, jestli to driv mel SML nebo Haskell, ale tam proste dava smysl, aby funkce vzdy vracela nejakou hodnotu.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
19.6.2014 19:49 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
„Nesouhlasil jsem s operace vždy dobře definované a vždy dávají výslednou hodnotu.“

Každá operace v SQL jazyce má jednoznačně definovaná pravidla, jaký bude výsledek, a ten výsledek bude vždy existovat.

---

To, že některé podobné operace berou v úvahu NULL a některé ne je otázkou definice funkce. To samé se Vám stane s float/double čísly třeba v C. Ale žádné protesty z této strany jsem neslyšel, obvykle proto, že matematici a fyzici pracující s výpočtu jsou většinou znalí, a uvědomují si, že jim hodnoty NaN slouží k tomu, aby měli život jednodušší. Běžní programátoři dnešní generace většinou naprosto netuší, že v reálných číslech mají nějakou NaN hodnotu, a tak nekritizují to, čemu nerozumějí.

Je otázkou dohody celé algebry.

Bohužel v databázích NULL svítí pro každého, i neznalého.

Praxe, na rozdíl od akademických teorií typu Codd, nebo deda.jablko, potřebuje řešit i krajní a chybové stavy. Pokud chcete dokonale teoreticky konzistentní, musíte začít s předpokladem, že nikdy nenastane žádná chyba, nikdy nenastane žádný výjimečný stav, vše bude dokonalé.

Bohužel realita je ošklivá. V realitě vznikají chyby na rozdíl od akademických řečí. V realitě vznikají různé případy, které nejde vyřešit akademicky.

Ano, a reálné chyby nejde vyřešit bez NULL hodnoty. Protože se často zpracovává najednou balík dat, kde chybná či speciálně označená pomocí NULL mohou být jen některá, a označovat agilně vše za chybu je NEPRAKTICKÉ (i když teoreticky a akademicky čisté). Výjimkami to opět řešit nejde, protože něco je špatné, něco ne.

A tak se holt objeví dohody, které funkce budou NULL ignorovat (všechny agregační funbkce), a které jej budou propagovat. NULL do toho vkládá asymetrii, což byl záměr.

Miloslav Ponkrác
19.6.2014 20:39 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Praxe, na rozdíl od akademických teorií typu Codd
Jeste stesti, ze se ta Coddova akademicka teorie v praxi vubec neujala... co by s ni vsichni ti praktici delali...
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
19.6.2014 22:48 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Ona se samozřejmě ujala a byla dále rozpracována (tedy nevzala se i s chlupama)a implementována. A další nápady Codda už se nekonaly vůbec (viz 4stavová logika, atd.) To neznamená, že Codd nebyl génius, ani že nestál na počátku relačních db, jenom že jste si ho vzal na pomoc, když jste nedokázal osobně obhájit Vaše vlastní tvrzení.

Ale takto přesně dopadají diskuse, když si někdo, argumentačně velmi slabý začne brát na pomoc další lidi, a není schopen obhájit argumenty sám svůj názor. Pak to znamená, že vlastně tomu, co obhajuje, vlastně nerozumí, když není schopen podstatu sdělit bez pomocníků.

Já jsem nikoho nepotřeboval a dělám to tak stále od svého narození. Mluvil jsem o věci přímo.

V zásadě jste nevěděl jak dál, když jsem jasně řekl, že NULL je hodnota, nic jiného. A když jsem nesouhlasil s tím, že algebra nad databázemi může mít různé vlastnosti dle potřeb praxe.

Chtěl jsem Vás vyprovokovat, a nejenom já, abyste ukázal řešení bez NULL hodnoty v řadě praktických příkladů, které je lepší a praktičtější, než současné. Protože toto je jediné přesvědčující. A pokud byste našel a ukázal toto řešení, uznale bych pokývl hlavou a řekl ano, máte pravdu.

A teď už končím s diskusí ohledně NULL/SQL.

Protože to nemá žádný další smysl.
19.6.2014 23:14 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
jenom že jste si ho vzal na pomoc
Tak za prve. Odkazoval jsem na Datovu knizku a ne na Codda a to z toho duvodu, abyste si rozsiril vzdelani o databazich, ve kterem mate mezery.

Za druhe. Kdo dokaze lip vysvetlit vyznam NULL v relacnim modelu Codd, nebo vy?

algebra nad databázemi
to je taky zajimave :-]]
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xxx avatar 19.6.2014 23:08 xxx | skóre: 42 | blog: Na Kafíčko
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Jako pardon, ze se vam do toho micham, ale pojmy: "priznak", "specialni hodnota" a "hodnota v systemu definovanem tak, aby to hodnota byla" mi prijdou ekvivalentni. (Jeden za 18, druhy za 20-2 a treti za 17+NULL, kde vysledek operace + s hodnotami NULL a 17 je 18).
Please rise for the Futurama theme song.
19.6.2014 23:44 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
"priznak", "specialni hodnota" a "hodnota v systemu definovanem tak, aby to hodnota byla" mi prijdou ekvivalentni
Nejsou. Hodnota je (hrube receno) abstraktni objekt, ktery nema zadnou fyzickou reprezentaci, proste to je jen hodnota, napr. 42. A potom mas reprezentaci teto hodnoty, napr. jako sekvenci bitu ulozenych nekde v pameti, napr. jako 0x2A nebo "42". I kdyz se jedna o ruzne reprezentace, porad predstavuji jednu konkretni hodnotu.

V pripade rel. db. se na to muzes divat tak, ze system pracuje s relacemi jako hodnotami, ktere jsou na disku/v pameti reprezentovany jako tabulky. Z tohoto pohledu se pak muzes pri zpracovani dotazu divat na tabulky jako na promenne, jejichz hodnoty jsou relace a pracovat s nimi konzistentne pomoci rel. operatoru.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
19.6.2014 16:52 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
tak ani tak nemůžeš null interpretovat jako true nebo false
bylo lepší, se toho držet a za žádných okolností takovou interpretaci/přetypování nepřipustit
Nebo by bylo lepší mít vedle NULL ještě další symboly jako ?, * atd.?
...a to jsou jedny z tech problemu SQL, o kterych je tu celou dobu rec.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
19.6.2014 16:59 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Ne, to není problém SQL, to je problém nepochopení některých lidí, o čem je NULL. A když lidé něco nechápou, tak to označí za problém. Je to snažší a vyžaduje to méně úsilí.
xkucf03 avatar 19.6.2014 17:44 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Asi je chyba, že v tom CASE se převede null na false a čistější by bylo, kdyby výsledkem byla výjimka (a bylo potřeba explicitní coalesce(null, false)). Ale znamená to snad, že bychom měli zavrhnout NULL jako takové? Já si myslím, že ne. Prázdná/chybějící hodnota je důležitá informace, kterou je potřeba nějak přenášet.

Takže bys radši víc symbolů? Jaké?

Nebo radši žádný, ani NULL? Pak by mne zajímala odpověď na moji otázku výše:

co by se v těch sloupečcích po propojení tabulek zobrazovalo v případě neexistence odpovídajícího záznamu v druhé tabulce, když bychom neměli NULL? Bylo by takové spojení nemožné a bylo by potřeba položit víc dotazů a data si poskládat až v aplikaci?
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
19.6.2014 18:52 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Ale znamená to snad, že bychom měli zavrhnout NULL jako takové? Já si myslím, že ne. Prázdná/chybějící hodnota je důležitá informace, kterou je potřeba nějak přenášet.
To je problem nepruzneho typoveho systemu. Pokud je to opravdu hodnota, mela by byt soucasti domeny daneho typu.
co by se v těch sloupečcích po propojení tabulek zobrazovalo v případě neexistence odpovídajícího záznamu v druhé tabulce, když bychom neměli NULL? Bylo by takové spojení nemožné a bylo by potřeba položit víc dotazů a data si poskládat až v aplikaci?
Pro toto existuje reseni, ktere ale vetsina databazistu nezkousne, protoze vyzaduje relace jako hodnoty, coz SQL nepodporuje.

Uvazujme relaci "items":

id item price
1 Item #1 100
1 Item #2 200
1 Item #3 150
2 Item #X 10
2 Item #Y 300

A relaci "customers":
id name
1 Alice
2 Bob
3 Chuck

Jejich vnejsi spojeni by pak mohlo vypadat nasledovne:

1 Alice

item price
Item #1 100
Item #2 200
Item #3 150
2 Bob

item price
Item #X 10
Item #Y 300
3 Chuck

item price

Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 19.6.2014 19:37 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

A co vícerozměrná pole?

$ sql-dk --db blog --formatter tabular-prefetching --sql "SELECT 'abc', array [[123, 321], [456, 654]] UNION SELECT 'def', array []::integer[]"
 ╭─────────────────┬───────────────────────╮
 │ ?column? (text) │ array         (_int4) │
 ├─────────────────┼───────────────────────┤
 │ abc             │ {{123,321},{456,654}} │
 │ def             │ {}                    │
 ╰─────────────────┴───────────────────────╯
Record count: 2
$ sql-dk --db blog --formatter xml --sql "SELECT 'abc', array [[123, 321], [456, 654]] UNION SELECT 'def', array []::integer[]"
<?xml version="1.0" encoding="UTF-8"?>
<batchResult xmlns="https://sql-dk.globalcode.info/xmlns/batchResult">
        <database name="blog">
                <statement>
                        <sql>SELECT 'abc', array [[123, 321], [456, 654]] UNION SELECT 'def', array [[],[]]::integer[]</sql>
                        <resultSet>
                                <columnHeader label="?column?" name="?column?" typeName="text" type="12"/>
                                <columnHeader label="array" name="array" typeName="_int4" type="2003"/>
                                <row>
                                        <column>abc</column>
                                        <column>
                                                <array>
                                                        <item>
                                                                <array>
                                                                        <item>123</item>
                                                                        <item>321</item>
                                                                </array>
                                                        </item>
                                                        <item>
                                                                <array>
                                                                        <item>456</item>
                                                                        <item>654</item>
                                                                </array>
                                                        </item>
                                                </array>
                                        </column>
                                </row>
                                <row>
                                        <column>def</column>
                                        <column>
                                                <array>
                                                </array>
                                        </column>
                                </row>
                        </resultSet>
                </statement>
        </database>
</batchResult>

Případně v procedurálním SQL můžeš vracet sady záznamů… ale tohle prostě nabourává představu, že hodnota atributu by měla být nejlépe atomická → s každou atomickou hodnotou můžu pracovat stejným způsobem (a nepotřebuji speciální funkce pro extrakci složek z různých komplexních typů a jejich aktualizaci nebo mazání).

Ale myslím, že tohle je spíš politické rozhodnutí – ne něco, čemu by jazyk SQL principiálně bránil a k čemu by nešel přizpůsobit.

Případně bys místo vnořené relace mohl použít nějaký komplexní typ jako XML a v něm zanořovat hodnoty třeba do deseti úrovní.

Neříkám, že by se to někdy nehodilo :-)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
19.6.2014 20:07 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
A co vícerozměrná pole?
Případně bys místo vnořené relace mohl použít nějaký komplexní typ jako XML a v něm zanořovat hodnoty třeba do deseti úrovní.
Takhle by to asi slo, ale je to nekoncepcni lepeni dalsich vlastnosti, protoze pro pole/XML bys potreboval dalsi dotazovaci jazyk. Kdyz to budes mit jako relaci, muzes pouzit uz dotazovaci jazyk, ktery mas.
hodnota atributu by měla být nejlépe atomická
Tohle pravidlo bere za sve, kdyz do databaze cpes JSON, XML, apod. coz dnes dela cim dal tim vic lidi.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
21.6.2014 01:23 WNJ
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Chapu, takze z plochych "tabulek" by se staly rekurzivni stromove struktury. Tohle umi treba dokumentove databaze (a ostatne kdyz si vsechno udelas v Jave s nejakym ORM, tak to tak taky muze vypadat), ale osobne si nejsem jisty, jestli ta pridana slozitost za to stoji.

Treba MongoDB to umi nejak podobne, ale ten dotazovaci jazyk ... neni nejpohodlnejsi. Pokud se SQL neda neco uprit, je to expresivnost.

MongoDB:
db.games.aggregate([
  {
    $match : {
      date : {
        $gt : ISODate("1999-08-01T00:00:00Z"),
        $lt : ISODate("2000-08-01T00:00:00Z")
      }
    }
  },
  {
    $unwind : '$teams'
  },
  {
    $match : {
      'teams.won' : 1
    }
  },
  {
    $group : {
      _id : '$teams.name',
      wins : { $sum : 1 }
    }
  },
  {
    $sort : { wins : -1 }
  },
  {
    $limit : 5
  }
]);
SQL
 SELECT abbrev, name, count(*)
    FROM winners JOIN team ON team.id = winners.winner
   WHERE     date > '1999-08-01T00:00:00Z'
         AND date < '2000-08-01T00:00:00Z'
GROUP BY winner, abbrev, name
ORDER BY count(*) DESC
   LIMIT 5;
21.6.2014 03:27 Kvakor
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Jaky je vlastne smysl NULL? Je to NULL nedefinovana, nebo neznama hodnota?
Pokud jde filosofičtější náhled tohoto konceptu, přijde mi lepší brát NULL ne jako neznámou či nedefinovanou hodnotu, ale spíš výraz nesmyslnosti samotného dotazu(/operace/reference/atd.), ve smyslu "Tento dotaz nemůže být zodpovězen" (viz Mu). To, že to reálné implementace nedodržují (viz mnohokát zmíněná suma sloupce, kde jsou některé hodnoty NULL) bych viděl jako upřednostnění pragmatické implementace nad idealistickou.

19.6.2014 13:12 Ondra
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Jenže ty problémy jsou často už vyřešené (či alespoň řešitelné v rámci SQL
ten

mismatch with host languages

neni resitelny a predstavuje ten nejvetsi problem SQL (a jakychkoliv deklarativnich jazyku). To ale neznamena, ze je treba SQL zavrhovat, proste se to ujalo, je to ekonomicky uspesne (tedy minimalne pro Elisona a Wideniuse) a proste se to pouziva. Dokonce to doslo tak daleko, ze se na skolach neuci uz nic jineho.
Fluttershy, yay! avatar 19.6.2014 13:36 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
ze se na skolach neuci uz nic jineho

Chrchly, chrchly. Já půl semestru bojoval s Relem. Java. Must. Die.

19.6.2014 16:43 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Stejně jako já jsme se na škole učil SQL jen jako jedno z mnoha možností práce s databází.

Nikdo nikomu nebrání napsat super duper hyper extra kultovně dokonalý nový DBMS, kde kromě SQL rozhraní bude možné pracovat ještě s 10 dalšími způsoby a API, jak s nimi pracovat.

Právě proto ani trochu nechápu snahu zavrhovat SQL. Žádný autor DBMS není nucen zatratit jakékoli jiné rozhraní. Může si nad svou DBMS implementovat kolik přístupů chce a kolik rozhraní chce. A řada DBMS to dokonce dělá.

Spíše po delší době začínám mít dojem, že nenávist k SQL a k relačním databázím je daná spíše nechopností autorů, uživatelů i akademických teoretiků na abclinuxu.cz ukázat něco výrazně lepšího, a tak potřebují dupat po tom, co jim konkuruje.

Navíc nikdy tomu nebylo tak, že všechny databáze jsou relační a všechny mají SQL. Po celou dobu existence databází byly vždy i nerelační a neSQL stále.

Ti, co tvoří si jednoduše používají co je jejich srdci libo. Ti druhé kritizují SQL a relační databáze s tím, že by neměly existovat.

Právě proto, že relační databáze nejsou všelékem, existují i jiné. Právě, že nerelační databáze nejsou všelékem, existují i relační.
Fluttershy, yay! avatar 19.6.2014 16:48 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
wat.

Měl jsem pocit, že podstatná část vlákna byla o tom, jak implementace relačního modelu a SQL jsou dvě kapánek odlišné věci.
19.6.2014 16:57 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Příslušnost příspěvků k vláknům je zde silně nepřehledná.
Fluttershy, yay! avatar 19.6.2014 18:02 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Doporučuji používat

  • odkaz "Výše",
  • vlastní stylopis nebo
  • přiblížení/oddálení v prohlížeči.
xkucf03 avatar 19.6.2014 13:57 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod
ten mismatch with host languages neni resitelny a predstavuje ten nejvetsi problem SQL (a jakychkoliv deklarativnich jazyku).

Ono tohle je i otázka bezpečnosti a distribuovanosti systému – když databáze běží na jiném stroji a provozuje ji někdo jiný, tak mě asi nenechá, abych si v ní mohl spouštět libovolný kód ve svém oblíbeném jazyce (zrovna v tom, v kterém píšu aplikaci, protože těch jsou spousty). Bylo by potřeba nějaké RPC/RMI, zajistit přenos objektů1 z jednoho systému (aplikace) na druhý (databáze). Jazyk typu SQL je nejlepší řešení, pokud to nemá být vázané na jeden konkrétní jazyk (→ aplikace by šlo psát jen v jednom jazyce) nebo dokonce konkrétní proces (databáze přímo součástí aplikace → nelze k ní přistupovat z více aplikací).

Řešitelné je to nějakou překladovou vrstvou, ať už ORM nebo nějakým generátorem typu JOOQ. Je to vlastně podobné, jako když chceš volat vzdálené procedury z jiného systému – máš strojově čitelný popis rozhraní, vygeneruješ si klientské třídy/funkce pro svůj jazyk a pak už píšeš jen v něm.

I když nevidím ani tak velký problém v kombinaci více jazyků v rámci jednoho programu – taky to má svoje uplatnění a dá se s tím pracovat.

[1] složité stromy nebo spíš grafy obsahující cykly, reference na sebe sama…

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
Heron avatar 18.6.2014 16:10 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: PoniDB - Úvod
single table, protože to chci co nejjednodušší

Njn. Můj první web byl v ANSI C (přes Apache a CGI), data měl v Trivial Database. Potom, bohužel, jsem byl ukecán že každý správný web musí být v php a samozřejmě MySQL. To mi naštěstí moc dlouho nevydrželo a teď je to PostgreSQL. "Klasické" relační DB se na určité pojetí webu příliš nehodí, leckdy je key-value nejlepším počátečním řešením. Jenže, potom přijdou dokumenty, json. Takže PostgreSQL. Umí být čímkoliv od "triviální" keyvalue db (hstore), přes "noSQL" dokumentovou databázi (bson) až po "klasickou" relační potvoru (pochopitelně historické pořadí bylo lehce jiné, postgres(ql) nebyl vždy SQL). S daty od pár set kB, až po stovky terabajtů.

19.6.2014 13:03 Ondra
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Jenže, potom přijdou dokumenty, json. Takže PostgreSQL
vy jste, pote co se objevil na scene json format cekal pet let a nic neprogramoval, nez to postgresql take implementoval?
19.6.2014 15:09 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
A pak ještě PostgreSQL uvaří kafe, udělá svíčkovou, a v posteli je také úžasná. A to vůbec nemluvím o tom, jak krásně PostgreSQL hraje na piáno Bacha.
19.6.2014 13:17 Ondra
Rozbalit Rozbalit vše Re: PoniDB - Úvod
rekl bych ze jdete spravnym smerem. Jestlize nechcete delat vsechno sam, tak doporucim pouzit jiz vyzkousene:

- perl:

- hash struktury

- tie

- Storable

Pouzitim techto 4 perl technik mate k dispozici perzistentni hashovaci im-memory databazi s grandiozni perl rychlosti a to nejen pro cteni.
19.6.2014 15:06 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Já bych spíše všem začátečníkům doporučil, a všude dokola doporučuji vyhnout se neseriózním programovacím jazykům.

Seriózní programovací jazyky jsou jazyky:

1) Mají de jure nebo de facto standard, který se bere za posvátný a dodržuje se.

2) Všechny následující standardy a implementace vykazují maximální snahu o zpětnou kompatibilitu co to jenom jde. Takové jazyky chápou, že změna základní syntaxe tak, jak jí provozuje Python nebo Perl, jsou zničením práce vývojářů, a každá taková změna musí mít setsakra dobrý důvod a zlepšení přesahující škody, kterou zpětná nekompatibilita udělá.

3) Existuje více různých implementací kompilátoru/interpretru, než jeden kousek.

4) Jazyk je navržen především prakticky a konzistentně. (Jakékoli jazyky, které se na svou reklamou ohánějí čistotou či teoretickou dokonalostí, dostávají mínus.)

5) Jazyk musí mít možnost být rozumně čitelný i po letech a obsahovat základní, dnes požadovaný arzenál featur.

---

Tedy začátečníkům rozhodně nedoporučuji Perl. Vlastně vůbec nikomu.
Bystroushaak avatar 19.6.2014 15:43 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Já bych spíše všem začátečníkům doporučil, a všude dokola doporučuji vyhnout se neseriózním programovacím jazykům.
Začátečníci mají imho požadavky na "serióznost" jazyka úplně minimální, až nulové. Ty požadavky dokonce nemá ani mnoho profesionálů (konkrétně bod 2 se mi zdá dost sporný).
xkucf03 avatar 19.6.2014 15:57 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod

Zrovna ten bod 2 je dost důležitý, bez něj se můžeš dostat do dost nepříjemných situací jako:

  • máme software fungující na jen platformě verze X, ale knihovna, kterou potřebujeme vyžaduje verzi X+1
  • protože platforma přináší nekompatibilní změny, drželi jsme se dlouho staré verze, a teď s překvapením zjišťujeme, že ta už není podporovaná a co všechno musíme najednou přepsat
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
19.6.2014 22:06 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
máme software fungující na jen platformě verze X, ale knihovna, kterou potřebujeme vyžaduje verzi X+1
a.k.a. The Python problem :-D
Jakub Lucký avatar 21.6.2014 08:55 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Zrovna ten Python, ve kterem se da bez velke namahy napsat kod, ktery se da spustit na obou verzich? A kdo si na tom chce hodne trvat, pouzije kvalitni knihovnu, ktera mu to usnadni (six)
If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
21.6.2014 14:54 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Problém je, když máš napsanej kód pro verzi 3 a potřebuješ použít knihovnu, která existuje jen pro verzi 2 (to se mi nedávno stalo).
19.6.2014 16:16 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
„Začátečníci mají imho požadavky na "serióznost" jazyka úplně minimální, až nulové.“

Právě proto jsou to začátečníci, protože se neorientují. Pokud si své začátky naučí špatně a získají špatné návyky, budou muset použít několikanásobek času a sil na to se to odnaučit, než kdyby se to naučili hned správně.

---

„Ty požadavky dokonce nemá ani mnoho profesionálů (konkrétně bod 2 se mi zdá dost sporný).“

Profesionálové možná ne, protože za profesionála se označuje každý, který se programováním živí bez ohledu na jeho míru znalostí a schopností.

Nicméně dobří programátoři si už tolikrát nabili ústa, že tyto požadavky mít budou, jakmile začnou projekt, na kterém jim záleží.

Bod 2) je nejdůležitější základ.

Ostatně zkuste si to. Proč by třeba sh a bash shelly měly držet nějakou zpětnou kompatibilitu? Nebylo by fajn je přepsat a vylepšit je? Holt si všichni administráoři serverů přepíší všechny své skripty a ztisícinásobí se počet úspěšných průniků do linuxových serverů, ale to přeci za to stojí, ne?

Nebo můžeme nekompatibilně vylepšit jazyk C. On si Linus Torvalds a vývojáři kernelu rádi střihnou napsat nový linux kernel od začátku znovu.

Bod 2) začnete považovat za nejdůležitější přesně v okamžiku, kdy jste to vy, kdo tyhle kratochvíle za nesmyslné nekompatibilní změny v jazycích bude platit. Svým časem, penězi, …

Proto budiž proklet a zkrachován každý programovací jazyk, který po delší době nekompatibilně změní základní syntaxi, aniž by k tomu neměl sakra dobrý důvod a benefity mnohonásobně převyšující náklady.

Miloslav Ponkrác
Bystroushaak avatar 19.6.2014 16:37 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Ostatně zkuste si to.
Zkouším si to. Profesionálně (python) ;)

Jinak tohle je třeba zrovna věc, která se dá docela úspěšně ovlivnit architekturou. Pokud je něco postaveno jako services/microservices, tak nevadí, že některé části běží třeba v cobolu (zrovna jsem na to v práci natrefil) a jiné části například ve starých verzích pythonu.

Osobně se mi ta python sitace taky nelíbí, když na verzi 3.x všichni z vysoka kašlou, ale existují příklady, kde mi to vůbec nevadí (například D).

Co naprosto nechápu je důvod, proč kompilátory/interpretry nemají vícero frontendů, kde ve zdrojáku by byla vyspecifikovaná verze se kterou to chci přeložit/interpretovat a tím by se celý problém vyřešil. Sice by to zvedlo velikost samotného překladače/interpretru, ale komu dneska není ukradená?
19.6.2014 16:45 aaa
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Co naprosto nechápu je důvod, proč kompilátory/interpretry nemají vícero frontendů, kde ve zdrojáku by byla vyspecifikovaná verze se kterou to chci přeložit/interpretovat a tím by se celý problém vyřešil. Sice by to zvedlo velikost samotného překladače/interpretru, ale komu dneska není ukradená?
#!/usr/bin/perl
use v5.6.1;
...
19.6.2014 16:54 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Ono hlavně existují užitečnější činnosti v životě i práci, než se přizpůsobovat zbytečně (s důrazem na slovo zbytečně) proměnlivým jazykům nechávající po svých změnách potopy.

Právě proto to nikdo neřeší. Jednodušší je, je-li možnost se na takový jazyk preventivně vykašlat. Jakmile vidíte, že s autory jazyků šijí roupy a vážně připravují nekompatibilní bezdůvodnou změnu, je třeba zastavit co jde nového v těchto jazycích. A nechat autory jazyka, ať se dívají na jazyk, který jde do háje a na vraždu svého dítěte, které mělo udělat díru do vesmíru.

Namísto přizpůsobování a opravování zdrojáků u prchavého jazyka si můžete vyjít se psem. Nebo si s dítětem zahrát karty. Nebo obejmout svou ženu. Nebo se dívat na hvězdy. Nebo napsat knížku. Nebo cokoli. Nebo se naučit něco nového. Nebo složit písničku, která bude v top ten světa.
xkucf03 avatar 19.6.2014 17:56 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod
$ javac 2>&1 | grep target
  -target <release>        Generate class files for specific VM version

$ gcc --help | grep std
  -std=<standard>          Assume that the input sources are for <standard>
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)
Bystroushaak avatar 19.6.2014 22:00 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: PoniDB - Úvod
To ovšem není tak úplně to, co jsem popisoval.
19.6.2014 16:48 aaa
Rozbalit Rozbalit vše Re: PoniDB - Úvod
takze jestli to chapu spravne, tak chces neco jako kyoto cabinet nebo leveldb a nad tim nejakej sikovnej dotazovaci jazyk se serverikem.
20.6.2014 00:35 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: PoniDB - Úvod
single table, protože to chci co nejjednodušší
On to vlastne neni problem, protoze nad jednou tabulkou se da vzdy udelat vice tabulek pomoci prefixu u klice.

Jinak pokud si chces zablbnout a podivat se do zajimavych vod, muzes svou ulohu rozsirit na distribuovanou in-memory databazi.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
20.6.2014 17:08 Valenta
Rozbalit Rozbalit vše Re: PoniDB - Úvod
ta diskuze zde ohledne NULL apod. exemplarne ukazuje 'vyhody' SQL :-)
Bystroushaak avatar 20.6.2014 21:32 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: PoniDB - Úvod
Ten tvůj příspěvek ukazuje, že jsi diskuzi četl a myslíš si, že SQL má svoje "výhody". Jaký to má ale smysl od anonymního uživatele, to mi zůstává ukryto.
xkucf03 avatar 21.6.2014 00:50 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: PoniDB - Úvod
zůstává ukryto

Ten přínos/smysl má pro tebe hodnotu NULL na škále od 1 do 10.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, Relational pipes (AWK)

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.