Vlákno názorů k článku Úvaha ohledně zneužívání LIKE v databázích od Franta Kučera - LIKE jsem vždycky bral jako velmi primitivní fulltextové...
-
LIKE jsem vždycky bral jako velmi primitivní fulltextové vyhledávání a tak ho taky občas používám, pokud nic lepšího není (takže na anketu nedokážu moc dobře odpovědět). Ale použít ho na cokoli jiného většinou znamená špatně navržený datový model. Ale vysvětluj to lidem, kteří serializují pole do textového řetězce a ten vrazí do databáze :-D
Měl bych dotaz k umělým primárním klíčům: je nutné používat všude číselné ID? Proč nepoužít jako PK e-mailovou adresu (viz příklad v článku)? Jde mi o to, že není moc dobré mít v tabulce víc unikátních sloupců (adeptů na primární klíč). Dejme tomu, že nebudeme předpokládat změnu e-mailové adresy (nebo ji budeme předpokládat tak málo často, že nám nebude vadit nutnost aktualizovat závislé tabulky – ON UPDATE CASCADE). Dá se čekat, že práce s textovými klíči a indexy bude pomalejší, ale kde je ta hranice, kdy se dají ještě použít a usnadnit si tak práci (nevytvářet zbytečné umělé klíče – což je jen technická pomůcka k propojení relací, nikoli něco, co by existovalo v reálném světě)? -
Těžko říct. Dejme tomu, že budu mít tabulku uživatelů. V ní sloupeček email_addr. Pravděpodobně budu mít nad tímto sloupcem unikátní klíč. Pokud by byl zároveň primárním klíčem, pak musím určitou podmnožinu adres zkopírovat do dalších tabulek (tam, kde jsou cizí klíče). A pokud bych měl nad FK ještě index, tak dojde k dalšímu zkopírování email adres. Z toho důvodu je praktičtější (úspornější) používat umělé klíče.
Delší klíč vám zabírá více místa v paměti, o něco déle se natahuje.. Vím ale, že jsou teoretici, kteří se umělým klíčům brání jak čert kříži. Já osobně mám raději číselné PK, případně pokud to lze, tak PK, které lze převést na číslo. -
Ideální by bylo, kdyby programátor pracoval s „přirozenými“* klíči a SŘBD by si to v pozadí převáděl na čísla – protože tohle je implementační záležitost, kterou se nechci zabývat, stejně jako když píši deklarativní SQL, místo abych psal procedurálně výběry dat z databáze.
*) třeba uživatelské jméno není přirozené, ale můžeme ho tak brát, protože je prostě dané, přichází k nám např. z jiného nadřízeného systému, nebo e-mailová adresa, kterou nám zadá uživatel, např. když chce vydat x509 certifikát pro svůj e-mail. -
Smyslem „autoinkrementu“ je nějak jednoduše označit vkládaný objekt, protože pro něj nemáme jinou identifikaci – tzn. neexistuje přirozený primární klíč → musíme použít umělý → nebudeme si ho vymýšlet v aplikaci, ale použijeme „autoinkrement“. Pokud ale přirozený PK, můžeme použít ten a „autoinkrement“ vůbec nepotřebujeme. Pokud nám jde o výkon (rychlost porovnání, velikost indexů), tam má smysl zavést umělé PK, ale jinak k tomu důvod moc nevidím.
-
atarist (neregistrovaný)prvni odstavec - v jednom informacnim systemu je tak 30% informaci ulozeno v takzvanych "strukturovanych poznamkach", tj. do aplikace se dobastlily dalsi atributy tak, aby se nemuselo menit GUI, uzivatele to proste cpou do poznamek - chutovka s tim dal pracovat, kazdy uzivatel si vymysli trosku neco jineho :-)
druhy odstavec - cisla (zvlast pokud jsou "mala", nejaky ten small int, int ci numeric(8)) se daji porovnat jednou operaci, zatimco u retezcu je slozitost prohledani vetsi. V tabulce o "n" zaznamech bude v nejhorsim pripade prohledavani ciselnych ID mit slozitost O(n), u retezcu je to O(n*m), kde m je prumerna delka retezce. Take (podle mych zkusenosti - ale nejsem uplne kovany databazista) se mi zda, ze je lepsi pouzivat "nemluvici" klice, protoze se DB potom lepe rozsiruje - treba vazba 1:n se da jednoduse zmenit na m:n.
Mam jeden priklad z praxe: u jedne energeticke spolecnosti je primarnim klicem v jejich databazi cislo SIPA, ze ktereho se za energie plati (na to se vazbi cislo elektromeru nebo odberniho mista). Proto je problem z jednoho uctu platit za vice odbernych mist - to jejich db nezvladne, protoze vse vazbi na SIPO, coz je blbost. Kdyby tam byl nemluvici klic, tak by klidne mohli vazbu rozsirit na m:n a vse by (po par upravach) fungovalo. -
1) To už mi přijde lepší tuhle „customizaci“ postavit na XML – v DB bude jeden sloupeček pro uživatelská XML data. To umožňuje celkem libovolné přizpůsobení ze strany uživatele a přitom jsou data strukturovaná – i když na jiném principu než je relační.
2) Jak jsem psal výše – nejradši bych, aby tuhle optimalizaci dělala databáze a já tyhle implementační detaily jako databázový modelář / programátor nemusel řešit
3) Tohle je chyba analýzy, někdo se prostě „zapomněl“ zeptat, jestli je možné platit z jednoho účtu více elektroměrů. Radši mám přirozené klíče a ty umělé beru jako nutné zlo z důvodu výkonnosti. -
logik (neregistrovaný)3) Ono v době tvorby aplikace to třeba možný nebylo. Jakmile je klíč "významovej", tak vždycky hrozí to, že si uživatel bude chtít aplikaci rozšířit a nepůjde to.
Libovolnej "mluvící" klíč požaduje, aby relace vůči němu byly 1:n. A u libovolný vlastnosti osoby jde vymyslet případ, kdy tý osobě těch vlastností přiřadím více než jednu. -
Sten (neregistrovaný)1) Správně navrženou databázi nebývá problém rozšiřovat, důležité je, že vaše klíče musí jít snadno nahradit (= je výhodnější použít ordinální typy). Pro XML můžete rovnou použít XML databázi.
2) Jenže pokud provedete deset dotazů do databáze, tak byste to řešit měl i jako programátor: buď pošlete desetkrát nějaký string s velkou složitostí vyhledávání nebo ten string pošlete jednou a potom už posíláte ordinální typ. Stejně tak se pomocí ordinálních typů daleko snáze (a rychleji) dělají multi-tier aplikační architektury, protože ordinální typy se daleko snáze zpracovávají (např. jako klíče pro statistiky nebo cache v RAM). -
LENIN POWER! (neregistrovaný)db2 9 umi XML i relacni data. Ty data xml uklada ve stromove strukture a nerosekava je do tabulek. Jsou to v podstate 2 databaze v jedne. Otvira to radu novych moznosti ve vyvoji aplikaci. Kuprikladu schema evolution je velice hezke.
http://www.ibm.com/developerworks/wikis/display/db2xml/Home
