Mongodb Primærnøkkel: Eksempel for å sette _id-feltet med ObjectId()

by: Stephen Twain Stephen Twain
Hours oppdatert

⚡ Smart oppsummering

MongoDB Primærnøkkelen er _id-feltet som unikt identifiserer hvert dokument i en samling. Som standard inneholder den en automatisk generert ObjectId, men du kan også tilordne din egen verdi til _id-feltet når du setter inn et dokument.

  • 🔑 Primær nøkkelrolle: Feltet _id er primærnøkkelen som unikt identifiserer hvert dokument i en MongoDB samling.
  • 🆔 Standard objekt-ID: Hvis du utelater _id, MongoDB legger automatisk til en unik 12-byte ObjectId-verdi i dokumentet.
  • ️ Tidsbestilt: En ObjectId begynner med et tidsstempel på 4 byte, så ID-er kan omtrent sorteres etter opprettelsestidspunkt.
  • ✍️ Tilpassede nøkler: Du kan oppgi din egen _id-verdi, for eksempel et tall eller en streng, når du setter inn et dokument.
  • 🔒 uforanderlige: Når _id-verdien er angitt, kan den ikke endres. Du må slette den og sette den inn på nytt for å endre den.
Les mer

Hva er Primary Key in MongoDB?

In MongoDB, _id-feltet som primærnøkkel for samlingen slik at hvert dokument kan identifiseres unikt i samlingen. _id-feltet inneholder en unik ObjectID-verdi.

Som standard når du setter inn dokumenter i samlingen, hvis du ikke legger til et feltnavn med _id i feltnavnet, MongoDB vil automatisk legge til et objekt-id-felt som vist nedenfor

Primær nøkkel inn MongoDB

Når du spør etter dokumentene i en samling, kan du se ObjectId for hvert dokument i samlingen.

Hvis du vil sikre det MongoDB oppretter ikke _id-feltet når samlingen opprettes, og hvis du vil spesifisere din egen id som _id for samlingen, må du eksplisitt definere dette mens du oppretter samlingen.

Når du eksplisitt oppretter et id-felt, må det opprettes med _id i navnet.

La oss se på et eksempel på hvordan vi kan oppnå dette.

db.Employee.insert({_id:10, "EmployeeName" : "Smith"})

Code Forklaring:

  1. Vi antar at vi oppretter det første dokumentet i samlingen, og derfor definerer vi i setningen ovenfor mens vi oppretter samlingen eksplisitt feltet _id og definerer en verdi for det.

Hvis kommandoen utføres vellykket og nå bruker finn-kommandoen for å vise dokumentene i samlingen, vil følgende utdata vises

Utgang:

Primær nøkkel inn MongoDB

Utdataene viser tydelig at _id-feltet vi definerte mens vi opprettet samlingen nå brukes som primærnøkkel for samlingen.

Hva er ObjectId i MongoDB?

En ObjectId er standardverditypen som MongoDB tilordner til primærnøkkelen _id. Det er en 12-byte identifikator som er utformet for å være globalt unik på tvers av servere og samlinger, slik at to dokumenter nesten aldri får samme verdi. Fordi klientdriveren kan generere en ObjectId uten å spørre serveren, MongoDB kan sette inn dokumenter raskt og skalere på tvers av mange maskiner uten en sentral teller.

Hver ObjectId lagres i et kompakt binært format, men vises som en heksadesimal streng på 24 tegn, for eksempel ObjectId(“507f1f77bcf86cd799439011”). De første bytene er basert på gjeldende klokkeslett, noe som betyr at verdiene øker jevnt etter hvert som dokumenter opprettes. Dette gjør ObjectId ikke bare unik, men også omtrentlig sorterbar etter innsettingsrekkefølge, en nyttig egenskap når du vil ha de nyeste eller eldste postene først.

Strukturen til en MongoDB Objekt-ID

A MongoDB Objekt-ID er nøyaktig 12 byte langt, og hver del har en spesifikk betydning. Å forstå strukturen bidrar til å forklare hvorfor objekt-ID-er er unike og tidsordnede:

  • 4-byte tidsstempel: Antall sekunder siden Unix-epoken, som registrerer når objekt-ID-en ble opprettet. Dette gjør ID-er sorterbare etter tid.
  • 5-byte tilfeldig verdi: En verdi generert én gang per prosess, som kombinerer maskin- og prosessidentiteten, slik at forskjellige klienter produserer forskjellige ID-er.
  • 3-byte inkrementell teller: En teller som starter fra en tilfeldig verdi og øker med hver ny ObjectId i samme sekund, noe som forhindrer kollisjoner under raske innsettinger.

Sammen garanterer disse tre delene at hver ObjectId er unik, selv når mange dokumenter settes inn samtidig på tvers av forskjellige servere. Du kan lese den innebygde opprettelsestidspunktet når som helst ved å kalle getTimestamp()-metoden på en ObjectId.

RELATERTE ARTIKLER

Fordeler med å bruke ObjectId som primærnøkkel

Å bruke standard ObjectId som _id-primærnøkkel gir flere praktiske fordeler, og det er derfor de fleste MongoDB samlinger er avhengige av det:

  • Automatisk generering: Du trenger ikke å opprette eller administrere nøkkelverdier selv, noe som reduserer sjansen for dupliserte nøkler.
  • Global unikhet: Objekt-ID-er forblir unike på tvers av servere, så de fungerer bra i distribuerte og shardede distribusjoner.
  • Innebygd tidsstempel: Den innebygde opprettelsestidspunktet lar deg sortere eller filtrere dokumenter etter alder uten et ekstra datofelt.
  • Høy ytelse: Klientsidegenerering unngår en rundtur til serveren, keeping setter inn raskt.

Selv om ObjectId passer til de fleste applikasjoner, kan du fortsatt velge en tilpasset _id, for eksempel en e-postadresse eller produktkode, når en naturlig forretningsnøkkel gjør spørringer enklere. Det riktige valget avhenger av hvordan du planlegger å slå opp og relatere dataene dine.

Spørsmål og svar

Nei. _id-feltet kan ikke endres når et dokument er opprettet. For å endre det, må du slette det eksisterende dokumentet og sette inn et nytt med ønsket _id-verdi.

Feltet _id godtar de fleste BSON-typer, inkludert ObjectId, heltall, strenger og til og med innebygde dokumenter. Den eneste regelen er at verdien må være unik i samlingen og ikke kan være en matrise.

Ja. MongoDB oppretter automatisk en unik indeks i _id-feltet for hver samling. Denne indeksen kan ikke slettes og gjør oppslag etter primærnøkkel svært raske.

AI kan forklare tidsstempelet til en ObjectId, generere kode for å f.eks.tract opprettelsestidspunkt med getTimestamp(), og konverter ObjectIds til strenger, helping utviklere feilsøker og forstår dokumentidentifikatorer raskere.

Ja. AI kan gi råd om hvorvidt standard ObjectId skal beholdes eller brukes en tilpasset _id, for eksempel en e-post eller UUID, basert på spørremønstre, unike behov og sharding-planer.

Oppsummer dette innlegget med: