प्राथमिक कुंजी के रूप में GUID - ऑफ़लाइन OLTP

Question

हम आमतौर पर OLTP (सोच: क्रय सिस्टम) वाले एप्लिकेशन को डिज़ाइन करने पर काम कर रहे हैं। हालांकि, विशेष रूप से यह आवश्यक है कि कुछ उपयोगकर्ता ऑफ़लाइन हों, इसलिए उन्हें अपनी मशीन पर डीबी डाउनलोड करने, उस पर काम करने और फिर लैन पर आने के बाद सिंक करने में सक्षम होना चाहिए।

मुझे यह ध्यान रखना होगा कि मुझे पता है कि यह पहले किया गया है, मुझे इस विशेष मॉडल के साथ अनुभव नहीं है।

एक विचार मैंने सोचा था कि GUIDs को टेबल कुंजी के रूप में उपयोग कर रहा था। तो उदाहरण के लिए, एक खरीद आदेश में एक संख्या (ऑटो-न्यूमेरिक) नहीं होगी बल्कि इसके बजाय एक GUID होगा, ताकि प्रत्येक ऑफलाइन क्लाइंट उनको उत्पन्न कर सके, और जब मैं डीबी से कनेक्ट होता हूं तो मुझे संघर्ष नहीं होता है।

क्या किसी कारण से यह बुरा विचार है? GUID कुंजी के माध्यम से इन तालिकाओं तक पहुंच धीमी हो जाएगी?

क्या आपको इन प्रकार के सिस्टम के साथ अनुभव हुआ है? आपने इस समस्या को कैसे हल किया है?

धन्यवाद!
डैनियल

Answer 1

प्राथमिक कुंजी के रूप में गइड्स का उपयोग स्वीकार्य है और उसी कारण से आप एक मानक मानक अभ्यास मानते हैं उन्हें। उन्हें अधिक उपयोग किया जा सकता है जो चीजों को डीबग और प्रबंधित करने के लिए थोड़ा कठिन बना सकता है, इसलिए यदि संभव हो तो उन्हें कोड तालिकाओं और अन्य संदर्भ डेटा से बाहर रखने का प्रयास करें।

जो चीज़ आपको स्वयं को चिंता करने के लिए है वह मानव पठनीय पहचानकर्ता है। लोगों द्वारा ग्रिड का आदान-प्रदान नहीं किया जा सकता है - क्या आप कल्पना कर सकते हैं कि फोन पर आपके ऑर्डर नंबर की पुष्टि करने की कोशिश कर रहा है अगर यह एक गाइड है? तो एक ऑफ़लाइन परिदृश्य में आपको अभी भी कुछ उत्पन्न करना होगा - एक प्रकाशक (वर्कस्टेशन/उपयोगकर्ता) आईडी और कुछ अनुक्रम संख्या की तरह, ताकि आदेश संख्या 123-5678 हो -।

हालांकि यह अनुक्रमिक संख्या होने की व्यावसायिक आवश्यकताओं को पूरा नहीं कर सकता है। वास्तव में नियामक आवश्यकताएं हो सकती हैं और प्रभावित हो सकती हैं - कुछ नियम (एसओएक्स शायद) की आवश्यकता है कि चालान संख्या अनुक्रमिक हों। ऐसे मामलों में यह एक प्रकार का प्रोफार्मा नंबर उत्पन्न करने के लिए असफल हो सकता है जिसे सिस्टम सिंक्रनाइज़ करते समय बाद में तय किया जाता है। आप ऑर्डरआईड (गइड), ऑर्डरनो (इंट), प्रोफोमा ऑर्डर एनओ (वर्कर) वाले टेबल के साथ उतर सकते हैं - कुछ जटिलता रेंग सकती है।

कम से कम प्राथमिक कुंजी के रूप में guids होने का मतलब है कि आपको पूरी तरह से करने की ज़रूरत नहीं है जब सिंक अंततः होता है तो बहुत सारे कैस्केडिंग अपडेट - आप बस मानव पठनीय संख्या को अपडेट करते हैं।

Answer 2

GUIDs निश्चित रूप से धीमी हो जाएगा (और अधिक स्मृति का उपयोग) मानक पूर्णांक कुंजी से है, लेकिन या नहीं, वह यह है कि एक मुद्दा लोड आपके सिस्टम देखेंगे के प्रकार पर निर्भर करेगा। आपके बैकएंड डीबी के आधार पर इंडेक्सिंग गाइड फ़ील्ड के साथ समस्या हो सकती है।

गाइड का उपयोग करने से समस्याओं की पूरी कक्षा सरल हो जाती है, लेकिन आप इसके लिए भुगतान करते हैं, भाग प्रदर्शन और डिबग्बिलिटी - उन परीक्षण प्रश्नों में टाइपिंग गाइड पुराने वास्तविक तेज़ हो जाएंगे!

Answer 3

यह GUID का एक बिल्कुल अच्छा उपयोग है। आईएनटी पर जीआईआईडी और मामूली आकार अंतर (16 बाइट बनाम 4 बाइट्स) के साथ काम करने में एकमात्र ड्रॉ बैक थोड़ी जटिलता होगी।

मुझे नहीं लगता कि इनमें से कोई भी एक बड़ा सौदा है।

Answer 4

बैकएंड SQL सर्वर 2005
दृश्यपटल/आवेदन तर्क

नेट की जाएगी GUIDs इसके अलावा हो जाएगा, तो आप "मर्ज" ऐसा होता है जब ऑफ़लाइन कंप्यूटर नए डेटा सिंक करता है को हल करने के लिए अन्य तरीकों के बारे में सोच सकते हैं केंद्रीय डेटाबेस में वापस?
मेरा मतलब है, यदि चाबियां आईएनटी हैं, तो मूल रूप से आयात करते समय मुझे सबकुछ किराए पर लेना होगा। GUID मुझे उसमें छोड़ देंगे।

Answer 5

GUID का उपयोग करके हमें बहुत सारे काम सहेजे गए जब हमें दो डेटाबेस एक में विलय करना पड़ा।

Answer 6

यदि आपका डेटाबेस लैपटॉप पर डाउनलोड करने और ऑफ़लाइन इसके साथ काम करने के लिए काफी छोटा है, तो आपको शायद इनट्स और ग्विड्स के बीच प्रदर्शन अंतर के बारे में ज्यादा चिंता करने की आवश्यकता नहीं है। लेकिन सिस्टम को विकसित करने और समस्या निवारण करते समय कितनी उपयोगी चींटियां कम नहीं होती हैं! आपको शायद कुछ जटिल जटिल आयात/सिंच तर्क के साथ आने की आवश्यकता होगी चाहे आप गुड्स का उपयोग कर रहे हों या नहीं, इसलिए वे जितना सोचते हैं उतनी मदद नहीं कर सकते हैं।

Answer 7

के माध्यम से इन तालिकाओं तक पहुंच होगी GUID कुंजी धीमी हो जाएगी?

GUIDs के साथ अन्य समस्याओं कर रहे हैं, जैसा कि आप देख GUIDs तो आवेषण हर जगह बिखरे हुए किया जाएगा, अनुक्रमिक नहीं हैं, यह पेज विभाजन और सूचकांक विखंडन

SQL सर्वर 2005 एमएस शुरू की NEWSEQUENTIALID में का कारण बनता है() इसे ठीक करने के लिए, आपके लिए एकमात्र समस्या यह हो सकती है कि आप केवल तालिका में डिफ़ॉल्ट मान के रूप में NEWSEQUENTIALID का उपयोग कर सकते हैं

Answer 8

@ सिमॉन,

आप बहुत अच्छे अंक उठाते हैं। मैं पहले से ही "अस्थायी" मानव-पठनीय "संख्याओं के बारे में सोच रहा था जो ऑफ़लाइन होने पर उत्पन्न होता था, कि मैं सिंक पर फिर से बनाउंगा। लेकिन मैं विदेशी कुंजी, आदि के साथ काम करना टालना चाहता था।

Answer 9

मैं इसके लिए SQL सर्वर कॉम्पैक्ट संस्करण देखना शुरू कर दूंगा! यह आपके सभी मुद्दों के साथ मदद करता है।

Data Storage Architecture with SQL Server 2005 Compact Edition

यह विशेष रूप से

फील्ड बल अनुप्रयोगों (FFAs) के लिए बनाया गया। FFAs आमतौर पर एक या निम्न विशेषताओं

वे उपयोगकर्ता से उनके नौकरी कार्यों डिस्कनेक्ट करने की अनुमति के और अधिक साझा बैक-एंड नेटवर्क साइट पर एक ग्राहक स्थान पर, सड़क पर, में एक हवाई अड्डे, या घर से।

FFAs आमतौर पर कभी कनेक्टिविटी के लिए तैयार कर रहे हैं, जिसका अर्थ है कि जब उन ग्राहक आवेदन चल रहे हैं, वे किसी भी तरह के पास नेटवर्क कनेक्शन की जरूरत नहीं है। एफएफए में अक्सर कई क्लाइंट शामिल होते हैं जो बैक-एंड डेटाबेस से डेटा को समेकित रूप से एक्सेस और उपयोग कर सकते हैं, दोनों कनेक्टेड और डिस्कनेक्ट मोड में।

एफएफए बैक-एंड डेटाबेस से क्लाइंट डेटाबेस ऑफ़लाइन समर्थन के लिए डेटा को दोहराने में सक्षम होना चाहिए। उन्होंने यह भी नेटवर्क

Answer 10

पहले सोचा था कि जो मन में आता से कनेक्ट जब आवेदन करने में सक्षम है दोहराने के लिए , संशोधित जोड़ा, या सर्वर करने के लिए ग्राहक से डेटा रिकॉर्ड नष्ट सक्षम होना चाहिए: क्या एमएस ने इस तरह के परिदृश्यों का समर्थन करने के लिए डेटासेट और डेटा एडाप्टर मॉडल तैयार नहीं किया है?

मुझे विश्वास है कि मैंने पढ़ा है कि एमएस ने अपने एडीओ रिकॉर्डसेट मॉडल को वर्तमान डेटासेट मॉडल में बदल दिया है, इसलिए यह बहुत अच्छा ऑफ़लाइन काम करता है। और यह भी है Sync Services for ADO.NET

मेरा मानना ​​है कि मैंने डेटा देखा है जो डेटासेट मॉडल का उपयोग करता है जो विदेशी कुंजी का भी उपयोग करता है और डेटाएडाप्टर का उपयोग करते समय भी वे पूरी तरह सिंक करते हैं। सिंक सेवाओं को आजमाएं नहीं, लेकिन मुझे लगता है कि आप इससे भी फायदा उठा सकते हैं।

उम्मीद है कि इससे मदद मिलती है।

Answer 11

@SqlMenace

वहाँ GUIDs के साथ अन्य समस्याओं, जैसा कि आप देख GUIDs तो आवेषण हर जगह बिखरे हुए किया जाएगा, अनुक्रमिक नहीं हैं, यह पेज विभाजन और सूचकांक विखंडन

का कारण बनता है

सच नहीं है। प्राथमिक कुंजी! = क्लस्टर सूचकांक।

यदि क्लस्टर्ड इंडेक्स एक और कॉलम ("inserted_on" दिमाग में स्प्रिंग्स) है तो आवेषण अनुक्रमिक होंगे और कोई पृष्ठ विभाजन या अत्यधिक विखंडन नहीं होगा।

Answer 12

आप सही है कि यह एक पुरानी समस्या है कर रहे हैं, और यह दो विहित समाधान है:

• उपयोग प्राथमिक कुंजी के रूप में एकमात्र पहचान। ध्यान दें कि यदि आप पठनीयता के बारे में चिंतित हैं तो आप GUID का उपयोग करने के बजाय अपना स्वयं का अद्वितीय पहचानकर्ता रोल कर सकते हैं। एक अद्वितीय पहचानकर्ता एक अद्वितीय मूल्य उत्पन्न करने के लिए तिथि और मशीन के बारे में जानकारी का उपयोग करेगा।

• 'अभिनेता' + पहचानकर्ता की एक समग्र कुंजी का उपयोग करें। प्रत्येक उपयोगकर्ता को एक संख्यात्मक अभिनेता आईडी मिलती है, और नई डाली गई पंक्तियों की चाबियाँ अभिनेता आईडी के साथ-साथ अगले उपलब्ध पहचानकर्ता का भी उपयोग करती हैं। तो यदि दो अभिनेता दोनों आईडी "100" के साथ एक नई पंक्ति डालते हैं, तो प्राथमिक कुंजी बाधा का उल्लंघन नहीं किया जाएगा।

व्यक्तिगत रूप से, मैं पहला दृष्टिकोण पसंद करता हूं, क्योंकि मुझे लगता है कि समग्र कुंजी विदेशी कुंजी के रूप में वास्तव में कठिन हैं। मुझे लगता है कि मानव पठनीयता की शिकायत अतिस्तरीय है - अंत उपयोगकर्ताओं को अपनी चाबियों के बारे में कुछ भी नहीं जानना चाहिए, वैसे भी!

Answer 13

@ पोर्टमैन डिफ़ॉल्ट रूप से पीके == क्लस्टरर्ड इंडेक्स, प्राथमिक कुंजी बाधा उत्पन्न करने से स्वचालित रूप से क्लस्टर्ड इंडेक्स बन जाएगा, यदि आप इसे क्लस्टर नहीं करना चाहते हैं तो आपको गैर क्लस्टर निर्दिष्ट करना होगा।

Answer 14

guid.comb का उपयोग करना सुनिश्चित करें - अनुक्रमण सामग्री का ख्याल रखता है। यदि आप उसके बाद प्रदर्शन के मुद्दों से निपट रहे हैं तो आप कम क्रम में, स्केलिंग पर एक विशेषज्ञ होंगे।

GUID का उपयोग करने का एक और कारण डेटाबेस रिफैक्टरिंग सक्षम करना है। मान लें कि आप पॉलिमॉर्फिज्म या विरासत या अपनी ग्राहक इकाई के लिए जो कुछ भी लागू करने का निर्णय लेते हैं। अब आप ग्राहक और कर्मचारियों को व्यक्ति से प्राप्त करना चाहते हैं और उन्हें एक टेबल साझा करना चाहते हैं। वास्तव में अद्वितीय पहचानकर्ता होने से डेटा माइग्रेशन सरल हो जाता है। लड़ने के लिए कोई अनुक्रम या पूर्णांक पहचान फ़ील्ड नहीं हैं।

Answer 15

मैं आपको What are the performance improvement of Sequential Guid over standard Guid? पर इंगित करने जा रहा हूं, जिसमें GUID बात शामिल है।

मानव पठनीयता के लिए, मशीन आईडी असाइन करने पर विचार करें और फिर उन मशीनों से अनुक्रमिक संख्याओं का उपयोग करने की संभावना के रूप में उपयोग करें। हालांकि, मशीन आईडी के असाइनमेंट को प्रबंधित करने की आवश्यकता होगी। एक या दो कॉलम में किया जा सकता है।

हालांकि, मैं व्यक्तिगत रूप से SGUID उत्तर का शौकीन हूं।