Dibi/Database a substituce

áno používam. Zo zvyku pri rovnomenných tabuľkách napr. web_polls a forum_polls napr.

@hrach > tak taky prihodim trochu do mlynku… v byvaly praci jsme prefixy pouzivali, ale hlavne z toho duvodu, ze se predelaval system a bylo potreba rozlisit novy tabulky (s prefixem) od tech starych (bez prefixu). Ale posledni dobou zjistuju ze je to spis zlo a porad na tom zapominam, takze (ikdyz jsi psal ze se o budoucich projektech zminovat nemame) je brzo asi zase pouzivat prestanu…

ale podle me spis zalezi jak je databaze slozita a jestli obsahuje tabulky pro vic projektu (celkem blbost, ale taky sem videl :D) nebo ne apod… Ono kdyz je pres 300 tabulek tak je dobry je mit rozliseny vice prefixy a ne jenom jednom, je v tom vetsi prehled.

Pouzivam prefixy u kazdeho projektu a to automaticky a intuitivne.

Dovody su nasledovne:

1. niekedy narazis na limited hosting u klienta a si nuteny tak mat vsetky tabulky v 1 DB
2. pri jednom projekte mozes mat viacero subaplikacii ktore pouzivaju svoje tabulky napr WordPress a tvoja aplikacia
3. v jednej samostatnej aplikacii takto namespacujem nazvy tabuliek. Napr: fb_ su tabulky ktore sluzia pre FB appku, stat_ su tabulky ktore uchovavaju potom statistiky nad danou appkou apod

Okrem spominanych vyhod ma napada aj jedna mala – na prvy pohlad nebadatelna, no mrte efektivna – Jakubov Adminer dokaze pri exporte DB spravit regex vyhladavanie podla prefixov a teda namiesto vyklikavanie napr 30 tabuliek na export (phpMyAdmin) si kliknem na prefix stats_ a vuala – mam oznacene vsetky tabulky so statistikami na export ;)

Používáte v jednu chvíli tabulku se stejným jménem ale jiným prefixem?

no, spíš se bavím o těch celoaplikačních prefixech (app_user, app_user_address) a ptam se, jestli v tu chvli nekdo pouziva fb_user. Z vyse zmineneho sem pochopil, ze ano.

Abych jeste lepe specifikoval problem, jde o toto:

• v klasickem dibi se hodilo psat do sql substituce, ani jinak to neslo, napsat parser na sql by neslo (select * from [:fb:user] where ...)
• v nette database jsou substituce taky, ale aktualne nefunguji na tabulky ($db->table(':fb:user'))
• v nette database by šlo takoveto věci dělat automaticky pomocí upravené database struktury, kteoru jsem již naprogramoval a pulloval
• dana automatika je velmi mocná, nicméně by znepříjemnila život v situaci, kdy máme dvě tabulky s různým prefixem. Šlo by pak v rámci automatiky udělat něco takévehoto:

use Nette\Database\Reflection\DatabaseReflection;
class MyDatabaseReflection extends DatabaseReflection
{
	public function __construct()
	{
		parent::__construct('id', '%s_id', '%s', 'myapp_%s');
	}

	public function getPrimary($table)
	{
		if (substr($table, 0, 3) === 'fb_')
			$table = substr($table, 4);
		return parent::getPrimary($table);
	}

	public function getReferencedColumn($name, $table)
	{
		if (substr($table, 0, 3) === 'fb_')
			$table = substr($table, 4);
		return parent::getReferencedColumn($name, $table);
	}

	public function getReferencedTable($name, $table)
	{
		if (substr($table, 0, 3) === 'fb_')
			$table = substr($table, 4);
		return parent::getReferencedTable($name, $table);
	}

	public function getPrefixedTable($table)
	{
		if (substr($table, 0, 3) == 'fb_')
			return $table;
		return parent::getPrefixedTable($table);
	}
}

V této ukázce

• V této ukázce bych pro běžný prefix (myapp_) bych používal Nette\Database naprosto standardně bez starostí ($db->table('users') → .. from myapp_users ..)
• Pro fb aplikační tabulky bych používal jejich název s prefixem $db->table('fb_users') → .. from fb_users ..
• dané používání tabulek lze samozřejmě kombinovat $db->table('users')->where('facebook_user_id', $db->table('fb_users')->where(...))

@westrem: souhlas

Magie by to nebyla kdyby se metoda table nejmenovala table… :-)