Řešení single server CMS

aDAm
na jednom serveru pouzivaji s vyhodou sql-lite tak, ze pro kazdeho uzivatele zalozi vlastni db. Tim padem se veskere jeho vyhledavani stava uspornym. Bohuzel u zprav uzivatelu dochazi k duplicite, ale tak, co uz. Za to muzou drzet vsechny zpravy neomezene dlouho.

Bez podrobnejsich znalosti tezko radit, ale nevidim duvod proc nepouzit jednu spolecnou databazi. Na tyto otazky by vam mela odpovedet analyza s odhadem poctu uzivatelu, polozek v DB, pomer cteni/zapisu, atd.

aDAm:

Já bych naopak doporučoval pro každou doménu/projekt extra databázi. Představte si například, že budete někdy v budoucnu chtít jeden takový projekt ze sdílené databáze přesunout jinam - taky se vám ta představa tak šíleně nelíbí? :)

Rozdíl v vytížení/výkonu/rychosti s jednou nebo 50 databázemi je myslím neměřitelný a rozhodně nebude stát za to, aby se dal uvažovat jako výhoda jedné z variant.

Kešování je dobrý nápad, nejen výsledky z db, ale i velká pole a objekty rozhodně stojí za to kešovat.

aDAm:
„tak ono vyselectovat pak jeden projekt z celé db by neměl být problém každý projekt by měl svůj identifikátor a podle něj by se dal nastavit filtr. “
To je právě to, co jsem naznačoval, není jednodušší udělat jeden dump celé databáze, vč. struktury, klíčů, indexů, atd., atd. než to všechno selectit jedno po druhém?

V řešení s jednou sdílenou databází pro společná data nevidím žádný zádrhel. Jedno připojení navíc ke sdílené db nevidím jako moc problém a považuji to za standartní řešení - jedna databáze pro jádro aplikace (cms, crm, eshop,...) a jednu na data pro jednotlivé projekty.

Osobně jsem zastáncem řešení s jednou centrální databázi pro úschovu dat o nainstalovaných webech (cesty, ftp účty, atd.) a pak pro každý web databázi zvlášť. Podle mně je výhodnější na začátku vybrat správnou databázi a pak pracovat pouze s daty, které patří pouze k příslušnému webu než při každém datazu vybírat data podle nějakého id webu. Nevýhodou je nutnost upravovat více databázi při updatu, ale s pomocí dat z centrální databáze to jde poměrně dobře automatizovat.

Řešení s více databázemi je určitě lepší z bezpečtnostního hlediska. Nemusíme hlídat jestli se čerpají pouze data, která patří k přislušnému webu.

Dále předpokládam, že každý web bude mít svou složku, ve které bude index.php obsahujici pouze require bootstrap souboru jádra a uživatelska data. Pak při adresování souborů nemusíme rozlišovat cesty podle toho, o který web se jedná.

Ssob: „Řešení s více databázemi je určitě lepší z bezpečtnostního hlediska. Nemusíme hlídat jestli se čerpají pouze data, která patří k přislušnému webu.“

To jste myslel jako vtip? Je to preci nesmysl. Potom muzete chtit pro kazdeho uzivatele it vlastni databazi, pro kazdy clanek, atd. Bezpecnost to nijak nezvysi, ale vase dusicka bude mit pokoj.

Preci data filtruji pomoci podminek v dotazu, v pripade ucelenych casti je v SQL vez zvana VIEWs, ktera se myslim na tento pripad velmi dobre hodi.

Tedy jedna databaze, a pro kazdy projekt oddeleny uzivatel s patricnymi pravy a vytvoreny VIEW.

Vykonostne by to melo byt urcite rychlejsi. A je to podle pravidel normalizace, ktere tu nejsou jen tak pro nic za nic.

ninja
„To jste myslel jako vtip?“
Spíše jako připomínku pod čárou. Samozřejmě se to dá zabezpečit například použiváním VIEWs. Ale už tam je ta další věc, kterou musím řešit.

Výkonnostně to bude zcela určitě pomalejší.

Relacni databaze jsou navrzeny tak, aby pracovali s velkym objemem dat (poctem radku) v tabulce, ne aby pro kazdych par radku se stejnou strukturou bylo vytvareno vlastni tabulka, natoz databaze.

Opravdu si myslite, ze napriklad sluzba blog.cz vytvari pro kazdeho uzivatele vlastni databazi na clanky?

Těď nechci zabíhat dál než sahají moje obzory, jestli se mýlim, tak mě opravte.

Ale.. není náhodou VIEW také určitá forma tabulky, ze které se pak tahají data? Takže to je vicemeně obdobný přístup jako u vícero databázi s tím rozdílem, že se ještě musí vytvořit ten VIEW.

Ale i kdyby se nepoužil view, tak dotazy zaberou (asi zanedbatelně) víc času. Přece když chci mít všechno uloženo v jedné databázi, tak musím mít navíc pár spojovacích tabulek a u hodně tabulek sloupec určující web navíc. Z toho vyplýva, že při dotazech musím použit více spojování a "wherovani".