Hlavní navigace

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...