Tafels met geen Primêre Sleutel

Question

Ek het'n paar tafels wie se enigste unieke data is'n uniqueidentifier ('n Guid) kolom.Want guids is nie-opeenvolgende (en hulle is die kliënt-kant gegenereer so ek kan nie gebruik newsequentialid()), ek het'n nie-primêre, nie-gegroepeer indeks op hierdie ID veld eerder as om die tafels'n gegroepeer primêre sleutel.

Ek wonder wat die prestasie implikasies vir hierdie benadering.Ek het gesien dat sommige mense stel voor dat die tafels moet'n auto-verhoog ("identiteit") int as'n gegroepeer primêre sleutel selfs as dit nie enige betekenis, want dit beteken dat die databasis enjin self kan gebruik wat waarde om vinnig te kyk op'n ry in plaas van om te gebruik om'n boekmerk.

My databasis saam te smelt-herhaal oor'n klomp van die bedieners, so ek het weggeskram van identiteit int kolomme as wat hulle is'n bietjie hard om reg te kry in replikasie.

Wat is jou gedagtes?Moet tafels primêre sleutels?Of is dit ok om nie enige gegroepeer indekse as daar geen sinvolle kolomme om die indeks dat die pad?

Answer 1

Wanneer die hantering van indekse, jy het om te bepaal wat jou tabel gebruik gaan word vir.As jy hoofsaaklik die invoeging van 1000 rye'n tweede en dit nie doen nie bevraagteken, dan'n gegroepeer indeks is'n treffer om die prestasie.As jy dit doen 1000 navrae'n tweede, dan nie met'n indeks sal lei tot baie slegte prestasie.Die beste ding om te doen wanneer ek probeer om te stem navrae/indekse is om te gebruik die Navraag Plan Analyzer en SQL Profiler in SQL Server.Dit sal jou wys waar jy is die bestuur in duur tafel skanderings of ander prestasie blokkers.

Soos vir die GUID vs ID argument, kan jy vind mense aanlyn wat sweer by beide.Ek het altyd geleer is te gebruik GUIDs tensy ek het'n baie goeie rede om nie te.Jeff het'n goeie pos wat praat oor die redes vir die gebruik van GUIDs: https://blog.codinghorror.com/primary-keys-ids-versus-guids/.

Soos met die meeste enigiets ontwikkeling verband hou, as jy op soek is om prestasie te verbeter daar is nie een, enkele regte antwoord.Dit hang af van wat jy probeer om te bereik en hoe jy is die implementering van die oplossing.Die enigste ware antwoord is om te toets, toets, en toets weer teen prestasie statistieke om te verseker dat jy jou doelwitte bereik.

[Wysig] @Matt, nadat doen'n bietjie meer navorsing op die GUID/ID-debat het ek afgekom op hierdie post.Soos ek voorheen genoem, daar is nie'n ware reg of verkeerde antwoord.Dit hang af van jou spesifieke implementering behoeftes.Maar hierdie is'n paar mooi geldige redes om te gebruik GUIDs as die primêre sleutel:

Byvoorbeeld, daar is'n probleem wat bekend staan as'n "hotspot", waar sekere bladsye van die data in'n tabel onder relatief hoë geldeenheid twis.Basies, wat gebeur, is die meeste van die verkeer op'n tafel (en dus van die bladsy-vlak slotte) plaasvind op'n klein area van die tafel, in die rigting van die einde.Nuwe rekords sal altyd gaan na hierdie hotspot, want IDENTITEIT is'n opeenvolgende nommer generator.Hierdie insetsels is lastig, want hulle vereis Exlusive bladsy slot op die bladsy wat hulle is bygevoeg (die hotspot).Hierdie effektief serializes al die insetsels om'n tafel te danke aan die bladsy sluitmeganisme.NewID() aan die ander kant nie ly aan hotspots.Waardes wat gegenereer word met behulp van die NewID() funksie is slegs opeenvolgende vir kort sarsies van insetsels (waar die funksie is genoem baie vinnig, soos tydens'n multi-ry voeg), wat veroorsaak dat die plaas rye te lukraak versprei oor die hele tafel se data bladsye in plaas van al aan die einde - dus die uitskakeling van'n hotspot van insetsels.

Ook, omdat die insetsels is lukraak versprei, is die kans van die bladsy split is aansienlik verminder.Terwyl'n bladsy verdeel hier en daar is nie te sleg nie, die gevolge moet optel vinnig.Met IDENTITEIT, bladsy Vul Faktor is redelik nutteloos as'n tuning meganisme en kan net so goed ingestel word om 100% - rye sal nooit ingevoeg word in enige bladsy, maar die laaste een.Met NewID(), jy kan eintlik gebruik maak van die Vul Faktor as'n prestasie-bemagtigende instrument.Jy kan Vul Faktor tot'n vlak wat naastenby geskatte volume groei tussen indeks rebuild, en dan die skedule van die rebuild tydens off-spitstye gebruik dbcc indekseer.Hierdie effektief vertraag die prestasie treffers van die bladsy split tot off-piek tye.

As jy selfs dink jy moet dalk in staat te stel replikasie vir die tafel in die vraag - dan is jy kan net so goed maak die PK'n uniqueidentifier en vlag die guid veld as ROWGUIDCOL.Replikasie sal vereis dat'n unieke gewaardeer guid veld met hierdie kenmerk, en dit sal voeg een indien nie een bestaan.As'n geskikte veld bestaan, dan sal dit net gebruik om die een dis daar.

Nog'n groot voordeel vir die gebruik van GUIDs vir PKs is die feit dat die waarde is inderdaad gewaarborg unieke - nie net onder al die waardes wat gegenereer word deur hierdie bediener, maar al die waardes wat gegenereer word deur al rekenaars - of dit jou db-bediener, web-bediener, app bediener, of die kliënt masjien.Pretty much elke moderne taal het die vermoë van die opwekking van'n geldige guid nou - in .NET jy kan gebruik Stelsel.Guid.NewGuid.Dit is BAIE handig wanneer die hantering van die kas meester-detail datastelle in die besonder.Jy hoef nie in diens te neem mal tydelike insleutel skemas net om met jou rekords saam voordat hulle daartoe verbind.Jy moet net gaan haal'n volkome geldige nuwe Guid van die bedryfstelsel stelsel vir elke nuwe rekord se permanente sleutel waarde by die tyd van die rekord is geskep.

http://forums.asp.net/t/264350.aspx

Answer 2

Die primêre sleutel dien drie doeleindes:

• dui aan dat die kolom (s) uniek moet wees
• dui aan dat die kolom (s) nie-nul
moet wees
• dokumenteer die bedoeling dat dit die unieke identifikasie van die ry

Die eerste twee kan gespesifiseer word in baie maniere, as jy reeds gedoen het nie.

Die derde rede is goed:

• vir die mens, sodat hulle maklik kan sien jou bedoeling
• vir die rekenaar, so 'n program wat kan vergelyk of andersins te verwerk jou tafel kan die databasis vir primêre sleutel die tafel se navraag.

'n primêre sleutel hoef nie 'n motor die verhoog aantal veld wees, so ek sou sê dat dit 'n goeie idee om jou GUID kolom spesifiseer as die primêre sleutel.

Answer 3

Net spring in, want Matt se aas my'n bietjie.

Wat jy nodig het om te verstaan dat alhoewel'n gegroepeer indeks is op die primêre sleutel van'n tafel by verstek, is dat die twee konsepte is afsonderlike en moet afsonderlik oorweeg word.'n CIX dui op die manier waarop die data is gestoor en verwys na deur NCIXs, terwyl die PK bied'n uniekheid vir elke ry om te voldoen aan die LOGIESE vereistes van'n tafel.

'n tafel sonder'n CIX is net'n Hoop.'n tafel sonder'n PK word dikwels beskou as "nie'n tafel".Dit is die beste om te kry'n begrip van beide die PK en CIX konsepte apart, sodat jy kan maak sinvolle besluite te neem in die databasis ontwerp.

Rob

Answer 4

Niemand het geantwoord werklike vraag: Wat is plus punte / minuses van 'n tafel met GEEN PK nóg 'n gegroepeer indeks. In my opinie, as jy optimaliseer vir vinniger insetsels (veral inkrementele grootmaat-insetsel, bv wanneer jy grootmaat vrag data in 'n nie-leë tafel), so 'n tafel: met GEEN cluster indeks, GEEN beperkings, geen vreemde sleutels, GEEN Standaard en GEEN Primêre Sleutel, in 'n databasis met 'n eenvoudige Recovery Model, is die beste. Nou, as jy ooit wil hierdie tafel navraag (in teenstelling met dit skandering in sy geheel), dan kan jy 'n nie-gegroepeer nie-unieke indekse voeg as dit nodig is, maar hou hulle aan die minimum te beperk.

Answer 5

Ek ook nog altyd gehoor dat 'n motor-verhoog van int is goed vir prestasie selfs as jy nie eintlik gebruik nie.

Answer 6

'n primêre sleutel hoef nie 'n autoincrementing veld, in baie gevalle beteken dit net jy kompliserende jou tafel struktuur.

In plaas daarvan moet 'n primêre sleutel die minimum versameling van kenmerke (let op dat die meeste DBMS n saamgestelde primêre sleutel jou sal toelaat) wat uniek identifiseer 'n tuple. Wees

In tegniese terme, dit moet die stuk grond wat elke ander gebied in die tuple is ten volle funksioneel afhanklik wees. (As dit nie wat jy dalk nodig om te normaliseer).

In die praktyk, kan prestasie kwessies beteken dat jy saamsmelt tafels, en gebruik 'n verhoog van die veld, maar dit lyk asof ek iets oor voortydige optimization onthou wat sleg is ...

Answer 7

Aangesien jy doen replikasie, jou korrek identiteite is iets om te stear duidelik van.Ek sou jou GUID'n primêre sleutel, maar nonclustered want jy kan nie gebruik newsequentialid.Dat stikes my as jou beste kursus.As jy dit nie doen nie maak dit'n PK maar sit'n unieke indeks op dit, vroeër of later wat kan veroorsaak dat mense wat in stand te hou die stelsel om te verstaan nie die SK verhoudings behoorlik die bekendstelling van foute.