Dnes: 16. ledna 2017    | Registrace | Hledáme | Redakce | Info | Testy | Školení | Ocenění | Nápověda | Čtenář: nepřihlášen

Rychlé odkazy
  • Hlavní stránka
  • Seznam rubrik
  • Ankety
  • Editoriály
  • TOP 15
  • KONFERENCE 2008
  • KONFERENCE 2007
  • KONFERENCE 2006
  • KONFERENCE 2005
  • KONFERENCE 2004
  • Sborník
  • Testy
  • Virtuální školení
  • Personalizace


  • Hledáte práci?
    Hledáme redaktora - pojďte s námi tvořit Databázový svět!

    Vyhledávání

    Hledej
    na Databázovém světě!



    Rozšířené vyhledávání

    Rubriky
    Aktuality
    Bezpečnost
    Business
    Česká scéna
    Datové sklady
    Dokumentace
    Dotazovací jazyky
    Hardware
    Historie
    Komentáře
    Literatura
    Metodologie
    Nondb
    Open Source
    Poradna
    Produkty
    Případové studie
    Redakce
    Rozhovory
    Standardy
    Technologie
    Tipy - triky
    Tiskové zprávy
    Vývoj
    Vývojové nástroje
    Zajímavosti

    Co je to?
    Replikace
    Replikace slouží pro zajištění konzistentnosti dvou a více databází, nejčastěji pak o stejné struktuře v rámci distribuovaného zpracování. Vyspělé SŘBD replikace podporují, případně lze použít řešení třetích stran či replikační logiku zajistit vlastními postupy.

    Akce
    Dynamická Datová Centra
    - na semináři se seznámíte s komplexním řešením a koncepcí Dynamických Datových Center od Fujitsu Siemens Computers se speciálním důrazem na řešení FlexFrame.

    Textová inzerce
    IBPhoenix - Vše o InterBase a Firebirdu.

    Smějete se rádi? - Pak je pro vás Vtipník to pravé!

    Prodejce reklamy - Hledáme schopného prodejce reklamního prostoru, možnost i externí spolupráce.

    Přihlášený čtenář
    Nepřihlášený čtenář

    O portálu
    Databázový svět
    ISSN: 1213-5933

    Web je optimalizován pro rozlišení 1024x768, nicméně kromě větších rozlišení podporujeme i 800x600. Podrobnosti najdete zde.

    Chcete-li mít kdykoliv možnost zkontrolovat obsah našeho portálu, můžete využít podporu rss. Podrobnosti najdete zde.
    GUID nebo int jako PK na MSSQL?


    [Tipy - triky] - Na internetu koluje mnoho názorů ohledně používání GUID jako primárního klíče, především v porovnání s datovým typem int. Nalézt je možné mnoho srovnání a zamyšlení nad oběma typy. Jak to ale vlastně je z pohledu výkonu?



    Uveďme podle nás dvě nejdůležitější okolnosti využití GUID jako primárního klíče:

    • GUID je konkrétně 4× delší než int. Ačkoli datová úložiště jsou levnější, než byla před rokem, musíme vzít v potaz i zpracování v operační paměti a samozřejmě i velikosti, které musejí být zpracovány indexační podčástí databázového stroje.
    • GUID je mnohem hůře zapamatovatelný a "předávatelný". Číslo do URL zakomponujete lehce. Stejně tak si jej uživatel lehce zapamatuje a poskytne například do telefonu. Stejně tak jej lze lehce napsat a tento zápis je přirozený snad pro všechny vrstvy vývoje aplikace. Naproti tomu reprezentovat přímo GUID není tak jednoduché.

    Abychom ale měli nějaké konkrétní podklady, provedli jsme jednoduchý výkonnostní test. Na testování jsme použili Windows 2003 Server Standard Edition Service Pack 2, běžící na stroji s 1,5GB RAM a P4@1,60GHz CPU. Na serveru běželo několik standardních služeb, které generovaly mírnou zátěž. SQL Server samotný byl použit ve verzi 2005.

    Do jednoduché tabulky bylo nejprve vloženo přibližně 2,6 milionu záznamů se zapnutým indexem, tak rychle jak server mohl (žádná síťová komunikace apod.). Citelně propadl, podle očekávání, GUID, jehož vkládání bylo zhruba 3× pomalejší (včetně generování). Na druhou stranu, vyhledávání na přímou shodu (nikoli rozsahové dotazy) nepřineslo žádné dramatické rozdíly (odstraněny byly vždy nejlepší a nejhorší výsledky). Časy dotazů se stále v rámci chyby měření pohybovaly, pro oba typy, okolo stejných hodnot.

    Ačkoli náš test není vše-pokrývající, a pro konkrétní výsledky doporučujeme udělat si vlastní testy, můžeme s jistotou říci, že pokud máme důvod používat GUID jako klíč (jsme si vědomi ostatních problémů, kterou mohou nastat), není třeba se obávat rapidní ztráty výkonu. Pro aplikace, které především čtou data je rozdíl minimální – situaci ovšem mohou zkomplikovat složité dotazy nad více propojenými tabulkami. V případě aplikací intenzivně zapisujících data je rozdíl větší – je tedy vhodné si provést vlastní testy a zvážit, zdali je zpomalení akceptovatelné.

    ( Celý článek! | Autor: Jiří Činčura | Počet komentářů: 5 | Přidat komentář | Informační e-mailVytisknout článek )

    Vyhledávání
     

    Anketa
    Kolik ročně utratíte za dovolené?

    Nic 
     (943 hl.)
    Do 1 000,- Kč 
     (741 hl.)
    Do 10 000,- Kč 
     (705 hl.)
    Do 25 000,- Kč 
     (816 hl.)
    Do 50 000,- Kč 
     (735 hl.)
    Do 75 000,- Kč 
     (756 hl.)
    Více než 75 000,- Kč 
     (712 hl.)

    Celkem hlasovalo: 5408


    Poslední komentáře
    frontierd@126.com
    frontierd@126.com
    frontierd@126.com
    c
    http://www.coachoutl

    Newsletter
    Přihlaste si nezávazně - i bez registrace - odběr informačního newsletteru. Podrobné informace najdete zde.

    Emailová adresa:


    Kalendář
    <<  Leden  >>
    PoÚtStČtSoNe
           1
    2345678
    9101112131415
    16171819202122
    23242526272829
    3031     

    Redakci připojuje


    Nejčtenější

    Databáze je prázdná!


    Nejvíce komentářů

    Databáze je prázdná!


    Reklama






    Nenechte si ujít články na dalších webech




    Na této stránce použité názvy programových produktů, firem apod. mohou být ochrannými známkami
    nebo registrovanými ochrannými známkami příslušných vlastníků.

    Databázový svět | dfKlub - digitální fotografie | Vtipník - vtipy přímo k Vám | Reminder - přestaňte zapomínat | Databázový svět

    Copyright (c) 2004 AVRE Publishing, spol. s r.o. Všechna práva vyhrazena