Existuje limit pro funkci CONCAT? – MySQL – Fórum – Programujte.com

Zdravím,

mám následující funkci v PHP:

Připojen obrázek.

která generuje JSON z DB pomocí volání concat.

Vše fungovalo roky perfektně, než jeden uživatel vložil do jednoho záznamu v DB data o velikosti více jak asi 24kB. V tu chvíli přestala funkce správně pracovat, přesněji řečeno generoval se špatný JSON formát.

Marně jsem hledal na googlu nějakou informaci a marně jsem o několik řádů nastavoval všemožné limity v konfiguraci MySQL. Nakonec jsem musel celý problém řešit přímo v PHP, což mě nepřijde tak elegantní a i uživatel pozná, že to trvá déle...

Proto se ptám, existuje nějaký limit pro funkci CONCAT?

Díky, R.

PS: dokumentace zde:

http://dev.mysql.com/doc/refman/5.0/en/string-functions.html#function_concat

#1 Radek
Poradil bych ti, ale nejde mi ten obrázek spustit a nemohu přečíst, co je tam napsáno.

http://dev.mysql.com/doc/refman/5.0/en/char.html

podle toho je limit 65535 .. mozna kdyby to bylo jako nejakej typ unicode, tak by to vyzralo driv.. ale teoreticky by se to tam vejit melo

+ i kdybys to delal v php, tak to zase tak o moc pomalejsi nebude... nic co bys poznal (hlavne to ani nemusis spojovat, staci to vypisovat spravne)

jo jeste je tu dalsi podstranka: http://dev.mysql.com/doc/refman/5.0/en/column-count-limit.html

jelikoz je UTF8 az 3 znaky dlouhe, tak musi alokovat trojnasobek .. tj. coz neco kolem tech necelejch 22kB plus minus odpovida

#2 Kit
Sem liny clovek a kod upravuji pres SSH primo na serveru, proto ten zdrojak v obrazku, abych to nemusel stahovat... Navic to pak neni rozsypane jak caj, kdyz se to nekam kopiruje...

#3 KIIV
Tabulka je InnoDB a data jsou ulozena jako TEXT, ne jako CHAR nebo VARCHAR...

Text je ve formatu UTF-8, takze pak muze zabirat jeden znak vice bajtu, to ano...

NEMAM PROBLEM S DATY V TABULCE, TY JSOU ULOZENA SPRAVNE, PROBLEM JE PRI EXPORTU DO JSONu...

Co me ale hlava nebere, tak je toto:

CONCAT(

  GROUP_CONCAT(

    CONCAT( ... )

    CONCAT( ... )

    CONCAT( ... )

    ...

  )

)

Jako ze ten vnejsi CONCAT pojme bez problemu 250kB dat (vsechny data z tabulky), ale jakmile je v jednom vnorenem COCNCAT uvnitr GROUP_CONCAT vic jak 24kB, tak se to usekne... Doufam, ze je muj problem (dotaz) spravne polozeny (pochopitelny)...

#5 Radek
Právě že takto na mne ten zdroják působí chaoticky. Kdyby to byl text, tak si ho zkopíruji do editoru, přeformátuji, zvětším písmo, barevně zvýrazním podle syntaxe a můžu ho číst.

JSON má určitá specifika a pokud je v uloženém textu nějaký znak, který je pro JSON jako řídicí, tak se ti to celé rozsype. Stačí do textu vložit uvozovky a jsi v loji.

V PHP je na to hezká funkce json_encode(), která se o všechno postará. Proč ji nepoužíváš?

Sem liny clovek a kod upravuji pres SSH primo na serveru, proto ten zdrojak v obrazku, abych to nemusel stahovat... Navic to pak neni rozsypane jak caj, kdyz se to nekam kopiruje...

Běžně edituji kód přes SSH přímo na serveru. Na přetahování kusů kódu používám myš. Levým myšítkem označím na serveru, prostředním myšítkem vložím do formuláře fóra. Jednodušší to snad ani být nemůže. Jsou to jen dvě kliknutí. Pokud máš Windows, tak ještě navíc Ctrl-C a Ctrl-V.

#7 Kit
Používám MC přes SSH a tam to takto kopírovat nejde...

Já se neptám, jak to mám řešit. Mám to dávno vyřešeno jinak...

Ptám se, jestli existuje nějaký limit pro funkci CONCAT v MySQL, obecně, s JSONnem to vůbec nesouvisí...

To jestli píšu  chaotické kódy, je věc názoru a s dotazem to vůbec nesouvisí...

#8 Radek
Aha, proto ty mizerné barvičky, kvůli kterým je to pro mne nečitelné. Tvůrci MC mají skutečně divný vkus.

O limitu pro CONCAT() ses tady jistě už dočetl. Kromě toho je to popsáno i v dokumentaci.

V dokumentaci bys jistě našel i funkci CONCAT_WS(), která by se pro tvůj účel hodila mnohem lépe.

Pokud chceš, abychom se ve tvých kódech vyznali, posílej je přes formulář pod tlačítkem "<?". Slouží ke vkládání zdrojových kódů.

Klidně si piš programy jak čuně, ale nebraň druhým, aby si to mohli přerovnat podle obecných zvyklostí.

#8 Radek 

Kód jsem nezkoušel, ale podle mne by to takto bylo mnohem jednodušší:

<?php
class JsonFile {
    private static function createJsanFile() {
        $result = $db->query(<<<SQL
            SELECT
                ID_WEB_DATA AS ID,
                STATUS,
                TYPE,
                USE_OM_BC AS BC,
                PAREMT,
                USER_ID AS USERID,
                DATE_TIME AS DATE,
                LIMK,
                LABEL,
                LABEL_EM AS LABELEM,
                DESCRIPTIOM AS DESCRIPTIOM,
                DESCRIPTIOM_EM AS DESCRIPTIOMEM,
                DATA,
                DATA_EM AS DATAEM
            FROM TWEB_DATA ORDER BY DATE_TIME 
SQL 
        );
        return json_encode($result->fetchall());
    }
}

#10 Kit
Ano, uz jsem to prepsal do PHP jeste pred polozenim tohoto dotazu zde...

Ale puvodni reseni nad SQL slapalo o neco rychleji...

#11 Radek
Snad tě uklidní, že kdysi jsem to dělal také tak (místo JSON jsem generoval HTML) a také jsem to úplně stejně schytal od komunity. Dnes už vím, že ty vrstvy aplikace zachovávat musím.

Jen mi není jasné, proč došlo ke ztrátě výkonu. Možná proto, že ta funkce to dělá pořádně, bez kompromisů.

#12 Kit
S tim kopirovanim si mel pravdu, viz root...

Tak obecne by mela byt DB lepe optimalizovana na podobne operace, nez PHP, ne?

Ale treba se pletu a navic jsem neprovadel zadna konkretni mereni a prumerovani casu, takze se vlastne neni o cem bavit, je to jen muj pocit, ze je to asi 2x pomalejsi...

#13 Radek
Ne tak docela. Některé operace běží v PHP velmi svižně, protože jsou napsány v C/C++. Pomalé bývají cykly, proto se jim vyhýbám, jak jen to jde - agregačních funkcí je v PHP hromada.

Čísla raději zpracovávám přímo v DB, zejména finance. Datum a čas podobně. Lokalizaci si však nechávám až na výstupní šablonu nebo dokonce až na klienta. Agregaci dat do stringů dělám v PHP a v poslední době i v XSLT, které mě ohromilo svým výkonem. 

Na JSON však nic lepšího než json_encode() neznám.

#14 Kit
OK, ja nejsem DB guru...

Ale rozhodne ted uz bych se tolik nehrnul do podobnych "vychytavek" na strane DB,

driv jsem mel pocit ze je DB na podobne veci vice nez vhodna, sem tam jsem si udelal i nejakou DB proceduru...

#15 Radek

V DB se dá dělat spousta dobrých vychytávek, ale před použitím vložené procedury je nutné si to 2× rozmyslet. Nedávno jsem v proceduře dělal stavový automat a bylo to mnohonásobně rychlejší než v PHP. Hlavně kvůli tomu, že jsem nemusel z DB stahovat cca 100k záznamů, ale jen jeden výsledný.

Na druhou stranu v PHP velmi dobře a rychle fungují funkce implode(), array_map(), array_reduce(),... které se na spojování výsledků hodí. Navíc třeba funkce htmlspecialchars() v MySQL svůj ekvivalent nemá. A bez ní je jen otázkou času, kdy na tebe někdo zaútočí přes XSS.