LINUXSOFT.cz Přeskoč levou lištu
Uživatel: Heslo:  
   CZUKPL

> PostgreSQL (13) - Na co se zapomnělo

Tř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.

27.7.2005 06:00 | MaReK Olšavský | Články autora | přečteno 15806×

Schémata

Pro 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 CREATE SCHEMA [jmeno] [AUTHORISATION uzivatel][ element schematu[ ...]], kde jednotlivé položky mají následující význam:

  • jmeno pod kterým bude schéma dostupné. Není-li použito, je nutné zadat parametr AUTHORISATION
  • AUTHORISATION udává uživatele, který bude oprávněn k danému schématu přistupovat. Není-li nastaven název schématu, je toto jméno použito jako název schématu.
  • element schematu je například příkaz k vytvoření objektu (typu, stored procedury, tabulky) příslušného ke schématu. Jednotlivé příkazy se neoddělují středníky, ale ten je teprve za posledním z nich. Při vytváření těchto entit databáze není nutné používat kvalifikovaný (dlouhý) název, ale dostačuje krátký, entity lze definovat kdykoliv později.

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 DROP SCHEMA jmeno [, ...] [CASCADE | RESTRICT], kde jméno schématu je povinné (lze jich uvést několik, není třeba rušit každé zvlášť. Dalším parametrem je CASCADE, pro zrušení všech objektů patřících do tohoto schématu, nebo RESTRICT, kdy schéma není zrušeno, pokud obsahuje nějaké objekty.

Změna parametrů schématu se provádí příkazem ALTER SCHEMA. Před 8. řadou PgSQL bylo možné pouze změnit název schématu pomocí ALTER SCHEMA jmeno RENAME TO nove_jmeno, ale od 8. řady lze změnit i uživatele oprávněného k danému schématu přistupovat příkazem ALTER SCHEMA jmeno OWNER TO novy_vlastnik, přičemž tuto druhou operaci smí provádět jen superuživatel databáze.

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 public.tabulka, nebo pouze krátkého jména, kdy se použije pouze název tabulky. Pochopitelně, jsou-li v databázi definována schémata a není-li použito kvalifikovaného jména, je tabulka hledána ve schématu public.

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 SELECT sloupce FROM tabulka1 [INNER [LEFT | RIGHT | FULL] | OUTER] JOIN tabulka2 USING (sl1, sl2);, kde část USING (sl1, sl2) je ekvivalentní zápisu ON (tabulka1.sl1=tabulka2.sl1 AND tabulka1.sl2=tabulka2.sl2).

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 SELECT * FROM tabulka1 NATURAL [INNER [LEFT | RIGHT | FULL] | OUTER] JOIN tabulka2;. Jak je vidět, chybí uvedení sloupců, čili databáze si musí najít sama sloupce které jsou stejného jména a typu a přes něž může spojení provést. Výhodou je kratší zápis, nevýhodou bude vymýšlení unikátních názvů sloupců, které jsou spojeny (na toto lze narazit při tvorbě cms (content management system), kdy rubriky i články budou mít datum poslední editace, ale steží jejich shoda bude spojovací podmínkou) a pravděpodobně toto spojení bude i pomalejší (autorem netestováno), než při implicitním vyjmenování sloupců.

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ěru

Vš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 LIMIT (počet_řádek | ALL) a OFFSET číslo_prvního_řádku, řádky jsou počítány od 0 (nuly). V MySQL režii těchto dvou příkazů obstarává pouze LIMIT start, počet_řádek, v případě použití jediného parametru je tento použit jako počet_řádek a start je nastaven na hodnotu 1 (slovy jedna). Číslování řádek je virtuální a řídí se uspořádáním výsledků, které je určeno klauzulí ORDER BY. Jak praví staré přísloví, šedivá je teorie, zelený strom života, mnohem lepší, než popis bude několik příkládků.

-- 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ěrem

V 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.

Verze pro tisk

pridej.cz

 

DISKUZE

trik pro testovani dotazu nad velkymi tabulkami 28.7.2005 23:50 Petr Aubrecht




Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

14.11.2017 16:56 /František Kučera

Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt – tradičně první čtvrtek před třetím pátkem v měsíci: 16. listopadu od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).


Přidat komentář

12.11.2017 11:06 /Redakce Linuxsoft.cz
PR: 4. ročník odborné IT konference na téma Datová centra pro business proběhne již ve čtvrtek 23. listopadu 2017 v konferenčním centru Vavruška, v paláci Charitas, Karlovo náměstí 5, Praha 2 (u metra Karlovo náměstí) od 9:00. Konference o návrhu, budování, správě a efektivním využívání datových center nabídne odpovědi na aktuální a často řešené otázky, např Jaké jsou aktuální trendy v oblasti datových center a jak je využít pro vlastní prospěch? Jak zajistit pro firmu či jinou organizaci odpovídající služby datových center? Podle jakých kritérií vybrat dodavatele služeb? Jak volit součásti infrastruktury při budování či rozšiřování vlastního datového centra? Jak efektivně spravovat datové centrum? Jak eliminovat možná rizika? apod.
Přidat komentář

13.9.2017 8:00 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt – tentokrát netradičně v pondělí: 18. září od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

3.9.2017 20:45 /Redakce Linuxsoft.cz
PR: Dne 21. září 2017 proběhne v Praze konference "Mobilní řešení pro business". Hlavní tématy konference budou: nejnovější trendy v oblasti mobilních řešení pro firmy, efektivní využití mobilních zařízení, bezpečnostní rizika a řešení pro jejich omezení, správa mobilních zařízení ve firmách a další.
Přidat komentář

15.5.2017 23:50 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt, který se bude konat ve čtvrtek 18. května od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

12.5.2017 16:42 /Honza Javorek
PyCon CZ, česká konference o programovacím jazyce Python, se po dvou úspěšných ročnících v Brně bude letos konat v Praze, a to 8. až 10. června. Na konferenci letos zavítá např. i Armin Ronacher, známý především jako autor frameworku Flask, šablon Jinja2/Twig, a dalších projektů. Těšit se můžete na přednášky o datové analytice, tvorbě webu, testování, tvorbě API, učení a mentorování programování, přednášky o rozvoji komunity, o použití Pythonu ve vědě nebo k ovládání nejrůznějších zařízení (MicroPython). Na vlastní prsty si můžete na workshopech vyzkoušet postavit Pythonem ovládaného robota, naučit se učit šestileté děti programovat, efektivně testovat nebo si v Pythonu pohrát s kartografickým materiálem. Kupujte lístky, dokud jsou.
Přidat komentář

2.5.2017 9:20 /Eva Rázgová
Putovní konference československé Drupal komunity "DrupalCamp Československo" se tentokrát koná 27. 5.2017 na VUT FIT v Brně. Můžete načerpat a vyměnit si zkušenosti z oblasti Drupalu 7 a 8, UX, SEO, managementu týmového vývoje, využití Dockeru pro Drupal a dalších. Vítáni jsou nováčci i experti. Akci pořádají Slovenská Drupal Asociácia a česká Asociace pro Drupal. Registrace na webu .
Přidat komentář

1.5.2017 20:31 /Pavel `Goldenfish' Kysilka
PR: 25.5.2017 proběhne v Praze konference na téma Firemní informační systémy. Hlavními tématy jsou: Informační systémy s vlastní inteligencí, efektivní práce s dokumenty, mobilní přístup k datům nebo využívání cloudu.
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

18.9.2017 14:37 / Rojas
high security vault

15.9.2017 7:33 / Wilson
new zealand childcare jobs

31.8.2017 12:11 / Jaromir Obr
Re: ukůládání dat ze souboru

30.7.2017 11:12 / Jaromir Obr
Národní znaky

27.7.2017 12:24 / Jaromir Obr
Cteni/zapis

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2017) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze