డేటాబేస్లో కీలు

5.1 పరిచయం

రిలేషనల్ డేటాబేస్‌లలో కీలను ఎలా ఎంచుకోవాలి మరియు ఉపయోగించాలి అనే దాని గురించి ఇంటర్నెట్ డాగ్మాటిక్ సూత్రాలతో నిండి ఉంది. కొన్నిసార్లు వివాదాలు హోలివర్‌లుగా మారతాయి: సహజమైన లేదా కృత్రిమ కీలను ఉపయోగించాలా? స్వీయ-పెంపు పూర్ణాంకాలు లేదా UUIDలు?

అరవై నాలుగు వ్యాసాలు చదివి, ఐదు పుస్తకాలలోని విభాగాలను తిప్పికొట్టి, IRC మరియు StackOverflowపై టన్నుల కొద్దీ ప్రశ్నలు అడిగిన తర్వాత, నేను (అసలు వ్యాసం రచయిత జో "బెగ్రిఫ్స్" నెల్సన్) పజిల్ ముక్కలను ఒకచోట చేర్చినట్లు అనిపించింది మరియు ఇప్పుడు ప్రత్యర్థులను పునరుద్దరించవచ్చు. చాలా కీలకమైన వివాదాలు నిజానికి వేరొకరి దృక్కోణం యొక్క అపార్థం నుండి ఉత్పన్నమవుతాయి.

సమస్యను విడదీసి, చివర్లో మళ్లీ కలిపేద్దాం. మొదట, ప్రశ్న అడుగుదాం - "కీ" అంటే ఏమిటి?

ఒక క్షణం ప్రాథమిక కీల గురించి మరచిపోనివ్వండి, మేము మరింత సాధారణ ఆలోచనపై ఆసక్తి కలిగి ఉన్నాము. కీ అనేది నిలువు వరుస (నిలువు వరుస) లేదా నిలువు వరుసలలో నకిలీ విలువలు లేని నిలువు వరుసలు . అలాగే, నిలువు వరుసలు తప్పనిసరిగా ప్రత్యేకతను కలిగి ఉండాలి, అనగా నిలువు వరుసల ఉపసమితి ఈ ప్రత్యేకతను కలిగి ఉండదు.

కానీ మొదట, కొన్ని సిద్ధాంతం:

ప్రాథమిక కీ

ప్రాథమిక కీపట్టికలోని అడ్డు వరుసలను గుర్తించడానికి నేరుగా ఉపయోగించబడుతుంది. ఇది క్రింది పరిమితులకు అనుగుణంగా ఉండాలి:

• ప్రాథమిక కీ అన్ని సమయాలలో ప్రత్యేకంగా ఉండాలి .
• ఇది ఎల్లప్పుడూ పట్టికలో ఉండాలి మరియు విలువను కలిగి ఉండాలి.
• ఇది తరచుగా దాని విలువను మార్చకూడదు. ఆదర్శవంతంగా, ఇది విలువను అస్సలు మార్చకూడదు .

సాధారణంగా, ఒక ప్రాథమిక కీ పట్టిక యొక్క ఒకే నిలువు వరుసను సూచిస్తుంది, అయితే ఇది బహుళ నిలువు వరుసలతో కూడిన మిశ్రమ కీ కూడా కావచ్చు.

మిశ్రమ కీ

కస్టమ్ కీ- ప్రతి పట్టిక వరుసను ప్రత్యేకంగా గుర్తించే లక్షణాల (నిలువు వరుసలు) కలయిక. ఇది అన్ని నిలువు వరుసలు మరియు అనేకం మరియు ఒకటి కావచ్చు. ఈ సందర్భంలో, ఈ లక్షణాల విలువలను కలిగి ఉన్న పంక్తులు పునరావృతం కాకూడదు.

సంభావ్య కీ

అభ్యర్థి కీ- సంబంధం యొక్క కనీస మిశ్రమ కీని సూచిస్తుంది (టేబుల్), అంటే, అనేక షరతులను సంతృప్తిపరిచే లక్షణాల సమితి:

• ఇర్రెడసిబిలిటీ : ఇది తగ్గించబడదు, ఇది కనీస సాధ్యమయ్యే లక్షణాలను కలిగి ఉంటుంది.
• విశిష్టత : ఇది అడ్డు వరుస మార్పుతో సంబంధం లేకుండా ప్రత్యేక విలువలను కలిగి ఉండాలి.
• విలువ యొక్క ఉనికి : ఇది శూన్య విలువను కలిగి ఉండకూడదు, అనగా అది తప్పనిసరిగా విలువను కలిగి ఉండాలి.

5.2 ప్రాథమిక కీల యొక్క ఆసక్తికరమైన సందర్భం

మునుపటి విభాగంలో మనం "కీలు" అని పిలిచే వాటిని సాధారణంగా "అభ్యర్థి కీలు"గా సూచిస్తారు. "అభ్యర్థి" అనే పదం అటువంటి అన్ని కీలు "ప్రాధమిక కీ" (ప్రాధమిక కీ) యొక్క గౌరవ పాత్ర కోసం పోటీపడతాయని సూచిస్తుంది మరియు మిగిలిన వాటికి "ప్రత్యామ్నాయ కీలు" (ప్రత్యామ్నాయ కీలు) కేటాయించబడతాయి.

SQL అమలులు కీలు మరియు రిలేషనల్ మోడల్ మధ్య అసమతుల్యతను అధిగమించడానికి కొంత సమయం పట్టింది, మరియు తొలి డేటాబేస్‌లు ప్రాథమిక కీ యొక్క తక్కువ-స్థాయి భావన వైపు దృష్టి సారించాయి. సీక్వెన్షియల్ స్టోరేజ్ మీడియాలో వరుస యొక్క భౌతిక స్థానాన్ని గుర్తించడానికి అటువంటి డేటాబేస్‌లలోని ప్రాథమిక కీలు అవసరం. జో సెల్కో దీన్ని ఎలా వివరించాడో ఇక్కడ ఉంది:

"కీ" అనే పదం ఫైల్ క్రమబద్ధీకరణ కీని సూచిస్తుంది, ఇది సీక్వెన్షియల్ ఫైల్ సిస్టమ్‌లో ఏదైనా ప్రాసెసింగ్ కార్యకలాపాలను నిర్వహించడానికి అవసరం. పంచ్ కార్డ్‌ల సెట్ ఒకటి మరియు ఒకే క్రమంలో చదవబడింది; తిరిగి వెళ్ళడం అసాధ్యం. ప్రారంభ టేప్ డ్రైవ్‌లు అదే ప్రవర్తనను అనుకరిస్తాయి మరియు ద్వి దిశాత్మక ప్రాప్యతను అనుమతించలేదు. అంటే, అసలు Sybase SQL సర్వర్ మునుపటి అడ్డు వరుసను చదవడానికి టేబుల్‌ను ప్రారంభానికి “రివైండ్” చేయడానికి అవసరం.

ఆధునిక SQLలో, మీరు సమాచారం యొక్క భౌతిక ప్రాతినిధ్యం, పట్టికల నమూనా సంబంధాలపై దృష్టి పెట్టవలసిన అవసరం లేదు మరియు అడ్డు వరుసల అంతర్గత క్రమం అస్సలు ముఖ్యమైనది కాదు. అయినప్పటికీ, ఇప్పుడు కూడా SQL సర్వర్ డిఫాల్ట్‌గా ప్రాథమిక కీల కోసం క్లస్టర్డ్ ఇండెక్స్‌ను సృష్టిస్తుంది మరియు పాత సంప్రదాయం ప్రకారం, వరుసల క్రమాన్ని భౌతికంగా అమర్చుతుంది.

చాలా డేటాబేస్‌లలో, ప్రాథమిక కీలు గతానికి సంబంధించినవి మరియు ప్రతిబింబం లేదా భౌతిక స్థానం కంటే కొంచెం ఎక్కువగానే అందిస్తాయి. ఉదాహరణకు, PostgreSQL పట్టికలో, ప్రాథమిక కీని ప్రకటించడం స్వయంచాలకంగా పరిమితిని అమలు చేస్తుంది NOT NULLమరియు డిఫాల్ట్ ఫారిన్ కీని నిర్వచిస్తుంది. అదనంగా, ప్రాథమిక కీలు ఆపరేటర్ కోసం ప్రాధాన్య నిలువు వరుసలు JOIN.

ప్రాథమిక కీ ఇతర కీలను ప్రకటించే అవకాశాన్ని భర్తీ చేయదు. అదే సమయంలో, ఏ కీని ప్రాథమికంగా కేటాయించనట్లయితే, పట్టిక ఇప్పటికీ బాగా పని చేస్తుంది. మెరుపు, ఏ సందర్భంలో, మీరు సమ్మె కాదు.

5.3 సహజ కీలను కనుగొనడం

పైన చర్చించిన కీలను "సహజమైనది" అని పిలుస్తారు, ఎందుకంటే అవి తమలో తాము ఆసక్తికరంగా ఉండే మోడల్ చేయబడిన వస్తువు యొక్క లక్షణాలు, ఎవరూ వాటి నుండి కీని తయారు చేయకూడదనుకున్నప్పటికీ.

సాధ్యమయ్యే సహజ కీల కోసం పట్టికను పరిశీలిస్తున్నప్పుడు గుర్తుంచుకోవలసిన మొదటి విషయం ఏమిటంటే చాలా తెలివిగా ఉండకూడదని ప్రయత్నించడం. StackExchangeలో వినియోగదారు sqlvogel క్రింది సలహాను అందిస్తుంది:

కొంతమంది వ్యక్తులు "సహజమైన" కీని ఎంచుకోవడంలో ఇబ్బంది పడతారు ఎందుకంటే వారు నిర్దిష్ట కీ ప్రత్యేకంగా ఉండని ఊహాజనిత పరిస్థితులతో ముందుకు వస్తారు. పని యొక్క అర్థం వారికి అర్థం కాలేదు. కీ యొక్క అర్థం ఏమిటంటే, ఏ సమయంలోనైనా లక్షణాలు తప్పనిసరిగా ఉండాలి మరియు నిర్దిష్ట పట్టికలో ఎల్లప్పుడూ ప్రత్యేకంగా ఉండే నియమాన్ని నిర్వచించడం. పట్టిక నిర్దిష్ట మరియు బాగా అర్థం చేసుకున్న సందర్భంలో ("విషయ ప్రాంతం" లేదా "ఉపన్యాస ప్రాంతం"లో) డేటాను కలిగి ఉంటుంది మరియు నిర్దిష్ట ప్రాంతంలో పరిమితిని వర్తింపజేయడం మాత్రమే అర్థం.

అందుబాటులో ఉన్న విలువలతో నిలువు వరుస ప్రత్యేకంగా ఉన్నప్పుడు కీలకమైన పరిమితిని ప్రవేశపెట్టడం అవసరమని ప్రాక్టీస్ చూపిస్తుంది మరియు అవకాశం ఉన్న సందర్భాల్లో అలాగే ఉంటుంది. మరియు అవసరమైతే, పరిమితిని తీసివేయవచ్చు (ఇది మిమ్మల్ని బాధపెడితే, క్రింద మేము కీలక స్థిరత్వం గురించి మాట్లాడుతాము.)

ఉదాహరణకు, అభిరుచి గల క్లబ్ సభ్యుల డేటాబేస్ రెండు నిలువు వరుసలలో ప్రత్యేకతను కలిగి ఉండవచ్చు - first_name, last_name. తక్కువ మొత్తంలో డేటాతో, నకిలీలు అసంభవం, మరియు నిజమైన సంఘర్షణ తలెత్తే ముందు, అటువంటి కీని ఉపయోగించడం చాలా సహేతుకమైనది.

డేటాబేస్ పెరుగుతుంది మరియు సమాచార పరిమాణం పెరుగుతుంది కాబట్టి, సహజ కీని ఎంచుకోవడం మరింత కష్టమవుతుంది. మేము నిల్వ చేసే డేటా బాహ్య వాస్తవికత యొక్క సరళీకరణ మరియు ప్రపంచంలోని వస్తువులను వేరుచేసే కొన్ని అంశాలను కలిగి ఉండదు, అవి కాలక్రమేణా మారే వాటి కోఆర్డినేట్‌లు వంటివి. ఒక వస్తువుకు ఏదైనా కోడ్ లేకపోతే, మీరు వాటి ప్రాదేశిక అమరిక లేదా బరువు లేదా ప్యాకేజింగ్‌లో స్వల్ప వ్యత్యాసాలను కాకుండా రెండు డబ్బాల పానీయం లేదా రెండు బాక్సుల ఓట్‌మీల్‌ను ఎలా చెప్పగలరు?

అందుకే ప్రామాణీకరణ సంస్థలు ఉత్పత్తులకు విలక్షణమైన మార్కులను సృష్టిస్తాయి మరియు వర్తిస్తాయి. వాహనాలు వెహికల్ ఐడెంటిఫికేషన్ నంబర్ (VIN) తో స్టాంప్ చేయబడతాయి , పుస్తకాలు ISBN లతో ముద్రించబడతాయి మరియు ఆహార ప్యాకేజింగ్‌లో UPCలు ఉంటాయి . ఈ సంఖ్యలు సహజంగా కనిపించడం లేదని మీరు అభ్యంతరం చెప్పవచ్చు. కాబట్టి నేను వాటిని సహజ కీలు అని ఎందుకు పిలుస్తాను?

డేటాబేస్‌లోని ప్రత్యేక లక్షణాల సహజత్వం లేదా కృత్రిమత బాహ్య ప్రపంచానికి సంబంధించి ఉంటుంది. ప్రమాణాల సంస్థ లేదా ప్రభుత్వ ఏజెన్సీలో సృష్టించబడినప్పుడు కృత్రిమంగా ఉండే కీ మనకు సహజంగా మారుతుంది, ఎందుకంటే ఇది మొత్తం ప్రపంచంలో ఒక ప్రమాణంగా మారుతుంది మరియు / లేదా వస్తువులపై ముద్రించబడుతుంది.

కరెన్సీలు, భాషలు, ఆర్థిక సాధనాలు, రసాయనాలు మరియు వైద్య రోగనిర్ధారణలతో సహా వివిధ విషయాల కోసం అనేక పరిశ్రమ, పబ్లిక్ మరియు అంతర్జాతీయ ప్రమాణాలు ఉన్నాయి. సహజ కీలుగా తరచుగా ఉపయోగించే కొన్ని విలువలు ఇక్కడ ఉన్నాయి:

• ISO 3166 దేశం కోడ్‌లు
• ISO 639 భాషా కోడ్‌లు
• ISO 4217 ప్రకారం కరెన్సీ కోడ్‌లు
• స్టాక్ చిహ్నాలు ISIN
• UPC/EAN, VIN, GTIN, ISBN
• లాగిన్ పేర్లు
• ఇమెయిల్ చిరునామాలు
• గది సంఖ్యలు
• నెట్వర్క్ Mac చిరునామా
• అక్షాంశం, భూమి యొక్క ఉపరితలంపై బిందువుల రేఖాంశం

సాధ్యమైనప్పుడల్లా మరియు సహేతుకమైనప్పుడు కీలను ప్రకటించాలని నేను సిఫార్సు చేస్తున్నాను, ఒక్కో టేబుల్‌కి బహుళ కీలు కూడా ఉండవచ్చు. కానీ పైన పేర్కొన్న అన్నింటికీ మినహాయింపులు ఉండవచ్చని గుర్తుంచుకోండి.

• ప్రతి ఒక్కరికి ఇమెయిల్ చిరునామా ఉండదు, అయితే ఇది కొన్ని డేటాబేస్ పరిస్థితులలో ఆమోదయోగ్యమైనది. అలాగే, వ్యక్తులు తమ ఇమెయిల్ చిరునామాలను ఎప్పటికప్పుడు మార్చుకుంటారు. (తర్వాత కీలక స్థిరత్వంపై మరింత సమాచారం.)
• ISIN స్టాక్ చిహ్నాలు కాలానుగుణంగా మారుతూ ఉంటాయి, ఉదాహరణకు, GOOG మరియు GOOGL చిహ్నాలు సంస్థ యొక్క పునర్వ్యవస్థీకరణను Google నుండి ఆల్ఫాబెట్‌కు సరిగ్గా వివరించలేదు. కొన్నిసార్లు గందరగోళం ఏర్పడవచ్చు, TWTR మరియు TWTRQ లాగా, కొంతమంది పెట్టుబడిదారులు Twitter IPO సమయంలో పొరపాటున రెండోదాన్ని కొనుగోలు చేశారు.
• సోషల్ సెక్యూరిటీ నంబర్‌లు US పౌరులు మాత్రమే ఉపయోగించబడతాయి, గోప్యతా పరిమితులను కలిగి ఉంటాయి మరియు మరణం తర్వాత మళ్లీ ఉపయోగించబడతాయి. అదనంగా, పత్రాల దొంగతనం తర్వాత, ప్రజలు కొత్త నంబర్లను పొందవచ్చు. చివరగా, ఒకే సంఖ్య ఒక వ్యక్తిని మరియు ఆదాయపు పన్ను గుర్తింపుదారుని రెండింటినీ గుర్తించగలదు.
• నగరాలకు జిప్ కోడ్‌లు సరైన ఎంపిక కాదు. కొన్ని నగరాలు సాధారణ సూచికను కలిగి ఉంటాయి లేదా దీనికి విరుద్ధంగా, ఒక నగరంలో అనేక సూచికలు ఉన్నాయి.

5.4 కృత్రిమ కీలు

కీ ప్రతి అడ్డు వరుసలో ప్రత్యేకమైన విలువలతో కూడిన నిలువు వరుస అయినందున, దానిని సృష్టించడానికి ఒక మార్గం మోసం చేయడం - మీరు ప్రతి అడ్డు వరుసలో కల్పిత ప్రత్యేక విలువలను వ్రాయవచ్చు. ఇవి కృత్రిమ కీలు: డేటా లేదా వస్తువులను సూచించడానికి ఉపయోగించే కోడ్ కనుగొనబడింది.

కోడ్ డేటాబేస్ నుండే రూపొందించబడటం చాలా ముఖ్యం మరియు డేటాబేస్ యొక్క వినియోగదారులకు తప్ప ఎవరికీ తెలియదు. ఇది కృత్రిమ కీలను ప్రామాణిక సహజ కీల నుండి వేరు చేస్తుంది.

సహజ కీలు పట్టికలోని నకిలీ లేదా అస్థిరమైన అడ్డు వరుసల నుండి రక్షించే ప్రయోజనాన్ని కలిగి ఉన్నప్పటికీ, కృత్రిమ కీలు ఉపయోగపడతాయి ఎందుకంటే అవి మానవులు లేదా ఇతర సిస్టమ్‌లు అడ్డు వరుసను సూచించడాన్ని సులభతరం చేస్తాయి మరియు అవి శోధనలను వేగవంతం చేస్తాయి మరియు అవి ఉపయోగించనందున చేరతాయి. స్ట్రింగ్ (లేదా బహుళ కాలమ్) పోలికలు కీలు.

సర్రోగేట్స్

కృత్రిమ కీలు యాంకర్‌లుగా ఉపయోగించబడతాయి - నియమాలు మరియు నిలువు వరుసలు ఎలా మారినప్పటికీ, ఒక అడ్డు వరుసను ఎల్లప్పుడూ అదే విధంగా గుర్తించవచ్చు. ఈ ప్రయోజనం కోసం ఉపయోగించే కృత్రిమ కీని "సర్రోగేట్ కీ" అని పిలుస్తారు మరియు ప్రత్యేక శ్రద్ధ అవసరం. మేము దిగువ సర్రోగేట్‌లను పరిశీలిస్తాము.

డేటాబేస్ వెలుపలి వరుసను సూచించడానికి నాన్-సరోగేట్ కృత్రిమ కీలు ఉపయోగపడతాయి. ఒక కృత్రిమ కీ ఒక డేటా లేదా ఆబ్జెక్ట్‌ని క్లుప్తంగా గుర్తిస్తుంది: దానిని URLగా పేర్కొనవచ్చు, ఇన్‌వాయిస్‌కి జోడించవచ్చు, ఫోన్ ద్వారా నిర్దేశించవచ్చు, బ్యాంక్ నుండి పొందవచ్చు లేదా లైసెన్స్ ప్లేట్‌పై ముద్రించవచ్చు. (కారు లైసెన్స్ ప్లేట్ మనకు సహజమైన కీ, కానీ ప్రభుత్వం కృత్రిమ కీలాగా రూపొందించబడింది.)

అక్షరదోషాలు మరియు లోపాలను తగ్గించడానికి సాధ్యమయ్యే ప్రసార సాధనాలను పరిగణనలోకి తీసుకుని సింథటిక్ కీలను ఎంచుకోవాలి. కీని మాట్లాడవచ్చు, ప్రింట్ చేయవచ్చు, SMS ద్వారా పంపవచ్చు, చేతితో వ్రాసి చదవవచ్చు, కీబోర్డ్ నుండి టైప్ చేయవచ్చు మరియు URLలో పొందుపరచవచ్చు. అదనంగా, క్రెడిట్ కార్డ్ నంబర్‌ల వంటి కొన్ని కృత్రిమ కీలు చెక్‌సమ్‌ని కలిగి ఉంటాయి, తద్వారా కొన్ని లోపాలు సంభవించినట్లయితే, వాటిని కనీసం గుర్తించవచ్చు.

ఉదాహరణలు:

• US లైసెన్స్ ప్లేట్‌ల కోసం, O మరియు 0 వంటి అస్పష్టమైన అక్షరాలను ఉపయోగించడం గురించి నియమాలు ఉన్నాయి.
• వైద్యుల చేతివ్రాత దృష్ట్యా ఆసుపత్రులు మరియు ఫార్మసీలు ప్రత్యేకించి జాగ్రత్తగా ఉండాలి.
• మీరు వచన సందేశం ద్వారా నిర్ధారణ కోడ్‌ను పంపుతున్నారా? GSM 03.38 అక్షర సమితిని దాటి వెళ్లవద్దు.
• బేస్64 వలె కాకుండా, ఏకపక్ష బైట్ డేటాను ఎన్‌కోడ్ చేస్తుంది, పాత కంప్యూటర్ సిస్టమ్‌లను ఉపయోగించడానికి మరియు నిర్వహించడానికి మానవులకు అనుకూలమైన పరిమిత అక్షర సమితిని Base32 ఉపయోగిస్తుంది.
• ప్రోక్వింట్లు చదవగలిగేవి, వ్రాయగలిగేవి మరియు ఉచ్చరించదగినవి. ఇవి నిస్సందేహంగా అర్థం చేసుకున్న హల్లులు మరియు అచ్చుల యొక్క PRO-నౌన్కేబుల్ QUINT-అప్లెట్‌లు.

మీరు మీ కృత్రిమ కీని ప్రపంచానికి పరిచయం చేసిన వెంటనే, ప్రజలు వింతగా ప్రత్యేక శ్రద్ధ ఇవ్వడం ప్రారంభిస్తారని గుర్తుంచుకోండి. "దొంగలు" లైసెన్స్ ప్లేట్‌లను లేదా అప్రసిద్ధ ఆటోమేటెడ్ శాప జనరేటర్‌గా మారిన ఉచ్చారణ ఐడెంటిఫైయర్‌లను సృష్టించే సిస్టమ్‌ను చూడండి.

మనం సంఖ్యా కీలకే పరిమితమైనా, పదమూడవ అంతస్థు వంటి నిషేధాలు ఉన్నాయి. ప్రోక్వింట్లు ప్రతి మాట్లాడే అక్షరానికి అధిక సాంద్రత కలిగిన సమాచారాన్ని కలిగి ఉన్నప్పటికీ, సంఖ్యలు అనేక విధాలుగా బాగానే ఉంటాయి: URLలు, పిన్-కీబోర్డ్‌లు మరియు చేతితో వ్రాసిన గమనికలు, గ్రహీతకి తెలిసినంత వరకు కీ సంఖ్యలు మాత్రమే.

అయితే, దయచేసి మీరు పబ్లిక్ న్యూమరిక్ కీలలో సీక్వెన్షియల్ క్రమాన్ని ఉపయోగించరాదని గుర్తుంచుకోండి, ఇది వనరులను (/videos/1.mpeg, /videos/2.mpeg, మరియు మొదలైనవి) మరియు సంఖ్య గురించి సమాచారాన్ని లీక్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. సమాచారం. సంఖ్యల శ్రేణిపై ఫీస్టెల్ నెట్‌ను సూపర్‌ఇంపోజ్ చేయండి మరియు సంఖ్యల క్రమాన్ని దాచేటప్పుడు ప్రత్యేకతను కాపాడుకోండి.

అదనపు కీలను ప్రకటించడానికి వ్యతిరేకంగా ఉన్న ఏకైక వాదన ఏమిటంటే, ప్రతి కొత్తది దానితో పాటు మరొక ప్రత్యేక సూచికను తీసుకువస్తుంది మరియు పట్టికకు వ్రాసే ఖర్చును పెంచుతుంది. వాస్తవానికి, డేటా యొక్క ఖచ్చితత్వం మీకు ఎంత ముఖ్యమైనది అనే దానిపై ఆధారపడి ఉంటుంది, కానీ, చాలా మటుకు, కీలు ఇప్పటికీ ప్రకటించబడాలి.

ఏదైనా ఉంటే అనేక కృత్రిమ కీలను ప్రకటించడం కూడా విలువైనదే. ఉదాహరణకు, ఒక సంస్థలో ఉద్యోగ అభ్యర్థులు (దరఖాస్తుదారులు) మరియు ఉద్యోగులు (ఉద్యోగులు) ఉంటారు. ప్రతి ఉద్యోగి ఒకప్పుడు అభ్యర్థి, మరియు వారి స్వంత ఐడెంటిఫైయర్ ద్వారా అభ్యర్థులను సూచిస్తారు, అది ఉద్యోగి కీ కూడా అయి ఉండాలి. మరొక ఉదాహరణ, మీరు ఎంప్లాయీస్‌లో ఉద్యోగి ఐడి మరియు లాగిన్ పేరును రెండు కీలుగా సెట్ చేయవచ్చు.

5.5 సర్రోగేట్ కీలు

ఇప్పటికే చెప్పినట్లుగా, కృత్రిమ కీ యొక్క ముఖ్యమైన రకాన్ని "సర్రోగేట్ కీ" అంటారు. ఇది ఇతర కృత్రిమ కీల వలె సంక్షిప్తంగా మరియు పాస్ చేయవలసిన అవసరం లేదు, కానీ ఎల్లప్పుడూ స్ట్రింగ్‌ను గుర్తించే అంతర్గత లేబుల్‌గా ఉపయోగించబడుతుంది. ఇది SQLలో ఉపయోగించబడుతుంది, కానీ అప్లికేషన్ దానిని స్పష్టంగా యాక్సెస్ చేయదు.

మీకు PostgreSQL యొక్క సిస్టమ్ నిలువు వరుసలు బాగా తెలిసి ఉంటే, మీరు సర్రోగేట్‌లను దాదాపు డేటాబేస్ ఇంప్లిమెంటేషన్ పారామీటర్‌గా భావించవచ్చు (ctid వంటివి), అయితే, ఇది ఎప్పటికీ మారదు. సర్రోగేట్ విలువ ప్రతి అడ్డు వరుసకు ఒకసారి ఎంపిక చేయబడుతుంది మరియు ఆ తర్వాత ఎప్పటికీ మారదు.

ON UPDATE RESTRICTసర్రోగేట్ కీలు విదేశీ కీల వలె గొప్పవి మరియు సర్రోగేట్ యొక్క మార్పులేని దానికి సరిపోలడానికి క్యాస్కేడింగ్ పరిమితులు తప్పనిసరిగా పేర్కొనబడాలి .

మరోవైపు, ON UPDATE CASCADEగరిష్ట సౌలభ్యాన్ని అందించడానికి పబ్లిక్‌గా షేర్ చేయబడిన కీలకు విదేశీ కీలను తో గుర్తు పెట్టాలి. క్యాస్కేడింగ్ అప్‌డేట్ పరిసర లావాదేవీల మాదిరిగానే ఐసోలేషన్ స్థాయిలో నడుస్తుంది, కాబట్టి కాన్‌కరెన్సీ సమస్యల గురించి చింతించకండి - మీరు కఠినమైన ఐసోలేషన్ స్థాయిని ఎంచుకుంటే డేటాబేస్ బాగానే ఉంటుంది.

సర్రోగేట్ కీలను "సహజంగా" చేయవద్దు. మీరు సర్రోగేట్ కీ యొక్క విలువను తుది వినియోగదారులకు చూపిన తర్వాత లేదా అధ్వాన్నంగా ఉంటే, ఆ విలువతో (ముఖ్యంగా లుకప్ ద్వారా) పని చేయనివ్వండి, మీరు కీకి సమర్థవంతంగా విలువ ఇస్తున్నారు. అప్పుడు మీ డేటాబేస్ నుండి చూపబడిన కీ వేరొకరి డేటాబేస్లో సహజ కీగా మారవచ్చు.

ట్రాన్స్‌మిషన్ కోసం ప్రత్యేకంగా రూపొందించబడిన ఇతర కృత్రిమ కీలను ఉపయోగించమని బాహ్య వ్యవస్థలను బలవంతం చేయడం వలన, సర్రోగేట్‌లతో అంతర్గత రెఫరెన్షియల్ సమగ్రతను కొనసాగిస్తూ, మారుతున్న అవసరాలకు అనుగుణంగా ఆ కీలను మార్చడానికి మాకు వీలు కల్పిస్తుంది.

స్వీయ-పెంపు INT/BIGINT

సర్రోగేట్ కీల కోసం అత్యంత సాధారణ ఉపయోగం ఆటో-ఇంక్రిమెంటింగ్ "బిగ్‌సీరియల్" కాలమ్ , దీనిని IDENTITY అని కూడా పిలుస్తారు . (వాస్తవానికి, PostgreSQL 10 ఇప్పుడు IDENTITY నిర్మాణానికి మద్దతు ఇస్తుంది, ఒరాకిల్ వలె, పట్టికను సృష్టించు చూడండి.)

అయినప్పటికీ, సర్రోగేట్ కీల కోసం ఆటో-ఇంక్రిమెంటింగ్ పూర్ణాంకం సరైన ఎంపిక కాదని నేను నమ్ముతున్నాను. ఈ అభిప్రాయం జనాదరణ పొందలేదు, కాబట్టి నేను వివరిస్తాను.

సీరియల్ కీల యొక్క ప్రతికూలతలు:

• అన్ని సీక్వెన్సులు 1 వద్ద ప్రారంభమై, క్రమంగా పెరిగితే, వివిధ పట్టికల నుండి అడ్డు వరుసలు ఒకే కీలక విలువలను కలిగి ఉంటాయి. ఈ ఐచ్ఛికం అనువైనది కాదు, ఇప్పటికీ పట్టికలలో కీల యొక్క విభజిత సెట్‌లను ఉపయోగించడం ఉత్తమం, కాబట్టి ఉదాహరణకు, ప్రశ్నలు అనుకోకుండా స్థిరాంకాలను గందరగోళానికి గురిచేయవు JOINమరియు ఊహించని ఫలితాలను అందించవు. (ప్రత్యామ్నాయంగా, ఖండనలు లేవని నిర్ధారించడానికి, వివిధ ప్రైమ్‌ల గుణకాల నుండి ప్రతి క్రమాన్ని నిర్మించవచ్చు, కానీ ఇది చాలా శ్రమతో కూడుకున్నది.)
• nextval() నేటి పంపిణీ చేయబడిన SQLలో క్రమాన్ని రూపొందించడానికి చేసిన కాల్ మొత్తం సిస్టమ్ స్కేలింగ్ సరిగా లేదు.
• సీక్వెన్షియల్ కీలను ఉపయోగించిన డేటాబేస్ నుండి డేటాను వినియోగించడం వలన వైరుధ్యాలు ఏర్పడతాయి ఎందుకంటే సిస్టమ్‌లలో సీక్వెన్షియల్ విలువలు ప్రత్యేకంగా ఉండవు.
• తాత్విక దృక్కోణం నుండి, సంఖ్యల వరుస పెరుగుదల పాత వ్యవస్థలతో సంబంధం కలిగి ఉంటుంది, దీనిలో పంక్తుల క్రమం సూచించబడుతుంది. మీరు ఇప్పుడు అడ్డు వరుసలను ఆర్డర్ చేయాలనుకుంటే, టైమ్‌స్టాంప్ కాలమ్‌తో లేదా మీ డేటాలో అర్ధమయ్యే దానితో స్పష్టంగా చేయండి. లేకపోతే, మొదటి సాధారణ రూపం ఉల్లంఘించబడుతుంది.
• బలహీనమైన కారణం, కానీ ఈ చిన్న ఐడెంటిఫైయర్‌లు ఎవరికైనా చెప్పడానికి ఉత్సాహం చూపుతున్నాయి.

UUID

మరొక ఎంపికను చూద్దాం: యాదృచ్ఛిక నమూనా ప్రకారం ఉత్పత్తి చేయబడిన పెద్ద పూర్ణాంకాలను (128-బిట్) ఉపయోగించడం. అటువంటి విశ్వవ్యాప్తంగా ప్రత్యేకమైన ఐడెంటిఫైయర్‌లను (UUIDలు) రూపొందించడానికి అల్గారిథమ్‌లు ఒకే సమయంలో రెండు వేర్వేరు ప్రాసెసర్‌లపై నడుస్తున్నప్పుడు కూడా ఒకే విలువను రెండుసార్లు ఎంచుకోవడానికి చాలా తక్కువ సంభావ్యతను కలిగి ఉంటాయి.

అలాంటప్పుడు, UUIDలు సర్రోగేట్ కీలుగా ఉపయోగించడానికి సహజమైన ఎంపికగా అనిపిస్తాయి, కాదా? మీరు అడ్డు వరుసలను ప్రత్యేకమైన రీతిలో లేబుల్ చేయాలనుకుంటే, ఏదీ ప్రత్యేకమైన లేబుల్‌ను అధిగమించదు!

కాబట్టి అందరూ వాటిని PostgreSQLలో ఎందుకు ఉపయోగించడం లేదు? దీనికి అనేక కల్పిత కారణాలు ఉన్నాయి మరియు ఒక తార్కికంగా పని చేయవచ్చు మరియు నా పాయింట్‌ను వివరించడానికి నేను బెంచ్‌మార్క్‌లను ప్రదర్శిస్తాను.

మొదట, నేను చాలా అసహ్యకరమైన కారణాల గురించి మాట్లాడుతాను. కొంతమంది వ్యక్తులు UUIDలు స్ట్రింగ్‌లుగా భావిస్తారు ఎందుకంటే అవి సంప్రదాయ హెక్సాడెసిమల్ సంజ్ఞామానంలో డాష్‌తో వ్రాయబడ్డాయి: 5bd68e64-ff52-4f54-ace4-3cd9161c8b7f. నిజానికి, కొన్ని డేటాబేస్‌లు కాంపాక్ట్ (128-బిట్) uuid రకాన్ని కలిగి ఉండవు, అయితే PostgreSQL రెండు పరిమాణాన్ని కలిగి ఉంటుంది మరియు కలిగి ఉంటుంది bigint, అనగా డేటాబేస్‌లోని ఇతర సమాచారంతో పోలిస్తే, ఓవర్‌హెడ్ చాలా తక్కువగా ఉంటుంది.

UUIDలు కూడా గజిబిజిగా ఉన్నాయని అన్యాయంగా ఆరోపించబడ్డాయి, అయితే వాటిని ఎవరు ఉచ్చరిస్తారు, టైప్ చేస్తారు లేదా చదువుతారు? కృత్రిమ కీలను చూపడం సమంజసమని మేము చెప్పాము, అయితే ఎవరూ (నిర్వచనం ప్రకారం) సర్రోగేట్ UUIDని చూడకూడదు. సిస్టమ్‌ను డీబగ్ చేయడానికి psqlలో SQL ఆదేశాలను అమలు చేసే డెవలపర్ ద్వారా UUID వ్యవహరించే అవకాశం ఉంది, కానీ దాని గురించి. మరియు డెవలపర్ వారు ఇచ్చినట్లయితే, మరింత అనుకూలమైన కీలను ఉపయోగించి స్ట్రింగ్‌లను కూడా సూచించవచ్చు.

UUIDలతో ఉన్న అసలైన సమస్య ఏమిటంటే, రైట్-ఎహెడ్ లాగ్ (WAL)కి పూర్తి పేజీ వ్రాతల కారణంగా అధిక యాదృచ్ఛిక విలువలు యాంప్లిఫికేషన్‌ను వ్రాయడానికి దారితీస్తాయి . అయితే, పనితీరు క్షీణత వాస్తవానికి UUID జనరేషన్ అల్గారిథమ్‌పై ఆధారపడి ఉంటుంది.

రైట్ యాంప్లిఫికేషన్‌ను కొలుద్దాం . నిజానికి, సమస్య పాత ఫైల్ సిస్టమ్‌లలో ఉంది. PostgreSQL డిస్క్‌కి వ్రాసినప్పుడు, అది డిస్క్‌లోని "పేజీ"ని మారుస్తుంది. మీరు కంప్యూటర్ పవర్‌ను ఆపివేసినట్లయితే, చాలా ఫైల్ సిస్టమ్‌లు డిస్క్‌లో డేటా సురక్షితంగా నిల్వ చేయబడే ముందు విజయవంతంగా వ్రాయబడిందని నివేదిస్తుంది. PostgreSQL అటువంటి చర్యను పూర్తి చేసినట్లు గ్రహిస్తే, తదుపరి సిస్టమ్ బూట్ సమయంలో డేటాబేస్ పాడైపోతుంది.

PostgreSQL కొనసాగింపును అందించడానికి చాలా ఆపరేటింగ్ సిస్టమ్‌లు/ఫైల్‌సిస్టమ్‌లు/డిస్క్ కాన్ఫిగరేషన్‌లను విశ్వసించనందున, డేటాబేస్ మారిన డిస్క్ పేజీ యొక్క పూర్తి స్థితిని రైట్-ఎహెడ్ లాగ్‌లో సేవ్ చేస్తుంది, ఇది సాధ్యమయ్యే క్రాష్ నుండి కోలుకోవడానికి ఉపయోగపడుతుంది. UUIDల వంటి అత్యంత యాదృచ్ఛిక విలువలను సూచిక చేయడం సాధారణంగా విభిన్న డిస్క్ పేజీల సమూహాన్ని కలిగి ఉంటుంది మరియు ప్రతి కొత్త ఎంట్రీ కోసం పూర్తి పేజీ పరిమాణం (సాధారణంగా 4 లేదా 8 KB) WALకి వ్రాయబడుతుంది. ఇది పూర్తి పేజీ వ్రాయడం అని పిలవబడేది (పూర్తి పేజీ వ్రాయడం, FPW).

కొన్ని UUID జనరేషన్ అల్గారిథమ్‌లు (Twitter యొక్క "స్నోఫ్లేక్" లేదా uuid_generate_v1() వంటివి PostgreSQL యొక్క uuid-osp ఎక్స్‌టెన్షన్‌లో) ప్రతి మెషీన్‌లో మార్పు లేకుండా పెరుగుతున్న విలువలను ఉత్పత్తి చేస్తాయి. ఈ విధానం తక్కువ డిస్క్ పేజీలలో వ్రాతలను ఏకీకృతం చేస్తుంది మరియు FPWని తగ్గిస్తుంది.

5.6 తీర్మానాలు మరియు సిఫార్సులు

ఇప్పుడు మేము వివిధ రకాల కీలు మరియు వాటి ఉపయోగాలను చూశాము, వాటిని మీ డేటాబేస్‌లలో ఉపయోగించడం కోసం నేను నా సిఫార్సులను జాబితా చేయాలనుకుంటున్నాను.

ప్రతి టేబుల్ కోసం:

• అన్ని సహజ కీలను నిర్వచించండి మరియు ప్రకటించండి.
• డిఫాల్ట్ విలువతో UUID<table_name>_id రకం సర్రోగేట్ కీని సృష్టించండి . మీరు దీన్ని ప్రాథమిక కీగా కూడా గుర్తించవచ్చు. మీరు ఈ ఐడెంటిఫైయర్‌కు పట్టిక పేరును జోడిస్తే, ఇది సులభతరం చేస్తుంది , అనగా. బదులుగా స్వీకరించండి . ఈ కీని క్లయింట్‌లకు పంపవద్దు మరియు డేటాబేస్ వెలుపల దాన్ని బహిర్గతం చేయవద్దు.uuid_generate_v1()JOINJOIN foo USING (bar_id)JOIN foo ON (foo.bar_id = bar.id)
• గుండా వెళ్ళే ఇంటర్మీడియట్ పట్టికల కోసం JOIN, అన్ని విదేశీ కీ నిలువు వరుసలను ఒకే మిశ్రమ ప్రాథమిక కీగా ప్రకటించండి.
• ఐచ్ఛికంగా, URL లేదా ఇతర స్ట్రింగ్ సూచన సూచనలలో ఉపయోగించగల కృత్రిమ కీని జోడించండి. స్వీయ-పెంపు పూర్ణాంకాలను మాస్క్ చేయడానికి Feistel గ్రిడ్ లేదా pg_hashids ఉపయోగించండి .
• ON UPDATE RESTRICTవిదేశీ కీలుగా మరియు కృత్రిమ విదేశీ కీల కోసం సర్రోగేట్ UUIDలను ఉపయోగించి క్యాస్కేడింగ్ పరిమితిని పేర్కొనండి ON UPDATE CASCADE. మీ స్వంత లాజిక్ ఆధారంగా సహజ కీలను ఎంచుకోండి.

ఈ విధానం సహజ కీలను అనుమతించేటప్పుడు మరియు రక్షించేటప్పుడు అంతర్గత కీల స్థిరత్వాన్ని నిర్ధారిస్తుంది. అదనంగా, కనిపించే కృత్రిమ కీలు దేనికీ జోడించబడవు. ప్రతిదీ సరిగ్గా అర్థం చేసుకున్న తరువాత, మీరు "ప్రాధమిక కీలు" పై మాత్రమే వేలాడదీయలేరు మరియు కీలను ఉపయోగించే అన్ని అవకాశాలను ఉపయోగించలేరు.