Názory k článku Pole v PostgreSQL
-
Ondrej (neregistrovaný)
Polia su dobre a kopec veci vedia zjednodusit. Puritani vsak namietaju ze ich treba dekonponovat do dalsej tabulky (niekedy je to skutocne ta spravna cesta)
Na jediny problem co som nazrazil je ze PHP polia nepodporuje a takze spat dostanem string: {xxx,xxxx,x,„x,xx“,xxx} ktory treba parsovat :(
-
Dost komplexne popisane, ale skor zo strany PostgreSQL. Mozno by niekoho zaujimala zjednodusena implementacia riesenia ulozenia array z PHP do PostgreSQL. Pred par dnami som napisal clanok zrovna k tejto tematike na svojom blogu. Pokial by bol zaujem a nepokladate to za spam.
http://brano.kalnet.sk/branislav-durina/ulozenie-pola-z-php-do-postgresql-prostrednictvom-pdo/ -
Polia pouzivam dlhe roky a mozem povedat, ze bez nich si to uz neviem predstavit. Pole sa da pouzit aj ako MN referencia. Len je tu jediny problem, ze nad polom sa neda spravit contstraint. Vyhoda je, ze je to omnoho rychlejsie ako tahat data z MN tabulky. Co sa pri vacsich objemoch dat hodi.
Co sa tyka PHP a konverzia na string. Mohli to dotiahnut v PDO drivery, bohuzial sa tak nestalo. -
No, s tím že pole je super náhrada za vazební tabulku v případě M:N vazeb si dovolím zásadně nesouhlasit. Už to že na tom nelze definovat standardní constraint je zásadní chyba – nevím jak Vám, ale mne na konzistenci dat docela záleží. Nechci trávit hodiny opravami konzistencí které vznikly „příliš chytrým řešením.“
A co se rychlosti týká, velmi výrazně závisí na použití. Beru že pokud potřebujete načíst tu hlavní tabulku a jenom „sem tam“ nějaké závislé záznamy (na základě ID z pole v řádku hlavní tabulky), tak to může být rychlejší. Ale jakmile procento načítaných záznamů vzroste nad určitou mez (a to v řádu jednotek procent), tak to bude výrazně pomalejší než využití JOINu přes vazební tabulku.
A to z toho prostého důvodu že zatímco v případě použití pole vlastně simulujete „nested loop“ join (a tedy náhodný přístup), PostgreSQL může zvolit optimální způsob joinování těch tabulek.
Nehledě na to že pokud potřebujete v té hlavní tabulce vyhledávat podle těch podřízených záznamů, tak je to úplně v háji …
-
Proč?!
Nic takového jsem rozhodně netvrdil – netvrdím že je SQL dokonalý jazyk, to určitě není – ale rozhodně si nemyslím že by SQL byl omyl. Ne, určitě to není bezchybná specifikace (už proto že se v některých ohledech nedrží principů definovaných E. F. Coddem), ale je to krok správným směrem.
Ostatně zajímalo by mne kde jste z mého postu vyčetl jakoukoliv spojitost s SQL – já jsem se tam o něm ani slovem nezmiňoval a ani se ho to nějak netýká.
Jediné k čemu jsem se tam vyjadřoval jsou žádoucí vlastnosti relační struktury, v tomto případě „atomičnost“ hodnot ve sloupci tabulky – což je právě princip porušovaný vkládáním polí (tj. strukturovaných dat) namísto „relačně správného“ využití vazební tabulky.
A to s SQL nemá vůbec nic společného …
-
Přiznávám že „D“ neznám (což ze mne ve vašich očích dělá nepochybně činí ignoranta), takže děkuji za zajímavé téma ke studiu. Stáhl jsem si „The third manifesto“ a zítra cestou do práce si to přečtu.
Každopádně z letmého nahlédnutí do manifestu a textů na wikipedii jsem pochopil že je to jakýsi návrh dotazovacího jazyka který by v ideálním případě měl nahradit SQL a jednak opravit nedostatky SQL a jednak pomoci překlenout přirozenou propast mezi relační a objektovou strukturou.
Každopádně ale „D“ v žádném případě nemůže vyřešit problémy typu
http://www.root.cz/…zory/315984/
tj. použití pole k ukládání odkazů na závislé záznamy namísto korektní vazební tabulky. To „D“ ani žádná jiná technologie vyřešit nemůže, to je totiž problém vývojáře který chybně navrhl schéma a posléze ho nevhodně používá.
Pokud mi ale vysvětlíte jak „D“ takovýmto chybám zabrání, budu velice rád.
-
Čili něco jako „nested table“ v Oracle, chápu to správně? Upřímně řečeno, jsem OCP Certified Professional PL/SQL Developer, a o nested tables si myslím svý (a není to nic moc pěknýho).
Každopádně smyslem mé poznámky bylo že žádná technologie nemůže zabránit chybám v designu aplikace – pokud to někdo nadesignuje špatně (pole namísto vazební tabulky, atd.) tak to technologie nezachrání. Je možný že „D“ opraví chyby v SQL, ale tomuhle se prostě technologií zabránit nedá.
-
Nechtěl byste o tom udělat přednášku pro Prague Developers Day? Nepochybně je to zajímavá technologie – i když zatím cca 10 let pouze v teoretické rovině (nicméně již existují dva prototypy).
Jako jistý nedostatek D bych viděl ortodoxní požadavky na relační model. Od toho SQL posledních 20 let ustupuje – což pan Date nepochybně nevidí rád. Ať už je to NULL – nedovedu si představit, že by programátoři akceptovali vyšší normální formy kvůli neexistenci NULL, když podle Vás mají problémy s 3NF, nebo nejrůznější nerelační rozšíření SQL – rekurzivní dotazy, analytické dotazy. Na druhou stranu, právě v tom D může být zajímavé, jako úplný minimalistický jazyk – prostě čistá panenská technologie.
-
Petr (neregistrovaný)
Také nevím zda jste myslel samotný jazyk SQL nebo relační databáze jako takové.
SQL byl navržen tak, aby se co nejvíce podobal přirozenému jazyku. Ano, nebýt toho, mohl být navržen formálněji a účelněji. Ovšem nemohu říct, že by mi jeho používání způsobovalo nějaké problémy.
A pokud by šlo o relační databáze jako o celek. Tak vám mohu říct, že nic lepšího (pro obecnou práci s daty) nebylo za posledních 50 let vymyšleno. Jestli o něčem lepším víte, tak sem s tím, moc by mě to zajímalo.
-
Tak přiznám se že smysl vaši poznámky nechápu, resp. nerozumím na kterou část předchozího příspěvku reagujete :-(
To že jazyk SQL byl navržen tak aby alespoň vzdáleně připomínal angličtinu je fakt, stejně jako konstatování že bez tohoto zabudování „přirozeného jazyka“ mohla specifikace být formálně správnější a snad i čistší. Ale tak to prostě je, a naopak tato „přirozená formulace“ dotazů je jedním z důvodů proč je SQL tak populární …
Co se týká JOINů – neumím jednoznačně zodpovědět důvody proč se jim někteří vývojáři vyhýbají, ale viděl bych například následující dva důvody:
1) připadá jim to příliš složité a jsou líní si o tom sami něco přečíst
2) neznají základy návrhu relačního modelu dat (v tomto případě dekompozici)
Souvisí to s tím že joinování je pokládáno za „pokročilé téma“ a tudíž je to v knížkách až někde na konci – samouk se k tomu často nedostane, na přednášce se to nestihne probrat, atd.
Nicméně opět – toto není problém SQL jako takového, to je otázka samotného relačního modelu. Ať navrhnete jakýkoliv dotazovací jazyk, vždy v něm budete muset řešit kompozici a dekompozici.
-
Souhlas. A v článku je to zmíněno – pole svádí k tomu, aby programátor přestal myslet „relačně“. To, že to databáze dovolí, neznamená, že je to správný postup. Žádná SQL databáze nemá optimalizovaný planner pro nerelační provoz – takže plán dotazů může být absolutně mimo. Navíc se připravíte o SQL. Netuším, proč se programátoři bojí JOINů?
-
Netuším, proč se programátoři bojí JOINů?
Tipuji, že je to dané strukturou snad všech seriálů o SQL. Začíná to velmi triviálním SELECT (jedna tabulka, jeden sloupec), INSERT s tím související, vytvoření DB a tabulky. Pak to vše naráz spadne do nejednoduchých CONSTRAINů a JOINů nad x tabulkami s y sloupci. Toto se lidé zaleknou (asi právem) a zůstanou u těch SELECTů s WHERE (na úrovni právě JOIN b ON a.id = b.a_id) a zbytek si vyřeší v PHP.
Rozhodně bych tento typ WHERE konstrukce vynechal a zařadil JOIN jako součást příkazů SELECT hned od začátku. Na co nejjednodušším schematu.
-
Problém je v tom že pokud je to čistě výuka SQL bez základů relační algebry, tak čitatel často vůbec netuší cože to je ta „relace,“ proč se dělá dekompozice na více tabulek, o normálních formách ani nemluvě, atd. A to se pak těžko vysvětluje proč je vlastně joinování potřeba …
Osobně za většinu úvodních znalostí vděčím p. Halaškovi z FELu – pokud tu někdo chodí na ČVUT a má možnost zapsat si jeho přednášku na databázové systémy (pokud to teda ještě učí), tak vřele doporučuji. Nebo si alespoň sežeňte jeho skripta „Databázové systémy“ – má to odhadem 100 stránek, a je to brané pěkně od začátku. Ale pochopitelně to není učebnice SQL – většina je věnována právě relační algebře, kopozici a dekompozici, atd.
-
Petr (neregistrovaný)
Tak použití pole v rámci jednoho atributu pro vazbu M:N je už vážně silné kafe. Práce s relační databází by měla probíhat ve smyslu množin a operací nad nimi. A ne jako s nějakým udělátkem pro strčení nějakých dat sem nebo tam. Co se týká rychlosti, tak při vhodném návrhu schématu a dotazů jsou současné relační databáze rychlé dostatečně.
-
Docela dlouho jsem si s podobným chápáním relace vystačil. Nejspíš záleželo, kde a s čím člověk začal. Za mě (na výšce) se dělalo vše (včetně výuky) ve Foxce, o SQL bohužel neměl nikdo páru :(. Na druhou stranu, alespoň pro mne nematematika, je relace coby vazba dvou tabulek více-méně jeden speciální případ obecnější matematické definice – beru-li ovšem jako relaci výsledný produkt spojení tabulek, nikoliv samotnou vazbu.
-
ok – znam databazi, kde datovy typ relace predstavoval pole ukazatelu.
Jinak k Vasi puvodni otazce – pole muze obsahovat krome skalarnich hodnot, take kompozitni hodnoty – tudiz lze prevest tabulku do jedne hodnoty.
postgres=# create table f(a int, b int, c int); CREATE TABL postgres=# create table ff(v f[]); CREATE TABLE postgres=# insert into f values(10,20,30),(40,50,60); INSERT 0 2 postgres=# insert into ff select array(select row(a,b,c)::f from f); INSERT 0 1 postgres=# select * from ff; v ----------------------------- {"(10,20,30)","(40,50,60)"} (1 row) postgres=# select unnest(v) from ff; unnest ------------ (10,20,30) (40,50,60) (2 rows) postgres=# select (unnest(v)).* from ff; a | b | c ----+----+---- 10 | 20 | 30 40 | 50 | 60 (2 rows)
ČLÁNKY DO MAILU