Připojení k databázi
Školení, která pořádám 
Není nad to mít parametry připojení k databázi v jednom centrálním souboru, který se všude, kde se s databází pracuje, pouze vhodně použije. Při změně parametrů připojení pak stačí změnit jeden soubor a není třeba to měnit na mnoha místech. Je už celkem jedno, jestli se připojení realizuje pomocí vloženého souboru, funkce nebo konfiguračního souboru, důležitá je ta centrálnost. To platí samozřejmě obecně – stejný kód by se vždy měl nacházet pouze na jednom místě (obvykle je na to nejlepší funkce nebo třída, v některých případech stačí prosté vložení souboru), u připojení k databázi to je ale obzvlášť citelné.
<?php // vložení souboru include "./connect.inc.php"; // soubor obsahuje přímo kód pro připojení k databázi // zavolání funkce include "./functions.inc.php"; // soubor obsahuje funkci, která zařídí připojení k databázi db_connect(); // konfigurační soubor include "./config.inc.php"; // soubor obsahuje konstanty definující parametry připojení k databázi mysql_connect(DB_SERVER, DB_USER, DB_PASSWORD); mysql_select_db(DB_NAME); ?>
Třetí způsob je o něco horší, protože časem můžeme usoudit, že by měl být nějak ošetřen případ, kdy se k databázi nepodaří připojit a budeme zase muset sahat do všech souborů.
Diskuse
Llaik:
Treti zpusob ma take ten "problem", pokud nekdy budete chtit svou mysql databazi vymenit za jinou. V ten okamzik budete muset vsude menit i samotne nazvy fci.
Ze vsech tri zpusobu bych doporucil druhy krizeny s druhym, tedy:
1] include souboru s nastavenim (nastaveni ma cela aplikace na jednom miste - nenastavuje se preci jen db, ale treba i defaultni skin ci cesta k obrazkum...)
2] include soubor s funkcemi (pripadne jen include souboru s funkcemi pro praci s db, to jiz zalezi na konkretnim pripade - kazdopadne fce nemichat s nastavenim!)
3] zavolani me vlastni fce pro pripojeni k db (preci jen jsou skripty, ktere vyzaduji nastaveni, treba vyzaduji i nejake me vlastni fce, ale nepotrebuji pripojeni k db - pripadne pripojeni k db potrebuji jen v nejake podmince.
Adam:
Pokud budeš chtít vyměnit databázi za jinou, tak musíš stejně změnit názvy všech funkcí, které s ní pracují, takže je lepší používat nějakou jinou vrstvu.Bjarne:
druhy krizeny s druhym? to pak ale neni krizeni :)Llaik:
Samozrejme, mozna jsem tedy mohl byt presnejsi - krome jiz zminene vlastni fce pro pripojeni k db mam samozrejme i vlastni fce pro vsechny ostatni operace s danou db (a pokud bych byl liny si je psat, podivam se na pear.php.net).
To vse ma nejenom vyhodu snadneho prechodu na jinou db, ale napriklad i rozsireni funkcnosti techto fci (fci mysql_query nahradim za svou vlastni, ktera bude umet zpracovavat chybovy navrat, tuto chybu logovat, prehravat spravci mp3 apod)
Bjarne:
Tenhle prispevek me zase utvrdil v tom, ze tenhle serial je pro zacatecniky (ne-li uplne zacatecniky). Informace z tohoto serialu se clovek dozvi z jakykoliv lepsi knizky o PHP v kombinaci s nepostradatelnym manualem :)Jinak nechci shazovat neci iniciativu, jen se mi nezda to pojmenovani ;)Bochi:
Možná ano, ale podle mě svůj smysl má. A ani pro ty, co ví, není občas na škodu si něco zopakovat. Já osobně se nepovažuju za úplného začátečníka, ale občas se tu dozvím něco zajímavého.Squad_Lead:
Hej. Jako tady neni kazdy profesionalni programator jako ty!Ja i kdyz zacatek plne chapu tak se pri precteni cele debaty dozvim minimalne na co si dat pozor nebo co delat lepe.
Kdyz sam nic nedelas tak tady nenapadej p. Vranu, ze narozdil od tebe neco dela.
Jako kritizovat dokaze kazdy:
"Kdo něco umí, dělá to. Kdo to neumí, učí to. A kdo neumí nic, ten o tom alespon píše. A kdo nedokaze ani jedno ten stoji a kritizuje".
spaze:
nejsem si jist, jestli se nahodou neco takovyho nechysta, ale kdyby ne, co takhle napsat clanek o tom, ze _mmmkay, pconnects are bad!_ ? :)
spaze: 
Jakub Vrána 
:
Chystá, posouvám to v edičním plánu nahoru :-).
Jakub Vrána : Tomáš:
Taky mám pocit, že to je hodně pro začátečníky. Daleko lepší způsob je všechny vlastní funkce pro přístup do databáze obalit do třídy.Llaik:
V cem je to lepsi? Pouziti objektu jako namespace? Hm, uzasne :)
Tomáš:
No, namespace má taky velkou a nenahraditelnou roli. Ale absence jmenných prostorů v PHP nenahradí ani todle. Objekt je prostě skupina funkcí, zaroveň ale nese libobolné množství informací. Prostě jako jakýkoliv jiný objekt všude kolem nás. Hlavní podstatou je to, že každý objekt je zodpovědný na určitý okruh činnosti a toho, kdo ten objekt používá nemusí vůbec zajimat, jak to uvnitř funguje. Když potřebujete zjistit čas, taky nevolá jen tak do vduhu jaký je čas, ale zeptáte se konkrétního objektu přes jeho veřejné rozhraní. Tím jsem popsal asi jedno procento všech výhod objektového programování. Možnosti jsou skutečně obrovské a programovat neobjektově rozsáhle aplikace, zvláště ve více lidech je skoro nepožné a pokud je někdo zastámce neobjektového programování a bude tvrdít, že je lepší. Tak je to jeho věc nevo spíše jeho smůla.Llaik:
jiste, je velky rozdil, mezi:
db_connect() a $db->connect()
predevsim, pokud si to benchmarknete :)
Co jste rekl o objektovem programovani, s tim se da pouze souhlasit. Pouze pod PHP to ma jeden velky hacek - naparsuje se knihovna, vytvori se instance objektu, pripoji se k db, provede dotaz, zobrazi vysledek, odpoji se od db, zrusi objekt, vse zapomene.
Prijde druhy uzivatel, a server se opakuje.. a treti, a opet se opakuje..
U mnoha aplikaci v mnoha jazycich se o neobjektovem programovani nema asi ani smysl bavit. Ale pokud vemu vykonnost PHP a veci, ktere potrebuji - tak to zacina byt na vazkach.
S cimz jsme asi trosku predbehli tema tohoto weblogu :)
Bjarne:
O te rychlosti bych se nehadal, ja to nikdy netestoval :)Koneckoncu od toho tu jsou pocitace aby se dreli ;) Ale velmi dulezita vlastnost OOP je zapouzdreni a skryvani dat. Proto pouzivam "objektove" paradigma i v PHP a take se mi daleko vice zamlouva ten zpusob samotne prace. Vyhody OOP se proejvuji pri vetsich projektech. Cetl jsem v jedne knizce uvahu autora na tema: Potrebuje PHP OOP? A tam je to napsany velmi dobre a je tam popsane vice nez dobre ;)Tomáš:
Neprováděl jsem taky žádné velké testování, ale rozohdně se vyplatí PHP doplnit o nějaké akcelrátor, ať už Zend nebo open source variantu http://www.eaccelerator.net/HomeUkAle samozřejmě souhlasím, že OOP je pro PHP náročnější, ale pro mě přehlednější. A napsané třídy jsou mnohem lépe znovu použitelné, aniž bych musel žit ve strachu, že použiju proměnnou, kteoru jsem už někde jako globální použil. A to je důležitější. Jestli jsem několikrát narazil na úzké hrdlo v PHP aplikacích, tak to nikdy nebylo kvůli OOP.
Mirun:
Jenže kromě (zbytečného) obalení standardních funkcí třídou si do ní můžu přibalit taky vlastní funkce, ošetření selhání atd. a nemusím pak neustále psát stále stejné věci, protože je obsahuje třída, kterou pak používám všude.Pokud píšu aplikaci pro 500 návštěv denně, nemusím nic benchmarkovat protože je to zbytečné, stejně to poběží někde na veřejném hostingu kde může běžet spousta zrůdností, které neovlivním a pokud jí píšu pro 50000 denně, tak mě zase vyjde levněji posílit železo, než se za tři měsíce při požadované změně v aplikaci utopit v kódu. OOP má v PHP velkou režii, ale jsem (já) přesvědčen o tom, že komfort a rychlost tvorby aplikací, možnost změn a modularizace za to prostě stojí.
Bjarne:
kua ten konec...je takovej...divnej :)))
llook:
Nejlepší se mi zdá tohle:
<?php
$dsn = 'mysql://user:pass@host/database';
?>
Takže změna jména, hesla, adresy, názvu databáze nebo samotného typu databáze představuje úpravu právě tohoto jednoho řádku.
Tohle umožňuje například PEAR::DB nebo ADODB.
llook: Jan Dvorak:
Pro toho, kdo ma tu moznost (je adminem serveru) - nenechavejte pristupove udaje k db valet v souborech s pravy verejneho cteni (coz php skripty jsou).Reseni v Apache: nejlepe je vrazit pomoci direktivy SetEnv primo do httpd.conf, ktery ma vlastnika root a prava 700.
Napr.
SetEnv dbuser JanDvorak
SetEnv dbpswd nejakeheslo
Neprecte si ho tak nikdo jiny nez root a Apache pri start-upu (tehdy totiz docasne funguje s pravy roota a pak prejde na "nobody"). Ve skriptech pak budou udaje pristupne v superglobalnim poli jako $_SERVER['dbuser'] a $_SERVER['dbpswd'].
Jestli jste docetli az sem, tak je vam asi jasne, ze je to sice dobre reseni, ale pouzitelne pri vyvoji aplikaci pro appliance nebo dedikovany server. Nepouzitelne na sdilenem webhostingu.
Radek:
Nemohu se připojit k databázi MySQL i když používám:mysql_connect(localhost, root, příslušné heslo);
mysql_select_db(píslušná databáze);
Samostaně mi vše chodí, v MySQL mám vytvořené různé databáze, které mi řádně pracují, ale to spojení přes PHP ne a ne. Prosím o radu.
Jakub Vrána :
Zeptej se radši na http://diskuse.jakpsatweb.cz/index.php?act…&forum=9. Tam se ti s takovýmito problémy budou spíše věnovat.
Jakub Vrána : zaachi:
NO - i když už je článek staršího data, proč nepřispět svou troško. :-DBěžně používám způsob:
<?php
function __autoload($name)
{
require_once $name . '.php';
}
class class_name extends connect
{
function __construct()
{
parent::__construct();
}
}
?>
Tino:
Čau borci, mám databázové jméno a heslo v jiném PHP souboru definované jako konstanty a v dalším souboru mám mnou definovanou funkci, která je používá pro připojení. Oba soubory pak includuji (ve správném pořadí) ve všech stránkách, používajících databázi. Jen si chci ověřit, jaká jsou rizika toho, že se někdo k souboru s heslem dostane. Mám to na veřejném hostingu (host.sk) a teď se jim to zrovna nějak přetěžuje a místo aby to parsovalo php a vrátilo jeho výstup, vrátí to rovnou neparsovaný PHP soubor! Tím případný útočník zjistí jméno includovaného souboru s heslem a pak ho zkusí zobrazit. Když to budou mít zase přetížené, tak mu to vrátí neparsované PHP a tam uvidí definici konstanty s heslem. Nehci rady ať změním hosting. Nějakým DoS útokem lze přetížit leccos.Tino:
Když mám ošetření přístupu do podadresáře přes .htaccess (deny from all), tak předpokládám, že si ten soubor s heslem nikdo nezobrazí, ať už se to parsuje nebo neparsuje kvůli přetížení. Pokud v tom vidíte nějakou díru, budu rád za radu.Diskuse je zrušena z důvodu spamu.
© 2005-2024 