query vapors...

Zdraveite,
Razpolagam s tablica v, koyato ima da rechem 1 000 000 zapisa. Pretarsvam tablicata kato pri nalichie na nad 1000 rezultata, vrastam potrebitelya da stesni kriteriite si za tarsene. Tova nesto realiziram s dve zayvki= "SELECT count(*) FROM table_name WHERE edi_kakvo_si" i ako zapisite sa nad 1000 izvejdam saobstenie za stesnyavane kriteriite za tarsene, inache pravya oste edna zayavka za izvejdane na rezultata. Tova nesto moje li da se realizira po drug nachin.Kasae se za MySql.

пишеш заявката така
SELECT alabala FROM table WHERE edikvosi LIMIT 1001

после с mysql_num_rows проверяваш дали редовете са повече от хиляда и решаваш как да продължиш...

не мисля, че 1001 реда ще озорят сървъра повече отколкото 1000 (където е границата на условието) а ако са по-малко спестяваш едното обръщение към My Sql-а.

[линк]

Za mojeneto, moje.V momenta se ucha i mi e po-lesno da popitam vmesto da otkrivam toplata voda. Kakvo mislite za slednata situacia.
Testvam slednia primer-Skript za malki obyavi. Kato kam vsyaka malka obyava mogat da se dobavyat proizvolen broi snimki. Pri pretarsvane na bazata danni, iskam da izvleka obyavata i svarzanite s neq snimki, vklyochitelno i obyavite za koito nyama snimki.
imam slednite tablici:
mo(id,info)
image(id,imagename)
Za da izveda rezulatata pravya slednata zayavka: " select id,info,image.imagename from mo left join image on mo.id=image.id. Izpalnenieto na tazi zayavka otnema strashno mnogo vreme. Za nad 100 000 zapisa ne mi se misli, kakvo ste e.Sasto taka, ako ima poveche ot edna snimka za malka obyava mi vrasta dublirasti se redove s razlichni snimki.

Ili pak da probvam slednia variant:
"SELECT id,info FROM mo LIMIT 0,10" i sled tova s PHP pri izvejdane na rezultata da proveryavam dali v tablica image ima snimki.
A inache pozdravlenia za novatorskia duh na Torbalan i otzivchivosta

да, така е
получава се нещо подобно:
обява 1 снимка 1
обява 1 снимка 2
обява 2 снимка 1
обява 3 няма снимка...))

ами нормално си връща всичко

ако имаш намерение да печаташ 100 000 обяви - не ми се мисли и на мен за горкия юзер...
а ако са в нормално количество - нищо не трябва да те притеснява
печатай наред...

моето мнение е че е по добре с една заявка да си извадиш всичко кактово ти трябва отколкото за всяка нова обява да вадиш снимките с нова заявка, макар че не мога да измисля нищо в подкрепа на първия вариант...

би било интересно да чуем мнението и на salle за това кой от двата варианта е за предпочитане...

[линк]

S left join-a mi zabiva mysql-a. Inache sas vtora zayavka, s koyato izvlicham snimkite raboti sravnitelno dobre.Tuk ne moga da se izkaja, ako server-a e natovaren, kakva proizvoditelnost ste postigna. Kakvo li ste stane ako zapazya rezultata vav vremenna tablica i sled tova osastestvya svarzvaneto s image?

не мисля, че има особен смисъл от временни таблици
ако ти забива mysql-а търси защо
във никой случай не е от left join
освен това виж таймаутовете, би трябвало да можеш да ги настроиш, така че ако до определено време не изпълни заявката - да я зареже и да върне грешка...

[линк]

sas 100 % left join s takav result set zabiva server-a
ne to4no zabiva a zaiavkata otnema tolkova vreme 4e e ravnozna4no
imai predvid 4e left join pravi slednoto :
na vseki red ot parvata tablica otgovariat vsi4ki redove ot vtorata ...
t.e. pri join-a polu4ava6 preimerno 1000(ot table1)*1000(ot table2) = 1 000 000 reda. (salle ako ne sam prav popravi me pls.) i varhu tezi 1 000 000 reda nalaga uslovieto za JOIN i usloviata ot where clausata.
te postigne6 adski goliamo zabarzvane s razdelianeto na zaiavkata na 2 prosti selecta. osven tova estestveno kogato ima6 v ednata tablica 1 red kam koito se joinvat niakolko reda vav vtorata tablica 6te polu4i6 palnia resultat. T.e. za vsiaka obiava koiato ima pove4e ot 1 snimka 6te polu4i6 tolkova redove v resulta kolkoto sa broja na snimkite.

za tova ti prepora4vam da razdeli6 zaiavkite na 2

P.S. moze da izpolzva6 i select ... from pictures where obiava_id in (select id from obiava_table where obiava_uslovie). za tova zavisi koia versia na MySQL ima6

E tuk ni6to niama :[линк]

... а то така само отговорите на Торбалан чета

salle.online.bg/sig

ами смисъла на въпроса беше горедолу следния

ако имаш две таблици с лефт джойн може да получиш подобен резултат

алабала едно
алабала две
алабала три
бабаяга едно
бабаяга ягоди
баба яга нул
дядомраз грозде
дядомраз череши

и да направиш на РНР скрипт който да печати
алабара КАРТИНКИ едно, две ....
бабаяга КАРТИНКИ ......
дядомраз КАРТИНКИ......

а може да направиш един прост селект, който да извади
алабала
бабаяга
дядомраз
и след това скрипта за всеки един резултат да прави нова заявка и да вади картинките

та кое е по добре, ако се има предвид, че става дума за уеб интерфейс....

[линк]

Ako uslojnim shemata, po-slednia nachin.
mo(mid,info,userid)
image(mid,imagename)
users(userid,username)
Koe li ste e po-barzo?
SELECT * FROM mo
select * from image where mid='$mid'
SELECT * FROM users where userid='$userid'

Ili pak
SELECT * FROM mo,users where mo.userid=users.userid
select * from image where mid='$mid'

обаче упорито си продължаваш на чуждоземски

--
The#Project - лайфстайл списание в мрежата

И после какво - ще изкара 1000 резултата на една страница ли?

направи го с по-малко заявки. помисли какво ще стане при 10 потребителя от по 20 заявки на страница и го сравни с 10 потребителя по една.

За забиването на left join - индексирай си както трябва таблиците и няма да имаш проблеми. Експериментирал съм с таблици от по няколко милиона записа, след като сложих индекси където трябва времето за изпълнение на заявката стана от няколко минути на няколко сек.

За да си оптимизираш заявките, използвай explain select, а за индексите погледни документацията на mysql

Колкото до по-горе дискутирания въпрос дали с left join или по заявка на резултат - определно с left join

pri join-a polu4ava6 preimerno 1000(ot table1)*1000(ot table2) = 1 000 000 reda. (salle ako ne sam prav popravi me pls.) i varhu tezi 1 000 000 reda nalaga uslovieto za JOIN i usloviata ot where clausata

Не е така. ако полетата, които засяга where клаузата са индексирани, се взимат само записите които отговярят на нея. Пусни си explain select вместо да питаш salle
А това че 100% заявката щяла да отнеме толкова време че било равнозначно да забие сървъра, е несериозно

iavno ne 4ete6 mnogo mnogo diskusiata
malko po-nagore bo obiasniava 4e tova e sistema za obiavi i moga da tvardia sas 99% sigurnost 4e obiavata mu e vav varchar (pone 120) pole i tarseneto stava s LIKE %% . pomisli si kakav 6te stane indexa ako indexi-ra6 po tova 120 simvolno pole i kakvo ti pomaga toi za LIKE.

E tuk ni6to niama :[линк]

не знам за теб, но аз на varchar обикновено правя fulltext index и търся с match against.
А това което написах беше по-скоро принципно, отколкото за неговия случай. В много редки случаи не е възможно да се избегне full scan на таблиците, така че твоя пример за 1000*1000 е по-скоро изключение отколкото правило.
А ако се върнем на неговия случай, едва ли търсенето ще става само по varchar поле - може да има и други критерии (най елементарния е дата), които ще намалят броя на обработените записи.
Освен това трябва да се отчете факта, че повечето заявки на една страница, ще забавят повече нещата, особено при повечко едновременни заявки

mo(mid,info,userid)
image(mid,imagename)
users(userid,username)
Slojil sam index v tablica mo(mid i userid), v tablica image(mid), v tablica users(userid).
Nyakakva ideq na drugo myasto index da se sloji?
Ne se zanimavam v sluchai da tarsya vav varchar ili text pole.Prosto left join na dvete tablici raboti strashno bavno. Sled kato razdelih zayavkata na dve prosti raboti normalno.

По колко записа имаш в таблиците и какво ти показва explain select? Можеш ли да постнеш заявката? A OS-a и машината ОК ли са?

моя отговор важи и за 100 и за 10 резултата..ще работи по един и същ начин

а при нас в офиса имам едни страници с по сто резултата...колегите най много тях ги харесват...така че 10х100 не ми звучи зле?

[линк]

e, на мен идеята ми беше, че за показване на определен брой резултати на страница се ползва лимит - така че пак се при всички случаи се прави една заявка за броене на резултатите и една за самите резултати.
Предполагам, че ти използваш по-различен подход за ограничаване на резултатите...