Hlavní navigace

Vlákno názorů k článku PHP okénko: Využití unikátních klíčů v databázi od geneticy - Je sice všeobecně známo, že mnoho programátorů webových...

  • Článek je starý, nové názory již nelze přidávat.
  • 27. 3. 2005 22:06

    geneticy (neregistrovaný)
    Je sice všeobecně známo, že mnoho programátorů webových aplikací obvykle o databázích nic nebo málo ví, ale tyhle uvedené konstrukce jsou na pováženou. U PHP to je většinou markantní, protože je oprávněně velice oblíben a práce s databázemi je pod ním tak jednoduchá...Ale právě ta počáteční jednoduchost maskuje časté nedostatky nebo neochotu se seznámit s tím, jak ten který DB stroj pracuje.

    Takže - pokud máte skutečnou databázi s potřebnou výbavou, tak se jakémukoliv zamykání čehokoliv vyhýbejte, pokud to jde. Zamykání záznamů je vyhrazeno pro případná transakční zpracování (běžný dotaz by měl probíhat jako with nolock) sad dat nad více tabulkami, případně pro lokální aplikace s nativním přístupem k danému DB stroji, kde je kontrola skutečného odemčení záznamu. Pokud někdo laboruje se zamykáním na úrovni stránky/sady (pokud to tedy ten DB stroj umožňuje) nebo celé tabulky, musí mít zatraceně dobrý důvod. Webová aplikace bez middleware (typicky většina PHP aplikací, ale platí to třeba i o starých ASP) by takový rozsah neměla vůbec používat a pokud ano, tak zprostředkovaně přes uložené procedury DB stroje (pokud je podporuje). V silně konkurenčním prostředí naděláte hodně škody podobnými nápady.

    Na potřebný zásah v uvedeném příkladu Vám skutečně postačí klíč typu UNIQUE, případně CANDIDATE (dle typu DB serveru) nad daným polem a nic více. Odchytit pak případnou chybu při insertu je elementární praxe databázového programování a nic víc nepotřebujete, než tuto chybu zdvořile oznámit uživateli, ať si vymyslí jiné username. Backlink dotazy stojí akorát zbytečnou režii aplikace a DB serveru a de facto oznámí uživateli totéž, ale zatíží databázi jedním (nebo více) zbytečným dotazem.

    Přihlašování dotazem na celou tabulku userů je taky pěkný zlozvyk. Buď databázový stroj umožňuje příjem parametrů a pak lze posílat login name jako parametrický dotaz, nebo, pokud DB stroj umožňuje využívat views (pohledy), dotaz poslat na k tomu určený view, který je v cache DB stroje, je naindexován a fyzicky předtříděn dle potřebného pole (v tomto případě username).

    Domnívám se, že by jako motiv tohoto článku bylo lepší, kdyby bylo případným začátečníkům vysvětleno, co je to PRIMARY KEY, CLUSTERED INDEX, FOREIGN KEY, UNIQUE KEY a kdy je použít. A pak tabulku, kde jsou porovnány nejběžnější databáze, zda to či ono mají ve výbavě. A až na závěr teprve příklad použití.

    I když - kovářova kobyla chodí bosa...když se dívám na některé své aplikace, tam je taky dost prohřešků. Ale alespoň návody pro začínající by jich měly být prosty. :)))

    No flame, please...
  • 27. 3. 2005 22:47

    Jakub Hegenbart
    Těžko lze s něčím z toho nesouhlasit, snad jen si nejsem jist, zda zrovna u tabulky uživatelů je overhead takový, aby separátní view přinesl nějaké výkonnostní rozdíl, nehledě na to, že přihlašování snad netvoří tak podstatnou část dotazů. Kromě toho, server, který s pohledy dělá takové věci jako fyzické třídění pohledu asi nebude příliš často používán jako backend PHP aplikace :)

    Co přesně rozumíte tím parametrickým dotazem? (Mám takové tušení, ale v tomto jednoduchém ködu mi asi mi uniká souvislost...)
  • 28. 3. 2005 13:50

    martin (neregistrovaný)
    Přesně tak, jak jsem už uvedl výše - je nutné si vybrat. Buď rezignovat na ošetření chyb, aplikaci rychle napsat, chvíli používat a pak zahodit (při té chvíli používání žádná chyba stejně nenastane a když jo, prd se stane), anebo se snažit psát neprůstřelně a robustně, ale pak je nutné používat i neprůstřelnou a robustní databázi.

    Pokud nemáme v db transakce a v jazyce podporu výjimek, pak se jakákoliv snaha napsat kvalitní aplikaci nemůže setkat s úspěchem.
  • 29. 3. 2005 20:18

    gemda (neregistrovaný)
    Ked sa uz vravi o tom kde sa malo zacat, tak vlastne ani nechapem preco sa v "PHP okienku", hned v prvom diely, hovori o mysql funkciach.

    Aj ked je pravda, ze login sa riesi ako prvy z casti webu ( aspon v mojom pripade), ktore vyzaduju databazu, takze to dava zmysel, len to mohlo byt nejako vysvetlene preco autor zacal prave odtial.

    Mna napriklad nedavno prekvapili zmeny v komunikacii PHP a MySQL co sa tyka ich novsich verzii. Teda nepatrim k tym co sa vyznaju a k problemu som sa dostal len tak ze som chcel nainstalovat phpBB2 a postNuke na mysql 4.1.8 co skoncilo odpovedou ze moj mysql klient je zastaraly a ze ho mam obnovit. Pravdu som zistil az tu v casti "Installation":

    http://www.php.net/manual/en/ref.mysql.php

    kde je medzi inym spomenute ze na MySQL verzie 4.1.+ je vhodne pouzit funkcie "mysqli_" ktore sa sice od "mysql_" funkcii z mojho hladiska odlisuju akurat tym pismenkom "i" :) ale moje phpBB to nevyriesi.

    Tiez tam spominaju zmeny v PHP 5 comu som tak celkom neporozumel, a to je to, co by ste mohli (ci uz dobrovolne alebo nie :) opisat v nejakom dalsom diely, ze ako su na tom verzie php verzus mysql.