|
||||||||||||||||||||||||||||||||||||||||||||||||
Menu
Distributions (131)
Software (10844)
|
PostgreSQL (13) - Na co se zapomněloTřináctý díl (smolný ;-)) bude věnován věcem, na které se v prozatimním průběhu seriálu zapomnělo, nebo jiným způsobem spadly pod stůl. Při vší snaze o pozornost občas člověku prostě něco unikne. Především se bude jednat o nedostatky, na které mě upozornili sami čtenáři seriálu.
SchémataPro programátory ve jazyce C++ bude princip pochopení asi nejjednodušší. Schémata definují jmenné prostory, obsahující tabulky, procedury, objekty, datové typy, které se tak mohou stát duplicitními v rámci jedné databáze. Používají se v momentě, kdy je k dispozici jedna databáze (například na webhostingu) a je třeba, aby na ní fungovalo několik projektů, ve kterých se mohou vyskytovat stejné tabulky (například několik oddělených webshopů v rámci jedinné domény 2. řádu). MySQL by touto funkčností měla disponovat od řady 5 (alespoň dle dokumentace). Přístup k objektům schématu je realizován kvalifikovaným jménem, to znamená, že název objektu bude prodloužen o název schématu, do kterého přísluší oddělený tečkou, název schématu se dává na místo prefixu, tj. před název objektu. Pro vytvoření schématu slouží příkaz
Bohužel na rozdíl od standardu SQL není možné nastavit pro každé schema nastavit vlastní kódování. Pokud chce vývojář předejít problémům s potřebou různých znaků v různých jazycích, je už několik let obecným doporučením použití UTF-8, ale i zde číhá drobné nebezpečí a tím je řazení (v Česku se ch řadí za h, nikolivěk, jako v angličtině k c). Pro zrušení schématu slouží příkaz Změna parametrů schématu se provádí příkazem Něco příkládků: -- Vytvoreni schematu a tabulek najednou CREATE SCHEMA keramika CREATE TABLE kategorie(id serial, jmeno varchar(200), popis text, zobrazovany char(1)) CREATE TABLE zbozi(id bigserial, jmeno varchar(200), popis text, zobrazovany(1), cenabezdph decimal(10,2), skupinadph integer) CREATE TABLE skupinydph(id serial, jmeno varchar(200), sazba decimal(4,2)) CREATE TABLE zbozi_kateg(id_zbozi bigint, id_kateg int); -- Totez vytvorene postupne CREATE SCHEMA keramika; CREATE TABLE keramika.kategorie(id serial, jmeno varchar(200), popis text, zobrazovany char(1)); CREATE TABLE keramika.zbozi(id bigserial, jmeno varchar(200), popis text, zobrazovany char(1), cenabezdph decimal(10,2), skupinadph integer); CREATE TABLE keramika.skupinydph(id serial, jmeno varchar(200), sazba decimal(4,2)); CREATE TABLE keramika.zbozi_kateg(id_zbozi bigint, id_kateg int); CREATE SCHEMA cms CREATE TABLE clanky(id serial, titulek varchar(200), perex text, obsah text, zobrazovany char(1)); -- Prejmenovani schematu a nasledna zmena vlastnika ALTER SCHEMA keramika RENAME TO ker; ALTER SCHEMA ker OWNER TO petr; -- prace s daty ve schematu ker INSERT INTO ker.kategorie(jmeno, popis, zobrazovany) VALUES ('Květináče 1','Květináče obyčejné','y'); INSERT INTO ker.kategorie(jmeno, popis, zobrazovany) VALUES ('Květináče 2','Květináče zdobené a bílé','y'); SELECT * FROM ker.kategorie; ... Výběry (i joiny mezi tabulkami) jsou pochopitelně možné i mezi jednotlivými schématy. Pomocí kvalifikovaných jmen souborů. Byť třeba spojování tabulek mezi jednotlivými schématy může občas (ne vždy) svědčit o špatném návrhu databáze pro aplikace běžící nad ní. Samozřejmě že výběr, kdy je potřeba spojit tabulky z několika schémat smí provádět pouze uživatel, který má do všech potřebných schémat přístup. INSERT INTO cms.clanky(titulek, perex, obsah, zobrazovany) VALUES ('První','První článeček vložený do redakčního systému','Toto ...', 'y'); SELECT * FROM ker.kategorie LEFT JOIN cms.clanky ON ker.kategorie.id=cms.clanky.id; Pokud vývojář/správce žádné schéma nedefinuje, je použito implicitní schéma, které je pojmenováno 'public'. Pro přístup do tohoto schématu je možné kvalifikovaného jména Spojování tabulek (JOIN)V sedmém dílu seriálu byly probírány základy výběru z tabulek, včetně jejich spojování pomocí klauzule JOIN. Od řady 7 tohoto databázového serveru přibyla možnost spojit tabulky bez uvedení spojovací podmínky (na tuto možnost autor zapoměl, protože ji nepoužívá). Zápis je poté o něco kratší a přehlednější, má ale drobné omezení. Aby server poznal, přes které sloupečky má použít spojovací tabulku, musí se tyto sloupce jmenovat stejně a měly by být stejného typu (?jak porovnat desetinné číslo a řetězec bez přetypování?). Pro příklady budou použity tabulky, které byly příslušné k 7. dílu. Zkrácený zápis je možné provést dvěma způsoby, z nichž napřed bude ukázán ten delší, který ale umožní předejít některým problémům krátkého zápisu, na něž bude upozorněno. Prvním způsobem je požití klíčového slova USING místo booleanovského spojení patřičných prvků v části ON, příkaz pak může vypadat takto Druhým způsobem je zápis i bez klíčového slova (části) USING, leč s přidáním klíčového slova NATURAL, dotaz pak vypadá takto Příklady: -- budou spojeny spatne zaznamy, protoze navrh tabulek na -- toto spojovani neni udelan SELECT t1.id AS id, login, first_name, surename, email, visible FROM users AS t1 LEFT OUTER JOIN userdetails AS t2 USING(id); SELECT t1.id AS id, login, first_name, surename, email, visible FROM users AS t1 NATURAL LEFT OUTER JOIN userdetails AS t2; Omezení počtu řádek výběruVšechny výběry, které zde byly dosud prezentovány vybíraly všechny záznamy z databáze odpovídající podmínkám, což sice může být použitelné v běžné aplikaci, ale například při tvorbě webových aplikací by toto mohlo být docela nepoužitelné. Jednou možností je vzít všechny záznamy, uložit si je do pole a přes toto pole posléze "stránkovat" v aplikaci, ale první nevýhoda je vidět hned na první pohled a tou jsou paměťové nároky na uložení takovéhoto pole. Druhým a mnohem lepší řešením je použití stránkování přímo v SQL dotazu, kdy se zadá číslo prvního záznamu a počet vrácených řádek, číslo řádku je v podstatě stránka*počet_řádek_na_stránce. Příkazy, které toto řídí jsou -- Ziskani prvniho radku SELECT * FROM users ORDER BY login LIMIT 1; -- ziskani 2 stranek po 2 uzivatelich razeno dle id SELECT * FROM users ORDER BY id LIMIT 2 OFFSET 0; SELECT * FROM users ORDER BY id LIMIT 2 OFFSET 2; ZávěremV tomto díle se autor pokusil napravit některé chybky a pozapomenuté informace, které se nabalili za několik předchozích dílů. V příštím díle budou probrány transakce, jakožto základní způsob udržení integrity dat v databázi i přes možné chyby, které mohou při komunikaci mezi databází a aplikací vzniknout.
|
Search Software
Search Google
|
||||||||||||||||||||||||||||||||||||||||||||||
©Pavel Kysilka - 2003-2024 | maillinuxsoft.cz | Design: www.megadesign.cz |