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í
×
včera 12:33 | Pozvánky

Příští týden bude na MFF UK zahájena série přednášek o architektuře a implementaci operačních systémů. Mezi přednášejícími budou odborníci z firem Kernkonzept, Oracle, Red Hat, SUSE či SYSGO. Pokud si chcete rozšířit obzory (virtualizace, ptrace, ZFS, kdump, ...), vyberte si z harmonogramu téma, které vás zajímá a přijďte. Přednášky se konají každý čtvrtek od 15:40 v učebně S4 na Malostranském náměstí 25 v Praze. Přednášky jsou přístupné veřejnosti (registrace není nutná), studenti UK a ČVUT si je mohou zapsat jako standardní předmět.

Vojtěch Horký | Komentářů: 5
včera 05:00 | Nová verze

Bylo vydáno Ubuntu 18.04.2 LTS, tj. druhé opravné vydání Ubuntu 18.04 LTS s kódovým názvem Bionic Beaver. Přehled novinek v poznámkách k vydání a v přehledu změn.

Ladislav Hagara | Komentářů: 0
včera 03:00 | Zajímavý software

Git History umí u souborů v git repozitářích zajímavým způsobem zobrazit jejich historii a následně jednotlivé změny, viz animovaný gif. Použít jej lze lokálně nebo aktuálně na soubory umístěné na GitHubu. Máte-li ve webovém prohlížeči zobrazen soubor umístěný na GitHubu, nahraďte v URL doménu github.com doménou github.githistory.xyz a nové URL odešlete. Využít lze také rozšíření Chrome i Firefoxu. V plánu je vedle GitHubu také podpora GitLabu a Bitbucketu.

Ladislav Hagara | Komentářů: 3
včera 01:00 | Nová verze

Byla vydána verze 1.0 webové a na frameworku Electron postavené desktopové verze svobodného decentralizovaného skupinového komunikátoru Riot (Wikipedie) využívajícího protokolu Matrix (Wikipedie). Přehled novinek i s náhledy v příspěvku na blogu. Zdrojové kódy jsou k dispozici na GitHubu.

Ladislav Hagara | Komentářů: 4
14.2. 14:22 | Nová verze

Společnost Collabora oznámila vydání verze 4.0 online kancelářského balíku Collabora Online a také Collabora Online Development Edition (CODE) pro domácí uživatele. Kancelářský balík vychází z LibreOffice Online (cgit).

Ladislav Hagara | Komentářů: 0
14.2. 12:11 | Nová verze

Byla vydána verze 241 správce systému a služeb systemd (GitHub, NEWS). Řešeny jsou také bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
14.2. 11:44 | IT novinky

Evropský parlament, Komise a Rada (trialog) se dohodli na návrhu reformy autorského práva včetně kontroverzních článků 11 a 13. Více v příspěvku na blogu europoslankyně Julie Redy.

Ladislav Hagara | Komentářů: 11
14.2. 07:00 | Komunita

Čtenářům a čtenářkám AbcLinuxu vše nejlepší k Valentýnu aneb Dni lásky ke svobodnému softwaru (FSF, I love Free Software Day, #ilovefs).

Ladislav Hagara | Komentářů: 3
14.2. 06:00 | Zajímavý článek

Jiří Eischmann se v příspěvku Lepší zvuk přes Bluetooth na Linuxu (en) na svém blogu věnuje možnostem přenosu audia mezi linuxovým desktopem a bezdrátovými sluchátky. Zatímco „po drátě“ jde zvuk v nekomprimované podobě, Bluetooth má omezenou propustnost, a proto se musí použít nějaký kompresní kodek. Které kodeky může Linux nabídnout?

Ladislav Hagara | Komentářů: 19
13.2. 15:22 | Bezpečnostní upozornění

Správce balíčků snapd on Canonicalu obsahuje zranitelnost CVE-2019-7304 nazvanou Dirty Sock, kterou může útočník zneužít k eskalaci práv na úroveň administrátora. Ke zranitelnosti je k dispozici PoC (Proof of concept). Je zneužitelná pouze lokálně, pokud má útočník do systému přístup a týká se všech linuxových distribucí s nainstalovaným snapd (zejména distribuce Ubuntu, kde je snapd nainstalován automaticky). Snapd od verze 2.37.1 už je opraven [CSIRT.CZ].

Ladislav Hagara | Komentářů: 0
Máte v desktopovém prostředí zapnutou zvukovou znělku po přihlášení se do systému?
 (7%)
 (1%)
 (90%)
 (1%)
Celkem 325 hlasů
 Komentářů: 11, poslední 14.2. 07:59
Rozcestník

Tvorba databází v MySQL - IV

10. 4. 2003 | David Hauzar | Návody | 27498×

V tomto díle se naučíte správně používat klíče a zabudované fulltextové vyhledávání. Nakonec se seznámíte s problematikou zamykání záznamů.

Pokud jste se už naučili jazyk SQL, můžete se svými znalostmi vytvořit dobře strukturovanou databázi, pomocí příkazů SQL ji můžete dokonce zaplnit daty a dotazy z ní získávat data. Nenechte se tím zmást a vězte, že jste stále ještě na začátku cesty poznání databázového systému MySQL.

Dnes se seznámíte s trochu pokročilejšími aspekty tvorby databází - klíči a zamykáním záznamů.

Klíče (indexy)

Při předchozím studiu jste se setkali s primárními klíči. Dnes se budu zabývat klíči komplexněji.

Klíče (nebo také indexy) urychlují vyhledávání v databázi. Pokud přidáme do tabulky klíč, vlastně ji setřídíme.

Je tedy vhodné používat klíče v těchto případech:

  • použití klíčů zvyšuje rychlost vykonání příkazu WHERE. Pokud se tedy pole často vyskytuje v příkazu WHERE, je vhodné přiřadit mu klíč.
  • použití klíčů také zvyšuje rychlost vykonání příkazu ORDER BY a GROUP BY.
  • použití klíčů zvyšuje rychlost vykonání funkcí MIN() a MAX()
  • klíče jsou také prostředkem k vytváření relací

Naopak není vhodné použít klíč v těchto případech:

  • tabulky, do nichž se často zapisuje
  • není vhodné indexovat sloupec, jehož hodnota je často stejná (například pohlaví, titul, ...)
  • pokud je už v dané tabulce příliš mnoho sloupců s klíči

K manipulaci s klíči lze v MySQL použít tyto příkazy:

(

Poznámka ke konvenci zápisu syntaxe příkazů:

ALTER TABLE tabulka ADD {KEY | INDEX} index ({sloupec1, sloupec2,...});
ALTER TABLE tabulka ADD UNIQUE index ({sloupec1, sloupec2,...});
ALTER TABLE tabulka ADD PRIMARY KEY index ({sloupec1, sloupec2,...});

[slovo] - slovo uzavřené v těchto závorkách je nepovinné

{slovo1, slovo2, slovo3} - minimálně jedno z uvedených slov musí být uvedeno

[slovo1| slovo2] - jedno z těchto slov bude může být nepovinně uvedeno

)

Pokud budete chtít klíč odstranit, nahradíte slovo ADD slovem DROP

Toto je upřednostňovaný postup při vytváření klíčů. Můžete ale také použít tyto příkazy:

CREATE INDEX index ON tabulka ({sloupec1, sloupec2,...}]);
CREATE UNIQUE INDEX [index] ON tabulka ({sloupec1, sloupec2,...});
CREATE PRIMARY KEY ON tabulka ({sloupec1, sloupec2});

Klíče můžete také definovat při vytváření tabulky:

CREATE TABLE tabulka (sloupec datovýtyp [NULL | NOT NULL],
  KEY col_index(sloupec));

Informace o klíčích v dané tabulce zobrazíte pomocí příkazu:

SHOW {KEYS | INDEX} FROM tabulka

Jednopoložkové klíče

Jednopoložkové klíče jsou nejjednodušší klíče. Jednopoložkový klíč k sloupci Jmeno_Prokuktu vytvoříte například takto:

ALTER TABLE Produkty ADD KEY produkt_idx (Jmeno_Produktu);

Vícepoložkové (složené) klíče

Pokud k definici klíče použijete více než jedno pole, vytvoříte vícepoložkový klíč. Vícepoložkový klíč vytvoříte například takto:

ALTER TABLE Produkty ADD KEY sloz_idx (Jmeno_Produktu, Zeme_Puvodu, Barva);

Rozdíl mezi jednoduchým a složeným klíčem můžete vidět v následující tabulce:

Jednopoložkové a složené klíče
Jmeno_Produktu Zeme_Puvodu Barva produkt_idx sloz_idx
Monitor China Šedá Monitor MonitorChinaŠedá
Myš Japan Šedá Myš MyšJapanŠedá
Klávesnice Japan Černá Klávesnice KlávesniceJapanČerná

Zkuste po vytvoření složeného indexu zadat příkaz:

SHOW KEYS FROM tabulka;

Při používání vícepoložkových klíčů je dobré řídit se následujícími pravidly:

  • Na prvním místě uveďte nejvíce omezující podmínku (např. sloupec Jmeno_Produktu je více omezující než sloupec Zeme_puvodu).
  • při psaní dotazů kritéria klauzule sestavujte tak, aby se v ní objevilo první pole vícepoložkového klíče. To zajistí, že bude tohoto klíče použito.
  • Vícepoložkové klíče zatěžují databázi více, než jednopoložkové klíče.

Částečné klíče

Částečné klíče se používají pro indexování určitého počtu prvních znaků sloupce textového datového typu.

Částečné klíče je vhodné použít, pokud by mohl být indexovaný sloupec příliš dlouhý. Částečný klíč vytvoříte například takto:

ALTER TABLE Produkty ADD KEY produkt_idx (Jmeno_Produktu(5));

Složené částečné klíče

Složený klíč můžete samozřejmě skládat i z částečných klíčů.

Používání částečných klíčů je výhodné, protože bývají kratší a jejich výkon je tedy zpravidla vyšší.

Jedinečné klíče

Jedinečné klíče nedovolují v indexovaných polích existenci duplicitních položek. Tabulka může obsahovat více než jeden jedinečný klíč. Jedinečný klíč vytvoříte příkazem:

ALTER TABLE tabulka ADD UNIQUE index (pole[...]);

Primární klíče:

Primární klíč je speciální typ jedinečného klíče. Na rozdíl od běžného jedinečného klíče smí být v tabulce pouze jeden primární klíč a pole definované jako primární klíč nesmí obsahovat prázdné hodnoty (NULL).

Primární klíč se používá pro vytvoření relace mezi tabulkami.

Vícepoložkové primární klíče

Pokud nelze jedinečnost primárního klíče zajistit pomocí jednoho pole, používá se vícepoložkový primární klíč. Vícepoložkový primární klíč nelze vytvořit pomocí příkazu CREATE TABLE, ale jedině pomocí příkazu ALTER TABLE. Složený primární klíč vytvoříte například takto:

ALTER TABLE Produkty ADD PRIMARY KEY (Jmeno_Produktu, Zeme_Puvodu);

Pokud vytvoříte takový primární klíč, nebudete moci mít v dané tabulce více produktů stejného názvu a stejné země původu!

Můžete samozřejmě vytvořit i složený částečný primární klíč.

Syntetické (náhradní) klíče

Vytvoření primárního klíče z reálných dat bývá často nevhodné. Často se jen těžko hledá taková kombinace sloupců, která je pokaždé jiná.

V takových případech je nejlepší vytvořit syntetický klíč. To je sloupec speciálně vytvořený pro to, aby se stal primárním. Je to tedy sloupec, který obsahuje data, která bychom jinak nepotřebovali. V našem příkladě bychom vytvořili pro každý produkt jedinečné identifikační číslo.

Naši tabulku vytvoříte příkazem:

CREATE TABLE Produkty (ID_Produktu INT(8) AUTO_INCREMENT
  PRIMARY KEY NOT NULL, Jmeno_Produktu VARCHAR(20), ...)

Fulltextové klíče

Fulltextové klíče jsou v MySQL poměrně nové - jejich podpora byla do MySQL přidána ve verzi 3.23.23.

Fulltextový klíč se smí vytvářet pouze ze sloupců typu VARCHAR a TEXT. Fulltextový klíč vytvoříte například takto:

ALTER TABLE Knihy ADD FULLTEXT INDEX (Nazev_Knihy, Ukazka);

V takto indexovaných sloupcích můžete použít velmi rychlé fulltextové vyhledávání. Vyhledávání se realizuje pomocí klíčových slov MATCH(pole_ve_kterem_chcete_hledat1, pole_ve_kterem_chcete_hledat2, ...) a AGAINST(hledaný výraz).

Pokud použijete klíčová slova MATCH a AGAINST v klauzuli WHERE, výsledný výpis bude sestupně setřízený podle četnosti hledaných slov v prohledávaných sloupcích.

Pokud hledaný výraz obsahuje víc slov, bere MySQL při výpočtu četnosti hledaných slov v prohledávaných sloupcích ohled i na to, jaké ze slov je obsaženo ve více záznamech. To, které je obsaženo ve více záznamech, má menší váhu (pokud je obsaženo v 50 a více procentech záznamů, tak nemá dokonce žádnou váhu - viz dále ), protože má menší sémantickou hodnotu. (slovo, které je v méně záznamech pravděpodobně určuje blíže, to co chcete najít)

Pozor:

  • Fulltextové vyhledávání můžete používat jen s tabulkami MyISAM (defaultní typ tabulek v MySQL).
  • Sloupce předávané jako parametry funkce MATCH() musí být ze stejné tabulky a musí být částí stejného fulltextového klíče.
  • Parametr konstrukce AGAINST musí být řetězec.
  • Pokud je hledané slovo kratší než 4 znaky, MySQL ho ignoruje.
  • Pokud se hledané slovo vyskytuje v 50 a více procentech záznamů, MySQL ho také ignoruje. Má to své opodstatnění - hledání pak ztrácí smysl. (Pokud se nějaké slovo vyskytuje v padesáti a více procentech záznamů, těžko vám pomůže najít to, co hledáte - to už můžete záznamy prohledávat "ručně").
  • Předchozí dvě omezení neplatí v boolean režimu (viz dále). Můžete je také upravit nebo zrušit přepsáním příslušných symbolických konstant ve zdrojovém kóku a následnou kompilací MySQL - viz manuál čát 6.8.2 Fine-tuning MySQL Full-text Search
  • To, zda-li je fulltextové vyhledávání case-sensitive, nebo case-insensitive závisí na použitém charsetu. Čeština je na rozdíl od většiny case-sensitive :-(.

Od verze 4.0 podporuje MySQL v hledaných výrazech dokonce i booleanovské operátory. Můžete použít tyto operátory:

  • + (+slovo znamená, že slovo musí být obsaženo v každém záznamu)
  • - (-slovo znamená, že slovo nemusí být obsaženo v každém záznamu)
  • < a > mohou být užity ke zvýšení/snížení váhy slova
  • ~ může být použit k udělení negativní váhy slovu
  • * zástupný operátor

Příklady:

SELECT * FROM Knihy WHERE MATCH (Nazev_Knihy, Ukazka) AGAINST ('databáze');

Tento dotaz vrátí všechny záznamy obsahující ve sloupci Nazev_Knihy nebo ve sloupci Ukazka slovo databáze. Výpis bude sestupně setřízený podle procentuální četnosti hledaných slov.

SELECT ID_Knihy, MATCH (Nazev_Knihy, Ukazka) AGAINST ('databáze') as Score FROM Knihy;

Tento dotaz zobrazí sloupec ID_Knihy a sloupec Score, ve kterém bude číslo (0 znamená, že v daných prohledávaných sloupcích se slovo databáze nevyskytuje, desetinné číslo určuje četnost slova databáze v prohledávaném sloupci vztaženou na počet slov tohoto sloupce => čím větší číslo, tím větší procentuální četnost) všech záznamů z tabulky Knihy. Výpis nebude setřízený

SELECT ID_Knihy, MATCH (Nazev_Knihy, Ukazka) AGAINST ('databáze') as score FROM Knihy
  WHERE MATCH (Nazev_Knihy, Ukazka) AGAINST ('databáze');

Jako předchozí dotaz, ale záznamy setřídí a vypíše jen záznamy, ve kterých se tato hledaná slova vyskytovala.

Zamykání záznamů

K databázi může přistupovat více lidí současně. Pokud je nějaký dotaz na databázi závislý na aktuálním stavu dat, který by jiný dotaz mohl změnit, je nutné uzamknout příslušný záznam.

Taková situace by mohla nastat, pokud bychom v databázi evidovali množství zásob na skladu a podle toho určovali dodací lhůty. Jeden proces by zjistil množství zásob na skladu, vypočítal by dodací lhůtu a pak by odečetl objednané zboží od zboží na skladu. Pokud by ale do databáze přistoupil druhý proces těsně po prvním (ještě před tím, než první odečte objednané zboží od zboží na skladu), získal by špatná data.

Syntaxe příkazu:

LOCK TABLES tabulka1 [AS alias] {READ | [LOW_PRIORITY] WRITE}
  [, tabulka2 {READ | [LOW_PRIORITY] WRITE} ...]

Tabulku odemknete příkazem:

UNLOCK TABLES

Tabulky lze zamykat pro čtení (READ) - znamená to, že ostatní procesy budou moci z tabulky pouze číst (a nebudou do ní moci zapisovat).

Dále lze tabulky zamykat pro zápis (WRITE) - pak bude moci tabulku používat pouze proces, který ji uzamkl - získá k ní výhradní přístup.

Pokud dostane databáze více příkazů LOCK TABLES, řadí se tyto příkazy do fronty. Požadavky na výhradní přístup mají přednost před požadavky na otevření tabulek jen pro čtení.

Pokud zadáte příkaz LOW_PRIORITY WRITE, bude MySQL dávat přednost požadavkům na čtení před požadavky na výhradní přístup. Tento příkaz zadejte, pokud je ve vaší databázi důležitější otevření tabulky pro čtení než otevření tabulky ve výhradním režimu.

Zadáte-li příkaz SELECT HIGH_PRIORITY, můžete z tabulek číst, i když je na tuto tabulku vystaven požadavek na výhradní přístup.

Použití příkazu LOCK TABLES

  • Příkaz se používá k zajištění výhradního přístupu.
  • U několikařádkových operací (zejména těch, které obsahují příkaz INSERT) může dojít ke zvýšení výkonu.
  • Příkaz LOCK TABLES se používá při zálohování databáze. Pokud by někdo zapisoval do databáze v průběhu zálohování, mohla by se porušit konzistence dat.

Závěr

Dnes jste nabyli další velmi významné dovednosti potřebné ke zvládnutí MySQL. Klíče jsou nezbytné při tvorbě relací, mohou významně zvýšit vykonání klauzule WHERE. V neposlední řadě můžete použít fulltextové klíče k fulltextovému hledání.

Zamykání záznamů se používá k odstranění problémů vzniklých v důsledku mnohonásobného přístupu.

V příštím dílu se seznámíte s nejdůležitějšími funkcemi v MySQL.

       

Hodnocení: 38 %

        špatnédobré        

Nástroje: Tisk bez diskuse

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

Komentáře

Vložit další komentář

10.4.2003 10:47 Martin Kučera | skóre: 12 | Vsetín
Rozbalit Rozbalit vše Fulltext index a Innobase tabulky
Podle dokumentace k mysql je možné používat fulltext pouze u tabulek MyISAM, na to by nebylo špatné upozornit. Zkrátka, člověk si musí vybrat: transakce (InnoDB) nebo fulltext :-(
10.4.2003 14:36 Jan Kubik
Rozbalit Rozbalit vše klic versus index
z clanku mam pocit, ze autor rika klic=index - je to spravne ?
10.4.2003 15:37 romo
Rozbalit Rozbalit vše klic versus index
klic <> index
10.4.2003 17:16 Jan Kubik
Rozbalit Rozbalit vše klic versus index
ty kluku usata, ty jiste tusis, ze ja jsem chtel vedet, kde je ten rozdil !!!
12.4.2003 20:57 romo
Rozbalit Rozbalit vše klic versus index
chacha... ked to vies, na co sa pytas?
10.4.2003 18:38 xyz
Rozbalit Rozbalit vše klic versus index
autor ma v podstate pravdu pretoze kluc (klic) primarny a ostatne su automaticky indexovane.
12.4.2003 20:59 romo
Rozbalit Rozbalit vše klic versus index
nema pravdu: kluc, ktory by nebol indexom, je hlupost, ale nie kazdy index je klucom
10.4.2003 20:23 Zdeněk Štěpánek | skóre: 57 | blog: uz_mam_taky_blog | varnsdorf
Rozbalit Rozbalit vše ja to delam po svym
Zdravim Ja jsme se mysql naucil jako samouk, takze mozna mam spatny navyky, ale podobne veci vestinou delam timto zpusobem: Mam v DB polozky jmeno, prijmeni, telefon, popis apod. Tyhle vsechny spojim za sebe a prozenu to MD5 funkci a ulozim jako ID. No a tohle ID pak pouzivam vsude jinde. Mam zaruceno ze je jedinecne. Zdenek
www.pirati.cz - s piráty do parlamentu i jinam www.gavanet.org - czfree varnsdorf
12.4.2003 00:31 ja
Rozbalit Rozbalit vše ja to delam po svym
tak to je z principu md5 pouze pravdepodobne, nikoli jiste :-)
14.4.2003 14:35 rat
Rozbalit Rozbalit vše ja to delam po svym
no kdyz odhlednes od toho, ze jde o uplne zbytecny vypocet, ktery je treba provadet pri kazde zmene a jedinecnost ani neni zarucena, tak je to skoro stejne dobre jako ten autoincrement...
11.4.2003 08:16 David Hruska
Rozbalit Rozbalit vše Fulltext a case (in)sensitive
Muz mi nekdo rici zda je fulltext vyhledavani case sensitive nebo insensitive? pripadne zda je mozno udelat insensitive vyhledavani? Dekuju
12.4.2003 19:36 David Hauzar | skóre: 26 | Vimperk
Rozbalit Rozbalit vše Fulltext a case (in)sensitive
Fulltext vyhledavani je case insensitive.
12.4.2003 21:41 Henryk Paluch
Rozbalit Rozbalit vše Fulltext a case (in)sensitive
Bohuzel to zavisi na pouzitem charsetu. Treba 'czech' je jako jeden z mala case sensitive (overeno i pokusem). Citat z dokumentace: Case-Sensitivity in Searches By default, MySQL searches are case-insensitive (although there are some character sets that are never case-insensitive, such as `czech'). Chcete-li pouzivat fulltext, tak doporucuji podrobne si precist dokumentaci. Je tam popsana rada zajimavosti, napr. MATCH/AGAINST standardne ignoruje slova kratsi nez 4 znaky a take vyrazy, ktere jsou nalezeny v 50% (a vice %) radku.
12.4.2003 22:08 Henryk Paluch
Rozbalit Rozbalit vše Fulltext a case (in)sensitive
Jeste upresneni k memu poslednimu odstavci: Popisovane omezeni (<=4 znaky, >=50%) se tyka jen varianty AGAINST('slovo'). V boolean rezimu, tj. AGAINST('+slovo1 +slovo2' IN BOOLEAN MODE) uvedene omezeni neplati.
23.12.2004 11:53 Vojtech Semecky
Rozbalit Rozbalit vše Re: Fulltext a case (in)sensitive
To že je čeština case-sensitive je docela problém/nedostatek. Nevíte, jestli tato vlastnost platí i u vyšších verzí MySQL s podporou Unicodu? Myslím, jestli je case-sensitive i čeština uložená jako UTF-8.
20.4.2006 10:47 OldFrog {Ondra Nemecek} | skóre: 30 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Tvorba databází v MySQL - IV
minimalni delku slova 4 znaky a limit 50% vyskytu lze upravit:

http://dev.mysql.com/doc/refman/5.0/en/fulltext-fine-tuning.html
-- OldFrog
20.4.2006 11:01 OldFrog {Ondra Nemecek} | skóre: 30 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Tvorba databází v MySQL - IV
minimalni delku slova 4 znaky a limit 50% vyskytu lze upravit:

http://dev.mysql.com/doc/refman/5.0/en/fulltext-fine-tuning.html
-- OldFrog
20.4.2006 11:02 OldFrog {Ondra Nemecek} | skóre: 30 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Tvorba databází v MySQL - IV
PS: smazte kdyztak ten duplicitni prispevek, dik
-- OldFrog
17.4.2018 12:45 Tillyard
Rozbalit Rozbalit vše coinbaselogin
Business is presently the Largest Insurer in the US. Its solutions are mainly https://coinbaselogin.com/ Report Glass Damage and even more Consumers can build up.

Založit nové vláknoNahoru

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