Jedna databáze na jeden projekt
Školení, která pořádám 
Pro udržení přehlednosti tabulek je více než vhodné mít pro každý projekt vytvořenou vlastní databázi. Na nekomerčních webhostinzích to většinou není možné – jeden uživatel dostane jednu databázi a když chce další, musí si ji založit pod novým uživatelem. Na komerčních hostinzích to možné obvykle je, ale pouze za poplatek, v horším případě dokonce pravidelný měsíční.
Přijde mi to velice smutné s přihlédnutím k tomu, že např. v MySQL jde snadno povolit vytváření databází odpovídajících nějaké masce příkazem ve tvaru GRANT ALL ON `vrana\_%`.* TO 'vrana'. Bezpečnostní rizika s tím spojena žádná nejsou, velikost se dá hlídat stejně jako u jedné databáze a nároky na podporu jistě také nijak zvlášť nevzrostou – kdo už si chce další databázi vytvořit, ten to jistě s vhodným návodem zvládne. Jenže nekomerční hostingy si nejspíš říkají „máte to zadarmo, tak buďte rádi, že vám dáme alespoň jednu databázi“ a komerční zase „na tom by se dalo něco trhnout, dáme to za poplatek“.
Pak to v horším případě skončí tím, že jsou tabulky z různých projektů pomíchané v jedné databázi a pokud náhodou kolidují jejich názvy, tak se jim přidá třeba koncovka „2“. V lepším případě tím, že jsou tabulky alespoň některých projektů prefixované svým názvem a v kódu jsou k vidění dotazy typu SELECT mujprojekt_uzivatele.* FROM mujprojekt_uzivatele INNER JOIN mujprojekt_prava ON mujprojekt_uzivatele.id = mujprojekt_prava.uzivatel WHERE mujprojekt_prava.pravo = 3.
Přijďte si o tomto tématu popovídat na školení Návrh a používání MySQL databáze.
Diskuse
tark:
Od toho snad jsou "prefixový" fce v db layerech, ne? Potom stačí jen nastavit prefix a layer se o to stará sám..Každopádně mě napadlo, že by nebyl špatnej nápad udělat něco ve stylu SELECT id,title from __tabulka -> ty dvě podtržítka by se braly jako prefix, protože 'SELECT id from '.$db->prefix('tabulka') je dost nepohodlný...
Michal Hantl:
U mě na hostingzdarma mám bohužel taky jen jednu databázi a musím to řešit prefixama. Pro jednoduché a časté sql dotazy(pohyb ve stromové struktuře a selekce z ní) mám jednu třídu, takže až na vyjímky sql dotazy "nevidím".Taky bych nejradši více sql databází, na pípni je myslím mají, ale tam se mi zas nelíbí že freehosting je pomalý a tuším nedovolují .htaccess.
Michal Molhanec:
jojo, na pipni neni pocet databazi omezen, vytvareji se pres admin rozhrani a vsem se automaticky pripojuje ke jmenu _domena_tld, takze se to nemicha. a nevim o tom, ze by s timhle meli nejake problemy typu "5k databazi, kazdy jedna tabulka" jak tu nekdo psal...Tomik2:
Pokud jsem dobře pochopil, tak autor asi myslel mít pod jedním uživatelským jménem 2 a více databází, což pipni.cz taky nesplňuje, byla by to ještě o něco větší výhoda než mít neomezený počet databází ale také jiných loginů.Petr:
Osobně si myslím, že pokud někdo dělá 'více projektů', tak by pro něj neměl být problém zaplatit pár korun za nějaký slušný hosting, který více databází podporuje, případně si za to připlatit. Navíc, pokud ty 'další projekty' za něco stojí, tak si každý zaslouží i vlastní doménu.To, že se v této souvysloti řeší freehostingy nechápu.
migon:
dej na placenem hostingu (vlastne kdekoliv) neomezenej pocet db a pri par schopnejch blaznech tam mas do tejdne 5k databazi a v kazdy bude jedna tabulka... dekuju radsi ne... :-DNick:
Na freehostingu ano, ale kdyz si nekdo zaplati vlastni domenu, za hosting plati treba 300/mesic, tak se da predpokladat jista inteligence spravce projektu a negenerovani zbytecnych databazi ;-) Naopak u takoveho projektu neni zrovna nejlepsi, kdyz se tabulky ze subdomen michaji mezi tabulky hlavni domeny. Do toho jeste tabulky phpbb fora a pak se v tom nekdo snadno a rychle orientuj...Navi:
Mam placeny hosting na pipni, databazi si muzu zalozit kolik na klikam a presto k teto situaci nedoslo - a tusim ze je totez mozne i ve free verzi.Havran:
PostgreSQL (7.4 a novsie) ma v tomto pripade zaujimave riesenie - schemy. Cosi ako databaza v databaze. Dost intenzivne pouzivam...Karel Benák:
Souhlasím, schémata v PostgreSQL jsou naprosto super záležitost, jejich použití je pro případy nutnosti "odstínit" od sebe jednotlivé tabulky výhodné.kocour v botách:
Já mám ve zvyku definovat si na začátku prefix jako konstantu (většinou ji ale nechám prázdný řetězec) a pak ji ve všech dotazech před každou tabulkou doplňovat. Pokud je pak potřeba tabulky projektu "odstínit" od druhého příchozího, udělám to změnou této konstanty a ALTER TABLE .. RENAME TO nad tabulkami stávajícího projektu.
Jakub Vrána 
:
Mě se to moc nelíbí, protože pak je kód plný konstant, které jsou v ideálním případě prázdné. Ale chápu, že v praxi to může být kvůli omezenosti hostingů to nejlepší řešení. Lepší smysl by mi to dávalo s nějakou abstrakční vrstvou, která by tam ty prefixy dávala centrálně.
Jakub Vrána : kocour v botách:
To by ale podle mě znamenalo buď syntaktickou analýzu každého spouštěného dotazu (a spolu s ním spoustu strojového času), nebo jeho zadávání pomocí argumentů funkcí nebo řetězení metod (které bude vždycky více nebo méně nepřehledné a méně intuitivní než prosté SQL).
Diskuse je zrušena z důvodu spamu.
© 2005-2024 