Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Modrá je dobrá
zelená je lepší

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Archiv klubu Database (mysql,...) [ŽP: neomezená] (kategorie Programování) moderuje melkor_unlimited.
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
   
[ 414 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 3.4.2006 14:30  351
kterak dostat z databáze timestamp v takový tý klasický formě jen čísel kterážto pak jde používat v dotazech?
používám ho v logu jak key a rád bych podle toho dokázal mazat...
knedle knedle online - Krabice živých 2.4.2006 21:04  350
postgresqldo delam spatne? su blbej nebo nevim

mam nainstalovanej na localhostu wamp s tim, ze sem povolil extension php_pgsql - v a phpinfo to mam potvrzene

nainstaloval sem postgresql-8.1-int.msi (port 5432)

pri instalaci sem tam narval na dvou mistech hesla co si pamatuju (H1, H2)

pgsql se mi spousti pri startu win...

kdyz se do pgsql chci podivat skrz PgAdmin 3 - chce to po me jenom heslo (H2) - a pusti me to - muzu pracovat...

u phpPGadmin to po me chce jak login tak heslo: zadavam adekvatni k funkcnimu heslu (H2) z pgadmin3 - bohuzel nic - a ac zkousim vsechny mozne a nemozne kombinace, tak se proste nedokazu pripojit :(

kde by mohla byt chyba?
king King Born to be king - ... 29.3.2006 02:28  349
ad oracle: IBM uvolnil DB2 s tim, ze omezeni jsou mnohem slabsi (4GB ram, neomezeny prostor na disku a 2 CPU)... jinak souhlas ;)
al3x 29.3.2006 00:23  348
makovecAle víš co, koukni na třeba Lopuch. přes milion (1070256) přípěvků v skoro 900 tabulkách, indexovaný přes varchary, plus nějaká pošta a systémový data navíc. Struktura db optimální neni vůbec, kolik je to dat ve srovnání s tvýma odhadnout nedokážu.
Nyx je několikrát větší, běží na třech strojích v ceně kolem 20 tis za kus (aspoň myslim, že to tak bylo).

Moc o struktuře toho tvůho portálu nevim, ale tak nějak mi přijde, že MySQL na železe za 80k je malinko disproporce. :)

Pokud je ten projekt tak velký, jak tvrdíš, tak bych zaplatil aspoň někoho, kdo vám udělá návrh (třeba jen na papíře). Pokud víš o db opravdu kulový, tak se může dost dobře stát, že to neuděláš idealně - což se ve staropramen webu ztatí, ale portál to bude brzdit a není nic horšího, než předělávat běžící datovou strukturu. Ten člověk by měl aspoň tušit, jestli při bežném použití bude lepší použít stored procedures (mysql umí dost špatně), čtení stromové struktury (mysql neumí), etc...

Asi bych po vytvoření té základní struktury nageneroval representativní množství dat, optimalisoval v několika vybraných SŘDB (třeba mysql, firebird a postgresql) a udělal pár benchmarků na nejběžnější dotazy. Je to sice dost sraní na začátku, ale pokud do toho chcete dát přes 80k, tak se to myslim vyplatí.


Řešením by mohl být ještě Oracle XE, který je zdarma, ale jen na jeden CPU, 4GB dat a 1GB ram...
makovec makovec Chuck Norris snědl jídlo od Babicy - a ještě si přidal 28.3.2006 22:35  347
no prave .. proto spis se ptam na vlastni zkusenosti.. jeste upresnim. zelezo bude zarucene slusny (s cenou pod 80k by se neslo), linka pravdepodobne primo na pateri.. a vytizeni.. to je velka neznama. v idealnim pripade by to mel bejt jeden z nej portalu svyho druhu v cechach. jenze o jinych databazich vim kulovy a platit si cloveka v teamu na neco co v mySQL zvladnu sam (editace, pridavani, uploady souboru, full text, guard system, sber dat, viceurovnova registrace) se mi zda zbytecny (alespon zatim, kdyz je projekt v plenkach s nejistym vysledkem).. zatim min rozsahly projekty (pred par lety portal sparopramenu, euroteli portal k MS v hokeji, dneska treba web akvizicni dcerinky rakousky erstebank) behaly krasne a rychle na mySQL. jenze tam byly zaznamy prave v radech tisicu. a velikost v radech desitek mega.. tohle v optimalnim pripade bude o neco masivnejsi.
al3x 28.3.2006 17:48  346
makovecProblém toho dotazu je, že na něj neexistuje ani moc inteligentní odpověď. Skoro by to stálo za vlastní benchmark v podmínkách, kde to chceš používat. Ale v zásadě s velikostí několika více desítek mega bys problém mít nemusel, kolem půl giga už třeba jo.
Obě hranice i všechno mezi závisí na struktuře, železe, vytížení, definici slova "svižný", dotazech a spol, ale to ti je asi jasný.
mach 28.3.2006 14:13  345
Neco se muzes docist v reakcich na tenhle prispevek (uplne dole na strance): http://www.lopuch.cz/klub.php?klub=database__mysql____a&from=120
makovec makovec Chuck Norris snědl jídlo od Babicy - a ještě si přidal 28.3.2006 14:10  344
lidicky, teoretickej dotaz (nekamenujte me, neumim podavat dotazy inteligentnejc .o).. kdyz si vezmem mySQL databazi, dobre strukturovanou.. do jaky velikosti tak priblizne dokaze bez problemu pracovat tak aby treba fulltext vyhledavani bylo celkem svizny
straka82 24.3.2006 11:36  343
makakoch, dekuji ti :-)
makak 24.3.2006 00:53  342
Straka82> Pouzit "union all".
straka82 23.3.2006 19:40  341
Ahoj :-)Mam dotaz

(select * from tab1 where id like '$id')union(select * from tab2 where id like '$id')

ktery mi dohromady slije dve tabulky. Kdyz mam ale v nejake z nich dva uplne stejny radky, tak se mi do vysledku da ten radek jen jednou. Jak se to vyresi, aby ve vysledky ty dva stejny radky zustaly?? Diky
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 16.3.2006 15:02  340
Bredy: Tomas Marny...
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 16.3.2006 14:57  339
Bredydikes, to slovo uz jsem slysel... inac, zelezo a databazi prave pak nebude tak jednoduchy vemenit, uz proto ze aplikace musi bezet porad a nejsou prebytecny penize na prelejzani z zeleza na zelezo "c(
bredy 16.3.2006 14:48  338
Oprava nikoliv jeden index na celý dotaz, ale jeden index na jednu tabulku v dotazu, pokud je dotaz složený z vícero tabulek.

Konečně zkus si před každý dotaz napsat klíčové slovo EXPLAIN. Je to dost dobrá věc, ukáže to uživateli jak vlastně se takový dotaz vyhodnocuje.
bredy 16.3.2006 14:47  337
tvxV zásadě se databázové systémy liší ve strategii cacheování mezivýsledků a stavění nějakých pomocných struktůr a v optimalizaci vyhledávacího dotazu.

Právě že u spojovaných tabulek se dá spoustu věci optimalizovat různě. MySQL tuším podporuje pouze jeden index na dotaz, to znamená, že pokud je potřeba hledat ve více kritériich, pak se vyhledá podle pole generující nejméně výsledků a na výsledky se aplikuje zbytek podmínky. Pokud se spojují tabulky, pak se začíná tabulkou, jejiž indeex generuje nejméně výsledků, pokud dotaz nepředepisuje pořadí (LEFT JOIN atd).

Hledání v rozsazích často představují jedno hledání a pak sekvenčí průchod do dosažení druhé hodnoty z rosahu. Je-li zadáno vícero rozsahů, pak se to tolikrát opakuje. Pokud se hledá pomocí IN, pak se hledání opakuje tolikrát, kolikrát je zadaných hodnot vpravo.

Samozřejmě doindexovávání záznamů je problém. V tomto směru bych viděl největší odlišnosti implementaci...

Chce to prostě zkusit. Zkus to, železo a databázi může podle mne kdykoliv vyměnit...

Kdokoliv: Vysoké N0 bych očekával spíš u Oracle, kde do hry bude vstupovat strategie cachování. U MySQL bych očekával N0 menší. Víc k tomu nemám co říct, tady se prostě neshodneme. I kdyby N0 bylo hodně vysoké, spíš to dává za pravdu mne, protože jakmile N bude vyšší než N0 nastoupí Log N a to v případě, že pod N0 je složitost horší naopak MySQL pomohlo. Zase nemůže být tak špatné, protože pro malé N je MySQL docela svižné.

Připomínáš mi jedince postiženého nemocí vyjádřenou filozofickou větou "Vím vše tudíž nevím nic" (Jára Cimrman - filozofie externismu)

[ 414 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt