Autor Zpráva
aDAm
Profil
Zdravím lidi,
řeším problém jak by se dal řešit single server CMS
tj. jeden systém, jeden server a otázka zda jen jednu DB

Moje vize je tato:
- Systém na jednom serveru
- Uživatelská data ( fotky, soubory atd co se přikládají k článkům v oddělených klientských složkách )
- Domény budou směřovat do jednoho místa a systém z podle nich bude zjišťovat o jaké stránky se bude jednat a poskytovat data návštěvniku

akorát nevím jak vyřešit DB
- buď pro každou doménu svou db
- nebo jedna centrální DB pro všechny projekty
- a nebo pro každého klienta svou DB, rozdíl oproti první možnosti je to že jeden klient může mít více stránek.

co vy na to jak by jste to řešili?
peta
Profil
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.
ninja
Profil
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
Profil
tak sem nad tím ještě přemýšlel a možná by dost pomohlo pokud by se obsah který se nemění cachoval, tím by ubylo dotazu do DB

Ono myslím že pokud by bylo vytvořeno více DB na jednom serveru nebo jen jedna DB pro všechny zatížení by bylo asi +- stejné ne?
Aesir
Profil
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
Profil
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.

Ale zase u řešení více db vidím nevýhodu v tom, že bych musel mít jednu centrální db pro administraci, kde by byli uživatelé, nastavení atd a pak jednotlivé db pro projekty kde by byly data a v administraci pak pracovat se dvěmi db najednou pokud by bylo potřeba
Aesir
Profil
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.
Ssob
Profil
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á.
ninja
Profil
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.
Ssob
Profil
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ší.
ninja
Profil
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?
Ssob
Profil
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".
aDAm
Profil
tak pokud jsem dobře pochopil funkci view tak to jakoby vytvoří virtuální tabulku takže by se dalo udělat třeba clanky_webxy kde by byl pomoci view udelan select z tabulky clanky jen pro web xy

Ssob
jak píšeš, pro každý web vlastní složku, přemýšlel jsem spíš o jedné centrálni, je tam jen index.php který si natáhne jádro systému a soubor htaccess pro upravu adres, ale tady bych možná narazil na problém při dělaní pravidel pro všechny weby, resp jedno pravidlo děla z neco . cz www . neco . cz dalsi pravidla sou stejna pro vsechny weby.
V adresaci souborů bych problém neviděl, protože všude používám absolutní cesty.

Jinak práce se dvěmi db by neměl být problém stejně tak jako použití VIEW nebo klasický selecetovat pomocí WHERE spíš mě zajímá co je elegantnější a výhodnější řešení.
aDAm
Profil
Takže jsem teda udělal struktůru následovně:

na serveru adr:
cms-core - zde je jádro systému a prezentační web systému

domena-com - zde jsou bootloadery na jádro a individuální soubory prezentace

DB je nakonec pro každý projekt individuální.

Bude tak zjednodušena aktualizace jádra systému u DB problém stále asi zůstane, pokud se změní struktůra nějaké tabulky bude se muset provést aktualizace u všech projektů cože je sice nevýhoda ale aspoň je to plus s jádrem.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: