| Autor | Zpráva | ||
|---|---|---|---|
| MONTYCEK Profil |
#1 · Zasláno: 13. 1. 2016, 13:39:54
Zdravím, mám v mysql tabulku kde je velké množství článků. U výpisu článků potřebuji zobrazit informace o autorovi příspěvku, ale v tabulce s články mám jen id toho autora a zbylé informace mám v tabulce kde jsou uživatelé.
Jak se dá co nejsnadněji získat informace o tom autorovi jen na základě toho id? Když si vytvořím funkci, která si informace vytáhne z db tak je to celkem náročné na server, tak to aktuálně řeším tak že si informace o uživateli ukladam do souboru a v tom vypisu ten soubor vždy otevřu a informace čerpám odtud, ale nemyslím si že je to nejlepší řešení. |
||
| juriad Profil |
Použij JOIN:
SELECT a.*, u.name FROM articles a LEFT JOIN users u ON a.author = u.id Opraveny aliasy v dotazu. |
||
| MONTYCEK Profil |
#3 · Zasláno: 13. 1. 2016, 13:48:41
juriad:
Ok dík vyzkouším to, ale bude to méně náročné než využití přímo funkce v php která ta data bude mít v v souboru? Jde mi hlavně o to, aby se snížilo množství dat přenášených z DB. |
||
| juriad Profil |
#4 · Zasláno: 13. 1. 2016, 14:23:51
MONTYCEK:
Spočítej si kolik těch dat navíc přeneseš z databáze. 300 bytů? Každý jeden článek je větší než všechna jména autorů dohromady. Přemýšlel jsi o tom, že bys na jednu stránku vypsal místo 10 článků jen 5? Tím by se ušetřilo přenesených dat mnohem více. Ten soubor se seznamem autorů musíš přečíst vždy celý a pokud z něj použiješ jen málo autorů, je to mnohem horší plýtvání. A ještě jinak, i kdyby MySQL bylo na jiném serveru v rámci hostingu, pořád jsou to mikrosekundy na rozdíl od milisekund / celých sekund, které uživatelé čekají třeba na obrázek, který je zbytečně velký. Nesnaž se šetřit tam, kde to nemá smysl. Piš elegantní kód. A přečti si Předčasná optimalizace |
||
| MONTYCEK Profil |
#5 · Zasláno: 13. 1. 2016, 14:35:17
juriad:
No možná jsem se špatně vyjádřil. problém je v tom že v té tabulce není potřeba jen jméno autora. Jde o všechna data z tabulky uživatelů pro toho daného autora (je tam celkem dost položek). A když jsem si to tahal z db tak mi server padal při větší frekvenci. Proto jsem to udělal přes tu funkci kde se to zlepšilo. Na toto zrovna nejsem nějakej expert takže se radši ptám jak to řešit. Možná by se mi spíše hodilo nějaké řešení jak ta data co nejlépe cachovat, aby se dala používat za běhu ze souboru. |
||
| juriad Profil |
#6 · Zasláno: 13. 1. 2016, 14:40:05
MONTYCEK:
Co je větší frekvence? Kolik databázových dotazů jsi celkem pokládal při výpisu seznamu článků? |
||
| MONTYCEK Profil |
#7 · Zasláno: 13. 1. 2016, 15:02:58
juriad:
No bývá to hodně jelikož v db jsou tisíce záznamů a je zde něco jako export do xml který je potřeba při každém zavolání aktuální. Pokud jsem to bral přímo z db tak mysql vytížila cpu na 100% což je nežádoucí, ale s těmi soubory kde jsou informace o uživatelích to není ani 30% na celém serveru. |
||
| Keeehi Profil |
#8 · Zasláno: 13. 1. 2016, 15:23:38
MONTYCEK:
„v db jsou tisíce záznamů“ To není mnoho. Ovšem rozdíl bude, pokud na vytažení těch záznamů potřebujete jen konstantní počet dotazů nebo jejich počet závisí na množství dat. |
||
| MONTYCEK Profil |
#9 · Zasláno: 13. 1. 2016, 15:37:45
Keeehi:
ideální je získat vše jako jeden výstup (ty záznamy nejsou problém), ale zajímá mě spíš jak k nim přidat informace o tom autorovi aby to nebylo moc náročné a nestalo se, že třeba server bude moc vytížený. Už jsem dostal pár rad a to právě s tím ukladáním do souboru a pak ještě, že prý je lepší použít Nette a tam prý je nějaká funkce Cache, která je k tomu vhodná, ale nevím zda by to bylo lepší řešení než ted kde data ukladam do těch samostatných souborů. |
||
| juriad Profil |
MONTYCEK:
Databáze toho zvládne hodně. Jaké dotazy jsi tam spouštěl? Byly pokryté indexy? Co o nich říkal EXPLAIN? Kolik dotazů bylo na jednu stránku? Pokud neznáš odpovědi, mohla být rada, ať smažeš náhodně polovinu článků, stejně dobrá jako ta, ať si autory ukládáš do souboru. |
||
| MONTYCEK Profil |
#11 · Zasláno: 13. 1. 2016, 16:11:32
juriad:
No zatím toho zvládá hodně, ale obávám se co se bude dít až tam těch dat bude víc jak pár tisíc, ale nejspíš to nechám až na dobu kdy to opravdu nebude zvládat a server bude přetížený. |
||
|
Časová prodleva: 9 let
|
|||
0