Více přístupů / zbytečná data? – MySQL – Fórum – Programujte.com

Dobrý den,
mám dilema - v databázi mám pole, které může nabývat vskutku velkolepých rozměrů. (Text) Pouze první záznam potřebuji celý - u zbytku jen 3 krátká pole. (dle toho kolik záznamů dám na stránku 50?, možná volitelně) Také podle jednoho sloupce řadím. Vyplatí se tedy řadit jednou a vytáhnout vše naráz (*) a pak si v PHP vybrat jen potřebné, anebo jen potřebné vytáhnout?
Děkuji.

#1 Matěj Andrle
Co znamená "velkolepých rozměrů"? 20 TB?

Vyplatí se vybírat jen ta pole, která skutečně potřebuji. Nejlépe jedním SQL dotazem.

Psal jsem - Text. Psal jsem - jedná se mi o to, že bych takto 2x řadil - to mi nepřijde jako rychlá operace...

#3 Matěj Andrle
Proč bys řadil 2×, když můžeš jednou?

Text nemůže mít 20 TB?

Právě proto - proč budu tahat 50x zbytečný Text? Prvně vytánu jeden celý záznam a u zbytku potřebuji jen maličkosti. (2x TinyText - ten první má k tomu ještě Text atd.) Jinak podle mých výpočtů je limit pro UTF-8 Text -> 21844 znaků. Tedy neberu to jako rozhodnutí - ptám se - 50x zbytečně, nebo ne?

Chapu to tak, ze mas seznam clanku, ty potrebujes seradit podle nejnovejsiho nahoru a u toho nejnovejsiho potrebujes cely text.
Bud bych pouzil SELECT v SELECTu a UNION a nebo jenom UNION. Zalezi na tom, zda dotazes spravne napsat podminky pro vybrani toho prvniho radku. Ta slozitejsi varianta (misto dotaz1 pak napises cely ten select, mozna to jde i jinak, jednoduseji, ale nejsem moc odbornik):

dotaz1 SELECT COUNT(*) AS n, id FROM clanky WHERE ... ORDER BY ...

SELECT b.id, b.text FROM (dotaz1) a LEFT JOIN clanky b ON a.id=b.id LIMIT 1
UNION
SELECT b.id, NULL AS text FROM (dotaz1) a LEFT JOIN clanky b ON a.id=b.id LIMIT 1
 

google = mysql select cislovani radku

jo, v tom druhem dotazu na poslednim radku nema byt LIMIT a mozna by mel byt limit take v tom dotaz1

Nejde přímo o články, každopádně první ukáži celý a další jen jako nabídku... Tudíž první je ten žádoucí a zbytek jen odkazy s anotací... (titulek, anotace, autor, čas - podle času právě řadím)

#8 Matěj Andrle
Můžeš použít dva dotazy nebo jeden složitější s UNION ALL.

Vím co mohu, já se ptám, co je nejefektivnější... Asi tedy jeden složitý splácanec - že?

efektivitu nechaj na system ktory si si vybral ... napis to tak aby sa to dobre citalo ... RDBC by si mal vybrat efektivnejsi sposob pre danu situaciu

#10 Matěj Andrle
Jeden složitý splácanec SQL je zpravidla nejefektivnější. Jen by neměl příliš zasahovat do dalších vrstev aplikace.

Žádný systém nemám - mám kód o 250 řádcích - zcela mých...

jo, 250 radku, kde jsou ty casy :) 2700 mam ted v rozdelane js hre (po odstraneni komentaru stareho kodu zbylo 1600), pulka z toho jsou komenty vyrazeneho kodu, co pujdou pryc.

Z meho pohledu je efektivni to vytahnout jednim dotazem. Nenavrhoval jsem zadny komplikovany dotaz. Vyberes si seznam idecek a k nim pak dohledas prislusne udaje v prvnim pripade pro prvni zaznam, ve druhem pak pro vsechny. Schematicky by se to dalo asi napsat jako
dotaz2 (dotaz1 LIMIT 1) UNION dotaz3 (dotaz1 LIMIT 2,30)
* prvni zavorka je dotaz1 s ORDER BY a vyber prvni polozky
* druha zavorka je opet dotaz1, ale vyber od druhe polozky, 30 radku
* dotaz1 vybere pouze tabulku se seznamem id, takze to ma hned. Kdyz bude uplne stejny podruhe, tak by se to melo samo kesovat, takze ma vysledek bleskove bez prace
* dotaz2 a dotaz3 pak dohleda k vysledkum prislusna data. Ale protoze union vyzaduje stejnu pocet sloupcu, tak je nutne pridat do selectu v dotazu 3 polozku navic jako NULL as text.

No, a kdybys napsal ty sql dotazy, jak to mas ted a funguje ti to, tak by se to dalo resit :) Takhle je to jen par napadu nad necim neurcitym.

Já jen, že toto jsou vlastně 3 vytažení dat... Jak neurčité - jasně jsem to určil. Mám Text, Tiny Text, Tiny Text, čas, id a ještě pár drobných informačních políček. Chci vytáhnout jeden celý řádek a ze zbytku jen 2 Tiny Texty a autora popř. (autora si rozmýšlím)

Ja mam osvedceny postup - napisu to nejdriv tak, aby to fungovalo, tzn delalo to co ma, vracelo vysledky, ktere potrebuju. Vykon vubec neresim. V dnesni dobe je velka sance, ze to co povazujes za problem je uz davno vyreseno nekym jinym, napr pomuze nejaka cache nebo v pripade databaze zafunguje vestavena optimalizace apod. No a teprve kdyz mi program funguje a zda se mi, ze potrebuje optimalizovat, tak se tim zacnu zabyvat. To nemusi byt jen rychlost, ale treba i mnozstvi obsazene pameti nebo neco dalsiho. Zkousim teda ruzne upravy a finty, ale bacha - nedelam to naslepo, ale vzdycky merim to co optimalizuju. A tady je dulezite, ze uz jsem pred optimalizaci mel funkcni celek, takze mam s cim porovnavat, jestli ta optimalizace pomohla, a jak moc.

Takze na Tvem miste bych zkusil nejprve tu nejjednodussi variantu, tedy tahat vse jednim jednoduchym dotazem. Zmeril bych cas, ktery to zabere. A pak bych to zkusil volat jako dva dotazy, nebo jeden dotaz s unionem, nebo cokoliv dalsiho Te napadne, a zase bych to zmeril. Tim dostanes objektivni vysledky.

Ja uz dlouho profesionalne pracuju s databazema, hlavne MSSQL a ORACLE, a u vsech plati takova obecna vec. Vetsina uloh jde provest nekolika ruznymi zpusoby a zaroven nikdy zadny navod nebo prirucka nerekne, ze nejaky zpusob je vzdycky lepsi nez jiny. Je to proto, ze nikdo nezna ta konkretni data, se kterymi zrovna Ty v danou chvili pracujes. Takze dotaz tady na foru je fajn jako inspirace, jakymi ruznymi zpusoby napsat ten select, ale potom to vyhodnoceni, co je rychlejsi, uz bude na Tobe.

Vtip je v tom, že nemám data. A musím to postavit dříve, než to publikuji...

Male mnozstvi dat sis urcite poridil rucne, abys mohl pri vyvoji testovat. Vetsi mnozstvi dat se da ruznymi fintami vygenerovat programove, bud mnohokrat zkopirovat ta data zadana rucne, nebo napriklad clanky postahovat z internetu, texty vygenerovat lorem ipsum apod.

Bez toho, aby byla databaze naplnena daty, bych se do zadnych optimalizaci nepoustel. Je tam riziko, ze zbytecne slozity dotaz ve vysledku ten vykon jeste zhorsi - na prazdne databazi nebo na malych datech se to nepozna.

Proč se ptám zde - přeci tu někdo musel dělat něco podobného - a jeho poznatek se nezmění - pokud už jednou naměřil...

MS access umi otevrit excel tabulku jako databazi a pak to exportovat, pripadne nad tim pouzivat dotazy. xls a csv se daji stahnout treba ze statistickeho uradu nebo jinych webu, treba gps poloha mes, psc cisla a ulice z posty a pod. Ale jednodussi to bude naplnit programove pomoci lorem isum.

Obvykle jednoduchy dotaz se provede rychleji nez slozity, kdyz ma spravne napsane podminky WHERE nez slozitejsi. UNION by asi nemel byt problem. Nebal bych se pouzit i dva nezavisle dotazy. Na jakpsatweb v diskuzi jsem videl tusim, ze to nekdo testoval, mozna i zname portaly jako root, zive, interval, vrana. Stav byl takovy, ze vysledek byl tak asi stejny. Jen v nekterych db byl rychlejsi slozitejsi dotaz, ale u nich zas dost krachoval casove jednodussi proti jinym db. jakoze treba
db1 dotaz1 10s
db1 dotaz2 32s
db2 dotaz1 15s
db2 dotaz2 13s

Jo, a stranku obvykle dobry programator kesuje do souboru pri editaci. Uzivatel uz si prohlizi staticky soubor, ktery uz ani nejde pres php. Pripadne se to necha jako php, ale kesovani ma zaply server a ten treba uzivateli 15 min bude posilat stale stejnou strenku, ikdyz jsi ji mezitim zmenil.

U AJAXu je cache nepřítel číslo jedna... Nemohu si dovolit statické stránky - vždyť bych uživateli podával staré informace... :) Si koupí 2 000$ a pořád by měl 0$? :)

Mě jde hlavně o to, jak moc je náročné 2x řadit...

Narocnost razeni zavisi na vice faktorech. Napriklad jak moc radku je v tabulce. Jakeho datoveho typu je sloupec - samozrejme je rychlejsi radit podle integeru nez podle stringu, ktery muze mit nejen vetsi delku v bytech, ale jeste se u nej navic bere v potaz treba narodni nastaveni. A jestli je na sloupci, podle ktereho se radi, vytvoreny index a jestli se index pri razeni vyuzije. Proste tech faktoru je hodne.

Kdybych to delal ja, nechal bych si nacist jednim selectem ta serazena data s kratkymi texty a nejakym identifikatorem - primarnim klicem. Pak bych si druhym dotazem sahnul pro dlouhy text, ale uz jen pro jeden konkretni zaznam, jehoz primarni klic znam neb je to v prvnim resultsetu na prvnim radku. Jenze zase nemuzu s jistotou rict, jestli to bude rychlejsi nez reseni, ktera navrhuji ostatni, protoze pokud se mezi jednotlivymi dotazy zavira a otevira spojeni do databaze, tak to muze stat vic casu nez se usetri za zbytecne razeni. Zkratka pokud to chces vedet jiste, budes si to muset zmerit.

Dokud to nezmeris, resis problem, ktery neexistuje.

#24 RomanZ
Mezi jednotlivými dotazy se nezavírá spojení do databáze. Bylo by to značně neefektivní, ztrácely by se dočasné tabulky a další stavové informace.

Však spojení je otevřené... A není tedy jednodušší vzít vše naráz a jen si vycucnout potřebné? (aktuální stav)

#26 Matěj Andrle
Není. Nepotřebuješ přece 50 článků, ale jen jejich náhledy. A také se ve výsledku nepotřebuješ přehrabovat.

Přehrabovat se budu tak jako tak - výsledné pole polí musím převést do HTML... Řešit lze jen tahání z DB... UNION pokud vím, jen lepí tahání - nic nezmění to, že se podle času bude řadit 2x a 2x se tahat z DB...

#28 Matěj Andrle
Pořád v tom nevidím, že budeš 2× řadit. Převedení do HTML ti přece udělá až výstupní šablona.

Mám pole polí - tak ho musím projet i kdybych si sehnal nějakou MVC šablonu. Tudíž se nezbavím přehrabování - to ti musí být jasné - nechápu proč to děláš. Plácneš vždy nějakou blbost, přitom se zdá, že věci rozumíš... Musíš vědět, že tvůj argument byl výstřel do tmy. Protože ať už vytáhnu jen COUNT(*), nebo jen jeden řádek - PDO vždy vydá pole polí... Mohu je číst po řádcích atd. Mohu si vytáhnout jen první řádek. Ale pořád se v tom budu přehrabovat... (to by výstupem muselo být HTML) Princip tvé blbosti - šablona nezařídí, že z MySQL vyleze HTML - tudíž se v tom musí i ona přehrabovat. Nač pak stahovat 7 500 řádkový krám, který jsem předčil 5 řádky kódu? Znovu - UNION jen lepí více dotazů. Tudíž v každém dotazu budu muset řadit...

#30 Matěj Andrle
Mohl bys vědět, že PDO nikdy nevrací pole polí. Dokud si to neuvědomíš, budeš mít s PDO potíže.

Jaký 7500řádkový krám? Šablonovací systém je součástí PHP, je to binárka napsaná v C/C++ a automaticky ti to zkonvertuje i entity dle potřeby.

Dělej si to jak chceš. Pokud o mé rady nestojíš, je to jen tvůj problém.

#30 Matěj Andrle
Pokud to budes mit zakombinovane v jednom selectu, stejny sql dotaz, tam bude v kesi. Takze druhej stejny select pak provede za 0.0001s, nebude nic hledat, radit a pod. Jeste mne napada, jestli by slo tomu prvnimu dotazu priradit pres AS nejake jmeno a v druhem to jmeno pouzit.
SELECT (SELECT FROM (SELECT ... LIMIT 30) AS tmp) UNION SELECT (SELECT FROM tmp)

V dokumentaci dal vidim priklady s (ale asi bude treba prepnout na transakce, coz je dalsi sql dotaz a ty nemas rad moc sql dotazu :) )
* CREATE TEMPORARY TABLE
* CREATE DEFINER=`user`@`%` PROCEDURE
* DECLARE Result cursor for

http://dev.mysql.com/…queries.html
SELECT * FROM t1 WHERE column1 = (SELECT column1 FROM t2);

http://dev.mysql.com/doc/refman/5.0/en/union.html
(SELECT a FROM t1 WHERE a=10 AND B=1) UNION (SELECT a FROM t2 WHERE a=11 AND B=2) ORDER BY a LIMIT 10;

Myslel jsem to takhle s tim tmp... Do tmp si vytahnes 30 clanku, jenom idcka. Dalsi SELECT potrebujes, abys k nim pridal i data z clanky. To same delas v druhe casti, ale nakonec to zlimitujes z 30 na 1.
SELECT ... -- ten tam musis mit, jak koukam na priklady
(SELECT ... FROM (SELECT ... FROM clanky ... ORDER BY LIMIT 30) AS tmp LEFT JOIN clanky ON ...) UNION
(SELECT ... FROM tmp LEFT JOIN clanky ON ... LIMIT 1)

Nechápu, jak mi pomůže to s tím TMP. Pokud tam vytáhnu vše, tak to mohu rovnou nechat, jak to mám nyní - ne? (tahám * v jednom příkazu) Pokud tam stáhnu jen to minimum, první stejně musím vytáhnout celý...

No to tmp by pomohlo v tom, ze uz je to v tmp serazeny. Nasledny dotazy nad tmp uz teda nemusi radit, vyberou pouze pozadovany pocet zaznamu. Je to dalsi inspirace , jak se vyhnout opakovanemu razeni.

Tož, ale tím pádem je v tom TMP vše - ne? A to už mohu mít vše u sebe - jedním dotazem...

Podle mne to opravdu resis zbytecne. Pocty clanku nepujdou do desitek tisic, predpokladam ze nejsi idnes. Delka clanku muze byt typicky 3 az 5 kB, do gigabajtu to urcite nepujde, to bys mel v jednom clanku celou MSDN. Takze pri takovem objemu dat by to nemuselo nijak zlobit. Jednoduse to cele nacti jednim dotazem, jak to mas od zacatku v planu. Kdyby to prestalo vyhovovat, predelat se to da vzdycky.

Mimochodem, doporucuju k precteni knihu Programator pragmatik, Hunt, Thomas, v CR vydal Computer press, myslim asi pred sesti nebo sedmi lety. Cas programatora je drahy, neni mozne ho palit na problemu, ktery mozna ani neexistuje.

#37 RomanZ
To už raději ty dva dotazy. Stejně je viewer potřebuje na různých místech stránky a bude je v modelu hledat každý zvlášť.

Jak jsem psal - nejsou to články. Jedná se o inzeráty/reklamy - počítám tak průměrně 300-500 znaků... Především jich bude vskutku moc. Buď se projekt nerozjede a celé to nemá smysl řešit, ale pokud se rozjede, budou jich miliardy... (proto řeším funkčnost před spuštěním)

#39 Matěj Andrle
Myslíš si, že miliardy záznamů to nějak zpomalí? Jenom když zapomeneš na indexy.