Struktura databáze a vytváření tabulek z aplikace

pidiclovek

Ahoj,

Zabývám se teď následujícím problémem a zajímaly by mě vaše názory. Dělám eshop, který se ale vlastně skládá z více pod eshopů, které se budou uživateli jevit víceméně jako jeden. Bude zde uživatel, který bude takovéto eshopy vytvářet.

A protože v těchto pod eshopech budou nemalé množství produktů, uvažuji o tom, že každý bude mít své vlastní tabulky pro produkty, které budou eshopu náležet. Čistě vzhledem k velikosti a rychlosti vyhledávání.

Teď myšlenky, kterými se zabývám – je vhodné mít u uživatele, pomocí kterého se připojuji v configu k databázi práva na rušení či vytváření tabulek? Není možné se připojovat pomocí dvou uživatelů k databázi, jak by se to ale promítlo v configu?

A celkově jsem se ještě nesmířil ani s těmi tabulkami, např název tabulky.:

products_store1
products_store2
…

co si o tom myslíte, či jak řešíte rozdělení tabulek v případě očekávání velkých datových obsahů?

Díky za názory :)

Ot@s

Výhodny/nevýhody asi tušíš sam. Případně zvaž skutečné důvody proč dělit projekt do „sub-tabulek“:

slabší parametry hostingu (rozložení zátěže do více tabulek)
snadnější práce s přístupovými právy (netestuje se na úrovni řádků, ale tabulek)
časté importy dat (resp. časté INSERT/DELETE nad daty)

Teorie návrhu databáze tomu moc hovět nebude, takže osobně se to řeším tak, že:

mám MySQL – provedu si praktické testy (poctivě i s indexy nad příslušnými sloupci) a pak se rozhodnu (zdroje dat pro import třeba zde)
mám Postgres – používám inheritance

Většinou to dělám tak, že co patří do jedné tabulky, tak to tam dám. Dělení totožných dat do více tabulek mě přineslo spíše problémy, než výhody.

llook

Přijde mi to jako premature optimization.

Jestli to pojede na jednom stroji, tak by snad neměl být velký rozdíl mezi SELECT ... FROM "products_store1" a SELECT ... FROM "products" WHERE "store_id" = 1 (samozřejmě předpokládám index nad „store_id“). Vsadím se, že i agregátory typu Heuréka nebo Zboží mají všechny produkty v jedné tabulce, a že to je nějaké množství produktů.

Jinak dvě databázová spojení se jednoduše nadefinují jako dvě služby v config.neon:

common:
	services:
		database:
			class: Nette\Database\Connection
			arguments: ['mysql:host=localhost;dbname=test', 'user', 'password']
		alterant:
			class: Nette\Database\Connection
			arguments: ['mysql:host=localhost;dbname=test', 'superuser', 'password']

Nové tabulky pak lze vytvářet jednoduše:

$container->alterant->exec('CREATE TABLE tbl_new LIKE tbl_old');

Ale podle mě to má víc nevýhod, než výhod.

pidiclovek

Velice děkuji oboum!

Už od začátku se mi vzhledem k čistotě návrhu nápad s více než jednou tabulkou nelíbil. Asi to nechám opravdu v jedné tabulce a hodím hosting někam, kde mi nebude os na kterém databáze poběží příliš omezovat max velikost tabulky. Tyto úvahy mi pomohly si uvědomit potencionální výhody i nevýhody, ještě jednou děkuji!

Díky i za příklad s neonem, dal bych si facku, že se ptám na takovou jednoduchost :)

Filip Procházka

Ono stejně, pokud ti aplikace naroste, tak ti nepomůže ani 10 databází a budeš tam muset dát search engine :) Nějaký Sphinx, nebo ElasticSearch (ale to by se taky dalo v téhle fázi projektu označit jako předčasná optimalizace;)