Jak postavit obrovský update? – PHP – Fórum – Programujte.com

Dobrý den,
mám opravdu monstrózní update a potřeboval bych řádně nastavit timeouty - padá mi to na 500...

set_time_limit(999999);

$subpublisher = "";
$xml = new XMLReader();
$database = new PDO("mysql:host=localhost;dbname=ads", "root", "fdfasdfasdsdfs");
$database->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$ch = curl_init("https://tango.admeta.com/api/CRMHTTPService/CRMHTTPService.svc/subpublishers?name=&zipcode=&street=&city=");
curl_setopt($ch, CURLOPT_MUTE, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_USERPWD, "dsfdfsdf");
$xml->xml(curl_exec($ch)) or die("Error: Cannot read subpublishers");
curl_close($ch);
while ($xml->read())
{
	if ($xml->name == "name")
	{
		$xml->read();
		if ($xml->depth == 3)
			$subpublisher = $xml->value;
		else
		{
			$statement = $database->prepare("UPDATE `source` SET `subpublisher` = :subpublisher WHERE `website` = :website");
			$statement->bindParam(":subpublisher", $subpublisher);
			$statement->bindParam(":website", $xml->value);
			$statement->execute();
		}
		$xml->read();
	}
}

Děkuji.

#1 Matěj Andrle
Jednou z možností, jak aktualizovat všechno naráz, je poskládat si SQL dotaz s CASE klíčovým slovem.

CASE <nějakýSloupec> [WHEN <hodnotaNějakéhoSloupce> THEN <hodnotaKterouChcešPřiřadit> ...] END

Výsledný SQL pak může vypadat nějak následovně:

UPDATE `source`
    SET `subpublisher` = CASE `website`
        WHEN "název první stránky" THEN "první sub_publisher"
        WHEN "název druhé stránky" THEN "druhý sub_publisher"
        WHEN "název třetí stránky" THEN "třetí sub_publisher"
    END
WHERE `website` IN ("název první stránky, "název druhé stránky", "název třetí stránky")

#2 ondrej39
A o co mu tedy jde? (Vždyť to nedělám naráz - tak proč to padá na 500?) Respektive to mám vytvářet pokaždé instanci, anebo nedá se jen pohrát si se sezením?

#3 Matěj Andrle
A jsi si jistý, že ti to padá na kroku s databází? Nepadá ti to třeba na volání té služby?

#4 ondrej39
Pokaždé se upraví stejný počet záznamů a pak to padne.

Při načítání adresy http://52.48.50.57/test.php narazily stránky na chybu. Na této adrese možná právě probíhá údržba stránek, nebo jsou stránky chybně nakonfigurovány.

Co by se mu tedy mohlo dít?

#6 ondrej39
Toto jsem nečekal - pardon za desinformaci:

Caught exception: SQLSTATE[HY000]: General error: 1267 Illegal mix of collations (ascii_bin,IMPLICIT) and (latin1_swedish_ci,COERCIBLE) for operation '=' Caught exception: SQLSTATE[HY000]: General error: 1267 Illegal mix of collations (ascii_bin,IMPLICIT) and (latin1_swedish_ci,COERCIBLE) for operation '='

#7 Matěj Andrle
Buď máš tabulky ve špatném kódování, nebo v tom XML jsou data ve špatném kódování. Každopádně se to dá natvrdo vyřešit použitím příkazu COLLATE.

#8 ondrej39
Švédštinu v tom nezřím: " Poradte.cz-Pocitace_a_prislusenství-C" Já nečekal, že tam bude diakritika (o možnostech kódování jsem uvažoval, timeout mi přišel logičtější) - stačí tedy jednoduchý převod... Děkuji.

#9 Matěj Andrle
Švédštinu budeš mít spíš u sebe, řekl bych. Z nějakého důvodu to bývá implicitní nastavení kódování znaků v MySQL.

#7 Matěj Andrle
V našich končinách bývá nezbytné nastavit UTF-8 pro veškerou komunikaci s databází. Máš do toho zamíchanou i Latin-1, která se nás vůbec netýká. 

<?php
$database = new PDO("mysql:host=localhost;dbname=ads;charset=UTF8", "root",...

#10 ondrej39
Nebere PDO náhodou encoding databáze - tam je UTF-Bin... Neznám možnost, jak v PDO nastavit encoding.

#10 ondrej39
Aha - kódování tabulky! Tak tím je to vyřešené - stačí jen toto a hotovo.

#10 ondrej39
Ano, švédština je defaultní pro MySQL. Správce databáze sice může nastavit UTF-8, ale skoro nikdo to nedělá a proto se na to vůbec nedá spolehnout. Je nutné zkontrolovat/předělat všechny tabulky, zda náhodou nejsou v Latin1.

#14 Kit

#10 ondrej39
Změněno a stejně:

Caught exception: SQLSTATE[HY000]: General error: 1267 Illegal mix of collations (ascii_bin,IMPLICIT) and (latin1_swedish_ci,COERCIBLE) for operation '=' in "Blesk pro muže - C"

Caught exception: SQLSTATE[HY000]: General error: 1267 Illegal mix of collations (ascii_bin,IMPLICIT) and (latin1_swedish_ci,COERCIBLE) for operation '=' in "Poradte.cz-Pocitace_a_prislusenství-C"

Collate tabulky je přitom na UTF!

#15 Matěj Andrle
Nejspíš budeš muset znovu založit tabulky se správným kódováním a znovu do nich nasypat data.

Viz Kit #7
Kdyz delas importy a exporty, tak se nemuzes spolehnout na kodovani a je lepsi to tam vzdy napsat, treba pres SET NAMES. Mysql 4+- a mensi nezna SET NAMES. Default kodovani ma latin1swedish. V tomhle kodovani ti vyplivne vystup. A s timto kodovanim ti to take importuje.
Pri importu, kdyz nastavis SET NAME na latinswedish a tabulky budou mit kodovani latinswedish, a sloupce tabulek taky, tak se to naimportuje spravne.
Ted to mozna reknu nepresne...  Kdyz budes chtit jine kodovani, tak musis nastavit v tabulce a sloupcich jine kodovani, ale SET NAMES pouzit pro latinswedish. Pak by se ti to melo prekonvertovat z latin na kodovani v tabulce. V aplikaci pak pouzijes SET NAMES pro to druhe kodovani, treba UTF-8.

A dlouhy import, prenos souboru od uzivatele na server, resim komprimaci pres zip.

Jestli mas firefox, a podari se ti ten soubor zobrazit ve firefoxu, tak si tam zkus pomenit kodovani a zjisti si, v jakem kodovani ten soubor je, cili, kdy zobrazuje spravne diakritiku (zobrazeni - znakova sada).
A pak je jeste dost casta chyba, prace s utf textem pomoci php funkci bez mb_. Treba strlen("vsechnyutfznaky") a mb_strlen("vsechnyutfznaky") ti da odlisne cislo, protoze utf obsahuje znaky, ktere se zapisuji jako dvojznak.

#15 Matěj Andrle
Napiš DB dotaz: 

SHOW CREATE TABLE `source`;

a pošli sem výsledek.

#19 Kit 

CREATE TABLE `source` (
 `index` int(11) NOT NULL AUTO_INCREMENT,
 `system` varchar(50) CHARACTER SET ascii COLLATE ascii_bin NOT NULL,
 `subpublisher` varchar(50) CHARACTER SET ascii COLLATE ascii_bin DEFAULT NULL,
 `website` varchar(60) CHARACTER SET ascii COLLATE ascii_bin NOT NULL,
 `webpage` varchar(50) CHARACTER SET ascii COLLATE ascii_bin DEFAULT NULL,
 `placement` varchar(60) CHARACTER SET ascii COLLATE ascii_bin DEFAULT NULL,
 `dsp` varchar(50) CHARACTER SET ascii COLLATE ascii_bin DEFAULT NULL,
 `totalImpression` int(11) DEFAULT NULL,
 `soldImpression` int(11) NOT NULL,
 `totalRevenue` int(11) NOT NULL,
 `date` date NOT NULL,
 PRIMARY KEY (`index`)
) ENGINE=InnoDB AUTO_INCREMENT=55783 DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='Reporting statistiky'

#10 ondrej39
#19 Kit
Co to je za hovadinu?

Připojen obrázek.

#20 Matěj Andrle
Proč máš sloupečky definovány ascii? Dáváš do nich pouze znaky bez diakritiky?

ascii_bin a utf8_bin v collate tam máš kvůli čemu? Vždyť to  má jen samé nevýhody.

#22 Kit
ASCII, poněvadž nevyužívám diakritiku - tak porovnávat jeden byte a více se mi jeví jako rozdíl. UTF-8 je právě kvůli vstupu! :S (Uvažuji nad změnou.)

#23 Matěj Andrle
Znak v UTF-8 bez diakritiky zabere 1 bajt stejně jako v ASCII. Přestaň šetřit tam, kde se šetřit nemá.

#24 Kit
Ovšem zjištění, že tomu tak je, to zabere více. Porovnávat přímo určený jeden byte je rozhodně snazší, než odhadovat, zda náhodou další znak nemá 2 byty... Jak píši - mohu to kdykoli změnit. Zde mne překvapily 2 věci - diakritika na konci záznamu (přitom 99.9 % záznamů nemá diakritiku a má to skýtat 100 %.) a defaultní encoding PHPMyAdmin.

#25 Matěj Andrle
Jenže když do takového sloupce v ASCII náhodou strčíš něco v UTF-8 (cokoliv s nastaveným 8. bitem), tak ti to zhavaruje. Stojí ti to za to?

ASCII napad je to zajimavy, nicmene neprakticky. Pokud to jde, tak dnes pouzijen UTF na vse. V opacnem pripade si klidne pouzij, co chces, ale pak se nediv, kdyz ti tam neco nepujde a nebo budes mit nekolik php kodu, abys kazdy rozdil mohl zpracovat. Cili, treba ted mas jiste kod, ktery odstranuje diakritiku. A ted je otazka, zda to potrebujes nebo to delas jen proto, aby jsi usetril?
Rychlost se u Mysql resi spravnym nastavenim indexu v tabulce a spravnym napsanim dotazu. 1.000.000 zaznamu nedela mysql, na dnesnim beznem pc, zadny velky problem.
Priklad spatneho dotazu s grupovanim muzu uvest tady od studentu. Bylo treba vyhledat vsechny publikace, ktere maji alespon jednoho autora ze seznamu 20. Nebo v druhem pripade vsechny autory ze seznamu. Studenti meli dotaz tak, ze kvadraticky narustal cas reseni pri zvysovani autoru a to tak neunosne, ze se dali vyhledavat jen 3 jmena. Predelal jsem to na spojovani vysledku pres UNION a ted vyhledani 20 jmen je rychlejsi nez 2 jmena puvodniho dotazu. (6 jmen to hledalo treba 20 minut pri asi 1000 zaznamech)

#27 peter
Diakritiku neodstraňuji - vůbec tam být neměla. Tak proto. (Někdo se uklepl a na konec jednoho slova ji přidal - za to nemohu.)

#28 Matěj Andrle
Chceš tím snad naznačit, že nemůžeš za pád své aplikace, pokud někdo vloží chybná vstupní data?

S takovým přístupem bych neměl nikde šanci. Máš příliš tolerantní zákazníky.

#27 peter
Snad nám nechceš tvrdit, že standardní JOIN byl tak pomalý.

Kit - Na tvou otazku nelze odpovedet. Spatne definovane pojmy. Ten dotaz proste vytvarel kaskadu vysledku. Cim vic autoru, tim mnohonasobne vic raku, ktere pak vsechny filtroval. No, nemusim rikat, jak tim zahlcoval server. Ze tam treba visel dotaz 3 dny :) Ikdyz ten clovek uz davno vypnul pc, co jej poslal.

#31 peter
Promiň, ale 50k záznamů nemůže být žádný problém, pokud ten SQL dotaz totálně nezvořeš.

Ja to vim. Na mne nekoukej. Proc jsem jim to asi prepsal, ze? :)