Hírfolyam: https://www.instagram.com/P1camofficial/media/ Post embed: https://api.instagram.com/oembed/?omitscript=0&hidecaption=false&maxwidth=658&url=https://www.instagram.com/p/BY3e1kNlVA7/?taken-by=p1camofficial
A fejlesztők 2 fajtája nem foglalkozik az adatbázis lekérdezések sebességével több kapcsolódó adatnál: a kezdők és a profik. A kezdők lekérdezik az alap adatokat, majd egy foreach()-en belül futatják le a kapcsolódó adatok lekérdezését: foreach ( $products as $product ) { $db->query( „SELECT id, thumbnail, url FROM product_images WHERE product_id = :product_id” ); } A profik is ez csinálják, csak sokkal csillibb kivitelben. Először csinálnak egy Image class-t. Majd egy [….]
Sokan elkövetik azt a hibát, hogy a MySQL lekéréseket PHP ciklusba teszik, mert másképpen szerintük nem megoldható, hogy több soros eredményt tegyünk bele 1 SQL cellába a lekérdezés eredményénél. Ez a rossz módszer természetesen nagyon erőforrás pazarló és a weboldalak sebesség problémáinak nagy részét is ez okozza. Az egyik jó megoldás ennek elkerülésére, ha a GROUP_CONCAT() paranccsal egyesítjük a subquery sorait. Viszont alapértelmezetten ebbe csak viszonyag rövid eredmény fér, így [….]
Annak ellenére, hogy a JSON nagyon hódít – nyilvánvaló okok miatt, még mindig nagyon sokan használnak XML formátumokat. Többek között ilyen az RSS feed is, de az egyik legerősebb marketinggel rendelkező bérelhető webshop API-ja is, a ShopRenteré. XML-el dolgozni viszont rémálom a JSON-höz képest. Így hát felmerült a probléma, hogy valami egyszerű megoldás kellene, ahelyett, hogy minden XML-t végignézek.
A NoSQL hullám nagyon hódít, amivel én nem feltétlenül értek egyet, mert azt vallom, hogy mindent arra kell használni, amire való (azaz adatok tárolására, szűrésére, stb. SQL-t). Az egyik fő indok mellette azt szokott lenni, hogy JSON objektumokat lehet benne tárolni és azokkal lehet dolgozni. Így kliens oldal eleve készen kapja, nem kell a backenden összerakni és szétszedni újra és újra.
