Omezení výpisu proměnné typu text
Ahoj mám v jedné bunce tabulky typu text uložen zdrojový text, chci se zeptat jestli nějak můžu při výpisu omezi tento výpis třeba pouze na 60 řádku např. nebo jiným způsobem? díky
Strejda Google mi to řekl prakticky hned:
select SUBSTRING_INDEX("www.sua.bla.uf.cz",".",2);
Tak si to zkus upravit na LF a 60.
select SUBSTRING_INDEX("www.sua.bla.uf.cz",".",2);
Tak si to zkus upravit na LF a 60.
mm.gene.cz
ja bych teda pouzil SELECT * a vyresil vypis pres php substr()
Hlavne bych omezil velikost stranky treba na 10-20k znaku. Ikdyz treba na skolnim webu mame stranky i 100k, ale na to nejsem hrdy :) Jsem proste mekky a me argumenty neberou vazne, ze to nikdo nebude cist tak dlouhe :)
ja bych teda pouzil SELECT * a vyresil vypis pres php substr()
Hlavne bych omezil velikost stranky treba na 10-20k znaku. Ikdyz treba na skolnim webu mame stranky i 100k, ale na to nejsem hrdy :) Jsem proste mekky a me argumenty neberou vazne, ze to nikdo nebude cist tak dlouhe :)
"SELECT *" je asi nejčastější prasárna v SQL. Proč chceš přetahovat desítky KB z MySQL do PHP a tam je teprve zpracovávat, když MySQL disponuje mnohem lepším arzenálem funkcí?
Kit (ekobrikety.vyrobce.cz)
O tom by se dalo dlouze diskutovat.
Toto je muj predpoklad a asi bych to i tak resil.
Pokud mas v databazi pole typu TEXT, ktere maji promennou delku, pak SELECT * nedoporucuji.
Pokud mas v databazi vsechna pole s pevne stanovenou delkou, SELECT * je podle mne nejrychlejsi reseni. Proc?
Podminkou ziskam z tabulky indexu radky 4, 7, 10.
jak nejrychleji vytahnout data? Treba ze souboru?
Vim, ze bunky maji pevnou delku, delka celeho radku je rekneme 100
seek = 400
copy = 100 znaku
seek = 700
copy = 100
seek = 1000
copy = 100
A mam hotovo.
Ano, ziskam 300 znaku, ale predpokladam, ze vetsinu z nich clovek v php pouzije, kdyz ma rozumne navrzene tabulky.
A jak to asi pracuje pri promenne delce? Predpokladam, ze pevne a promenne bunky se ukladaji zvlast. Takze pevne se vycucnou podobne a promenne pri SELECT *
z index tabulky se vycucnou indexy a soucasne se vycucne i pocatek daneho radku/bunky a jeste delka radku/bunky (coz jsou 2 operace navic nehlede a vetsi index tabulka)
seek = pocatek
copy = delka
A jak to pracuje, kdyz mas zvolene bunky?
SELECT a,b,c
Vytahnes si info o sloupcich. operace+1
seek a = pocatek
copy a = delka
seek b = pocatek
copy b = delka
seek c = pocatek
copy c = delka
To mas pro 3 sloupce 3 seeky.
Pro dynamicke pole dalsi zdrzovacka s dohledanim aktualni delky.
A pro SELECT SUBSTRING() te navic zdrzuje substringova funkce.
A ted hodne zalezi, jak mas nastaveny stroj, PC. Pokud je databaze mimo stroj a musi se spojovat pres draty, pak je lepsi co nejmene zatezovat draty a databazi a tvuj PC muzes mit pak predimenzovany aby zvladal PHP.
Pokud mas all in 1, wash and go, tak si muzes dovolit databazi brzdit substringy, sloupci a pod.
Samozrejme, kdyz tam neajky kun nacpe 20k bunky a pak vytahuje na stranku 100 radku a pro nahled mail zpravy mu staci prvnich 100 znaku, pak i v pripade 1 je lepsi pouzit SUBSTRING().
Cili souhlasim i nesouhlasim :)
O tom by se dalo dlouze diskutovat.
Toto je muj predpoklad a asi bych to i tak resil.
Pokud mas v databazi pole typu TEXT, ktere maji promennou delku, pak SELECT * nedoporucuji.
Pokud mas v databazi vsechna pole s pevne stanovenou delkou, SELECT * je podle mne nejrychlejsi reseni. Proc?
Podminkou ziskam z tabulky indexu radky 4, 7, 10.
jak nejrychleji vytahnout data? Treba ze souboru?
Vim, ze bunky maji pevnou delku, delka celeho radku je rekneme 100
seek = 400
copy = 100 znaku
seek = 700
copy = 100
seek = 1000
copy = 100
A mam hotovo.
Ano, ziskam 300 znaku, ale predpokladam, ze vetsinu z nich clovek v php pouzije, kdyz ma rozumne navrzene tabulky.
A jak to asi pracuje pri promenne delce? Predpokladam, ze pevne a promenne bunky se ukladaji zvlast. Takze pevne se vycucnou podobne a promenne pri SELECT *
z index tabulky se vycucnou indexy a soucasne se vycucne i pocatek daneho radku/bunky a jeste delka radku/bunky (coz jsou 2 operace navic nehlede a vetsi index tabulka)
seek = pocatek
copy = delka
A jak to pracuje, kdyz mas zvolene bunky?
SELECT a,b,c
Vytahnes si info o sloupcich. operace+1
seek a = pocatek
copy a = delka
seek b = pocatek
copy b = delka
seek c = pocatek
copy c = delka
To mas pro 3 sloupce 3 seeky.
Pro dynamicke pole dalsi zdrzovacka s dohledanim aktualni delky.
A pro SELECT SUBSTRING() te navic zdrzuje substringova funkce.
A ted hodne zalezi, jak mas nastaveny stroj, PC. Pokud je databaze mimo stroj a musi se spojovat pres draty, pak je lepsi co nejmene zatezovat draty a databazi a tvuj PC muzes mit pak predimenzovany aby zvladal PHP.
Pokud mas all in 1, wash and go, tak si muzes dovolit databazi brzdit substringy, sloupci a pod.
Samozrejme, kdyz tam neajky kun nacpe 20k bunky a pak vytahuje na stranku 100 radku a pro nahled mail zpravy mu staci prvnich 100 znaku, pak i v pripade 1 je lepsi pouzit SUBSTRING().
Cili souhlasim i nesouhlasim :)
<HTML>Já mám jiný úhel pohledu:
Předpokládejme ideálně funkční MySQL server a ideálně funkční PHP stroj. Předpokládejme situaci, kdy potřebujeme dostat nějaká z dat spočítaná data. Mějme dvě možnosti:
a) Získat z databáze všechna zdrojová data a výpočty provést v PHP.
b) Výpočty provést na MySQL stroji a v PHP pracovat s výsledky.
Vhodná volba je závislá na tom, jak vůbec by ta řešení vypadala.
V případě (a) je proveden výběr všech dat. Těch bude nejspíše více, než by byla data spočítaných výsledků, takže více zatížíme spojení. Poté je proženeme PHP skriptem, který je "interpretovaný" (sice je předkompilovaný při načtení) a zejména v cyklech, které stoprocentně při výpočtech využijeme, to bude znát. Další věcí je paměťová zátěž PHP stroje, který nemívá vnitřně ty struktury implementovány nejúspornějším způsobem (někdy je zábava pročítat si vnitřnosti PHP). Takže varianta (a) více zatíží spojení a PHP stroj, navíc bude pomalejší (transfer dat MySQL -> PHP a zpracování v PHP).
V případě (b) provede výpočty MySQL stroj. Jistě, dotaz bude složitější a bude se o něco déle parsovat, vlastní provedení je však rychlé - databázové servery jsou optimalizované na množinové operace a operace s daty v těchto množinách. Z MySQL serveru do PHP stroje půjde nejspíše menší množství dat a PHP skript nebude muset sjíždět ve smyčkách žádné složité výpočty. V tomto řešení klademe nároky na MySQL stroj (čas a paměťový prostor), zbytek (spojení a PHP stroj) budou zatíženy méně.
Celkově vychází (b) jako lepší řešení než (a).
Kde je chyba mé úvahy? ;) Dám 1342 bodů tomu, kdo na ni přijde.
Nápověda: Hledejte ji na začátku.</HTML>
Předpokládejme ideálně funkční MySQL server a ideálně funkční PHP stroj. Předpokládejme situaci, kdy potřebujeme dostat nějaká z dat spočítaná data. Mějme dvě možnosti:
a) Získat z databáze všechna zdrojová data a výpočty provést v PHP.
b) Výpočty provést na MySQL stroji a v PHP pracovat s výsledky.
Vhodná volba je závislá na tom, jak vůbec by ta řešení vypadala.
V případě (a) je proveden výběr všech dat. Těch bude nejspíše více, než by byla data spočítaných výsledků, takže více zatížíme spojení. Poté je proženeme PHP skriptem, který je "interpretovaný" (sice je předkompilovaný při načtení) a zejména v cyklech, které stoprocentně při výpočtech využijeme, to bude znát. Další věcí je paměťová zátěž PHP stroje, který nemívá vnitřně ty struktury implementovány nejúspornějším způsobem (někdy je zábava pročítat si vnitřnosti PHP). Takže varianta (a) více zatíží spojení a PHP stroj, navíc bude pomalejší (transfer dat MySQL -> PHP a zpracování v PHP).
V případě (b) provede výpočty MySQL stroj. Jistě, dotaz bude složitější a bude se o něco déle parsovat, vlastní provedení je však rychlé - databázové servery jsou optimalizované na množinové operace a operace s daty v těchto množinách. Z MySQL serveru do PHP stroje půjde nejspíše menší množství dat a PHP skript nebude muset sjíždět ve smyčkách žádné složité výpočty. V tomto řešení klademe nároky na MySQL stroj (čas a paměťový prostor), zbytek (spojení a PHP stroj) budou zatíženy méně.
Celkově vychází (b) jako lepší řešení než (a).
Kde je chyba mé úvahy? ;) Dám 1342 bodů tomu, kdo na ni přijde.
Nápověda: Hledejte ji na začátku.</HTML>
Chyba bude asi v tomto: Autor: Nípal (moderátor) :-)
"Předpokládejme ideálně funkční MySQL server a ideálně funkční PHP stroj"
Trefil jsem to?
Trefil jsem to?
Matematika, fyzika a vše kolem - na základní a střední škole se to naučíme. Na vysoký škole zjistíme krutou pravdu. Že by toto bylo to, co Nipal myslí? ;)
<HTML>Kit má 1342 bodů, Lama 2 body za snahu (použil při hledání nápovědu), Tomík se netrefil, navíc daná věc platná na ZŠ i SŠ platí i na VŠ.</HTML>
Podvodníku! Ideálně funkční MySQL server a PHP stroj je nanic, když není k dispozici ideálně rychlá internetová linka, která obslouží najednou desetitisíce (ideální číslo) zájemců o výsledek. Takže chyba byla v idealizaci podmínek bez ohledu na linku (takže body SEM!).
zas mi to smazalo prispevek, ja na to wz kaslu. hawk.
To zkratim, ale pak mne neobvinujte, ze je to zmatene, protoze vic proste nestiham napsat.
nipal - uvaha je spravna, pokud mas 1 databazi a 1 program. obvykle mas 1 databazi a 100 programu se vuci ni autentizuje a taha informace
Lama - najednou = 1 okamzik = max 10 lid. 60 okamziku = 60x10 nevyresenych - 60x1 vyresenych
Skynet_IV (fotbalujezd.euweb.cz) - novy sloupec, substring pri editaci, 1000x wiev, 1x editace, 1000x substring nebo 1x ?
To zkratim, ale pak mne neobvinujte, ze je to zmatene, protoze vic proste nestiham napsat.
nipal - uvaha je spravna, pokud mas 1 databazi a 1 program. obvykle mas 1 databazi a 100 programu se vuci ni autentizuje a taha informace
Lama - najednou = 1 okamzik = max 10 lid. 60 okamziku = 60x10 nevyresenych - 60x1 vyresenych
Skynet_IV (fotbalujezd.euweb.cz) - novy sloupec, substring pri editaci, 1000x wiev, 1x editace, 1000x substring nebo 1x ?
>> Tomík se netrefil, navíc daná věc platná na ZŠ i SŠ platí i na VŠ.
Jak netrefil! Na základce a střední se učí vzorce pro idealní stav. Na vysoký pak zjistí, že nic není ideální a vzorce, které jsme se učili, jsou neplatné nebo neúplné.
Jak netrefil! Na základce a střední se učí vzorce pro idealní stav. Na vysoký pak zjistí, že nic není ideální a vzorce, které jsme se učili, jsou neplatné nebo neúplné.
nic jako ideální sql a php (nebo cokoli) není, stejně jak neexistuje ideální db (myšleno návrh), takže
1. co se dá rozumně udělat na db se dělá na db.
2. čím menší provoz na síti, tím líp
3. když s daty program nemusí nic dělat, tak je to ideální
Nabízí se ještě:
když klient nic nechce, tím líp.
Select * je použitelný POUZE jako "potřebuju se honem na něco udělat" nebo jako školní příklad. A nedá se o tom diskutovat ani vteřinu (mnohý příklad známe...).
A v ideálnosti jste, krom ideálních linek, také ideální routery, providery, potažmo vlády a lidi a to už narážíme na naprosto neuskutečnitelnou záležitost (třeba takový ideální programátor...).
1. co se dá rozumně udělat na db se dělá na db.
2. čím menší provoz na síti, tím líp
3. když s daty program nemusí nic dělat, tak je to ideální
Nabízí se ještě:
když klient nic nechce, tím líp.
Select * je použitelný POUZE jako "potřebuju se honem na něco udělat" nebo jako školní příklad. A nedá se o tom diskutovat ani vteřinu (mnohý příklad známe...).
A v ideálnosti jste, krom ideálních linek, také ideální routery, providery, potažmo vlády a lidi a to už narážíme na naprosto neuskutečnitelnou záležitost (třeba takový ideální programátor...).
Ono zalezi na pouziti. Jestlize SELECT * vrati skoro stejne velky radek jako SELECT konkretni sloupce, pak nema zmysl se zdrzovat vypisem konkretnich sloupcu.
Ale ve vetsine dotazu, co jsem videl, se vypisuji 3 sloupce z 10, tam uz to smysl ma.
Pokud chci co nejmene zatizit SQL server a vim, ze 5 stranek zobrazuje informace z jedne tabulky a pouzivaji se casto. Tak urcite bude rychlejsi pouzit SELECT * , protoze SQL server si uklada nekolik poslednich vysledku dotazu. A kdyz pro 5 stranek pouzije 1 SQL dotaz 4x vybrani z kese, jiste jeho prace bude efektivnejsi nez 5x volat jiny dotaz. Samozrejme stoupne zatez na sit, coz je minus. Takze treba v pripade dlouheho radku se sloupcem TEXT bych to jiste nepouzil.
Ale ve vetsine dotazu, co jsem videl, se vypisuji 3 sloupce z 10, tam uz to smysl ma.
Pokud chci co nejmene zatizit SQL server a vim, ze 5 stranek zobrazuje informace z jedne tabulky a pouzivaji se casto. Tak urcite bude rychlejsi pouzit SELECT * , protoze SQL server si uklada nekolik poslednich vysledku dotazu. A kdyz pro 5 stranek pouzije 1 SQL dotaz 4x vybrani z kese, jiste jeho prace bude efektivnejsi nez 5x volat jiny dotaz. Samozrejme stoupne zatez na sit, coz je minus. Takze treba v pripade dlouheho radku se sloupcem TEXT bych to jiste nepouzil.
Nesouhlasím, žádná ušetřená mikrosekunda nenahradí bezesné noci, když ti někdo změní název sloupce nebo ti přidá sloupec typu varchar(max), xml nebo podobnou nabobtnalost.
... nehledě k tomu, že obvyklý dotaz do normalizované databáze obsahuje relaci přes víc tabulek. Hvězdička se pak dá jen těžko prosadit. Pokud potřebuji přejmenovat pole v dotazu (a to potřebuji často), tak hvězdičku také nemohu použít.
Výhodou vyjmenování polí je také fakt, že když někdo změní strukturu tabulky, přestane fungovat patřičný SELECT a ne až chybějící závislá proměnná o pár řádek či stránek níže.
Výhodou vyjmenování polí je také fakt, že když někdo změní strukturu tabulky, přestane fungovat patřičný SELECT a ne až chybějící závislá proměnná o pár řádek či stránek níže.
...nehledě na to, že tu mikrosekundu opravdu, ale opravdu nemáš jak ušetřit. A vůbec: 42....
'Pokud potřebuji přejmenovat pole v dotazu' Kit (ekobrikety.vyrobce.cz)
A tihle lide delaji programy? Ach jo.
MzM (markovo.wz.cz) Do programu nema, co hrabat cizi clovek a uz vubec ne pridavat sloupce. To si pohlida admin, upravy v nove verzi.
Jako v celku souhlasim, ze misto * vypisi vsechny sloupce. To mi nevadi a prijde mi to lepsi. Kdo setri, ma za tri, u programovani to neplati. Tam se uspory musi resit casove a tokem dat.
'nehledě na to, že tu mikrosekundu opravdu, ale opravdu nemáš jak ušetřit'
skutecne programator?
Ve skole do nas hustili assembler. KAZDE If vyrazne zpomalovalo program.
1x IF - mam uz vysledek dotazu v kesi? Ano, vratim.
Ne - proved select s dalsimi tisice ify a prohledavanim indexu a kdesi cosi.
Mikrosekunda? Pri jednoduchem dotazu. Ale obvykle se vytahuji desitky kilo, kdyz vyuzivas pravidlo co nejvic shodnych dotazu. Pri desitkach kilo v mega a gigabajtech dat uz je to vyrazna mikro.
A tihle lide delaji programy? Ach jo.
MzM (markovo.wz.cz) Do programu nema, co hrabat cizi clovek a uz vubec ne pridavat sloupce. To si pohlida admin, upravy v nove verzi.
Jako v celku souhlasim, ze misto * vypisi vsechny sloupce. To mi nevadi a prijde mi to lepsi. Kdo setri, ma za tri, u programovani to neplati. Tam se uspory musi resit casove a tokem dat.
'nehledě na to, že tu mikrosekundu opravdu, ale opravdu nemáš jak ušetřit'
skutecne programator?
Ve skole do nas hustili assembler. KAZDE If vyrazne zpomalovalo program.
1x IF - mam uz vysledek dotazu v kesi? Ano, vratim.
Ne - proved select s dalsimi tisice ify a prohledavanim indexu a kdesi cosi.
Mikrosekunda? Pri jednoduchem dotazu. Ale obvykle se vytahuji desitky kilo, kdyz vyuzivas pravidlo co nejvic shodnych dotazu. Pri desitkach kilo v mega a gigabajtech dat uz je to vyrazna mikro.
peta:
'Pokud potřebuji přejmenovat pole v dotazu' Kit (ekobrikety.vyrobce.cz)
"A tihle lide delaji programy? Ach jo."
A jak chceš napsat select z relace dvou tabulek, ve kterých jsou shodné názvy polí? Pokud chci použít nějakou agregační funkci (vlastně jakoukoli funkci), tak se bez přejmenování pole také neobejdu.
Použil jsi někdy v databázi více než jednu tabulku? Víš o tom, že se v dotazu může vyskytnout funkce?
Určitě je lepší zadat komplexní dotaz do SQL, než se s tím pak piplat v PHP. Na to ty databáze máme.
'Pokud potřebuji přejmenovat pole v dotazu' Kit (ekobrikety.vyrobce.cz)
"A tihle lide delaji programy? Ach jo."
A jak chceš napsat select z relace dvou tabulek, ve kterých jsou shodné názvy polí? Pokud chci použít nějakou agregační funkci (vlastně jakoukoli funkci), tak se bez přejmenování pole také neobejdu.
Použil jsi někdy v databázi více než jednu tabulku? Víš o tom, že se v dotazu může vyskytnout funkce?
Určitě je lepší zadat komplexní dotaz do SQL, než se s tím pak piplat v PHP. Na to ty databáze máme.
SELECT
b.nazev,
b.cislo
FROM
tabulka1 a,
tabulka2 b
WHERE
a.nazev='neco' AND
a.cislo=b.cislo
GROUP BY
b.nazev,
b.cislo
Ano, to jinak napsat nejde.
'Pokud potřebuji přejmenovat pole v dotazu'
Kde jsem prejmenoval pole v dotazu?
Maximalne
SELECT
b.nazev,
a.cislo AS cislo1,
b.cislo AS cislo2
Zas tak casto se to nepouziva, spis se prejmenovanaji pole pro vystup.
SELECT
b.nazev AS zbozi_nazev,
a.cislo AS zbozi_cislo1,
b.cislo AS zbozi_cislo2,
c.nazev AS zbozi_sklad
b.nazev,
b.cislo
FROM
tabulka1 a,
tabulka2 b
WHERE
a.nazev='neco' AND
a.cislo=b.cislo
GROUP BY
b.nazev,
b.cislo
Ano, to jinak napsat nejde.
'Pokud potřebuji přejmenovat pole v dotazu'
Kde jsem prejmenoval pole v dotazu?
Maximalne
SELECT
b.nazev,
a.cislo AS cislo1,
b.cislo AS cislo2
Zas tak casto se to nepouziva, spis se prejmenovanaji pole pro vystup.
SELECT
b.nazev AS zbozi_nazev,
a.cislo AS zbozi_cislo1,
b.cislo AS zbozi_cislo2,
c.nazev AS zbozi_sklad
to smazalo 2 mezery ze zacatku pred a.cislo a pod, chjo, to je forum...
<HTML>peta, ony tam jsou, jukni se do zdrojáku stránky, takže fórum je nemaže. Jo, nepřevede je na , ale to je věc jiná.</HTML>
Někdy se bez přejmenování pole v dotazu neobejdeš:
SELECT sum(Cena) AS CenaCelkem from Uctenka WHERE ...
SELECT SUBSTRING_INDEX(Zdrojak,";",60) AS LimZdrojak WHERE ...
SELECT sum(Cena) AS CenaCelkem from Uctenka WHERE ...
SELECT SUBSTRING_INDEX(Zdrojak,";",60) AS LimZdrojak WHERE ...
Peťo: clekem dlouho jsem nedělal na ničem, co bych dělal úplně sám, takže mi do db skutečně mají ostatní co zasahovat, i když to vždycky dají vědět. Nebo řeknou, přidělej tam sloupeček, co potřebuju, a kdybych tam měl select *, tak makám celý den jak mourovatý a pak se ještě klepu, co mi zákazník omlátí o hlavu, že mu tam nefunguje.
Ve škole vás sice učili, že každé if něco stojí, ale když pak stojí něco, co mělo jet dva dny, protože jsi někde zatáhl chybičku hvězdičkou, tak to za tu mikrosekundu fakt nestojí. Holt praxe je trochu něco jiného jak škola. Dokonce jsme tu měli požadavek na zrychlení aplikace, a vyšlo levněji koupit rychlejší železo než optimalizace kódu. Vypadá to hrozně, ale je to tak. A když to promyslíš do důsledků, tak je to levnější a do doby, než někdo napíše něco lepšího, tak to stačí. Takže je to správně.
Optimalizace: sql a php není assembler. Co může udělat sql svými binárkami, bych nenechával na interpretovaném PHP.
A o dalších věcech by se dalo povídat dlouho a dlouho, a na to není čas musím tvořit neoptimalizované programy s chybama....
Ve škole vás sice učili, že každé if něco stojí, ale když pak stojí něco, co mělo jet dva dny, protože jsi někde zatáhl chybičku hvězdičkou, tak to za tu mikrosekundu fakt nestojí. Holt praxe je trochu něco jiného jak škola. Dokonce jsme tu měli požadavek na zrychlení aplikace, a vyšlo levněji koupit rychlejší železo než optimalizace kódu. Vypadá to hrozně, ale je to tak. A když to promyslíš do důsledků, tak je to levnější a do doby, než někdo napíše něco lepšího, tak to stačí. Takže je to správně.
Optimalizace: sql a php není assembler. Co může udělat sql svými binárkami, bych nenechával na interpretovaném PHP.
A o dalších věcech by se dalo povídat dlouho a dlouho, a na to není čas musím tvořit neoptimalizované programy s chybama....
Nové příspěvky
Python MySQL Connecter na WZ?
ukládání do db
Only full group by mode
Připojení k MySQL z venčí
chyba po přihlášení do DB
Pčipojení do DB
Povoleni views, triggres, functions
Uživatelské účty
nelze vytvořit db
Otazníky místo Š a Ž v textech v databázi
nefunguje mysqli?
Nefunkčný import údajov do databázy
SQL connection timeout
Nepřístupná Databáze
Problém s databázou
ProBlreM
phpBB 2 cast
Záložka event chýba
Zase ta reklama
Dotaz k údajům v databázy
joomla instalace
Počet Zátnamů
Stránkování
Jak vertikalne vycentrovat text v divu?
Nová databáze
Další témata
STATUS
FTP
HTTP
SQL
PHP
© 2002 - 2024 Web zdarma s.r.o. — zvládnete to sami