Guid كما المفاتيح الأساسية - حاليا OLTP
https://stackoverflow.com/questions/40230
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
نحن نعمل على تصميم تطبيق عادة OLTP (أعتقد:نظام الشراء).ومع ذلك, هذا واحد على وجه الخصوص تحتاج إلى أن بعض المستخدمين سوف تكون حاليا ، لذلك فإنها تحتاج إلى أن تكون قادرة على تحميل DB إلى آلة ، العمل على ذلك ، ومن ثم مزامنة مرة أخرى مرة واحدة انهم على الشبكة المحلية.
أود أن أشير إلى أنني أعرف هذا تم القيام به من قبل, أنا فقط لم يكن لديك تجربة مع هذا نموذج معين.
فكرة واحدة فكرت باستخدام Guid كما الجدول المفاتيح.لذلك على سبيل المثال ، طلب الشراء سوف لا يكون لديك عدد (السيارات-رقمية) ولكن GUID بدلا من ذلك ، حيث أن كل المعلومات دون اتصال العميل يمكن أن تولد تلك و لا يكون الاشتباكات عندما أقوم بتوصيل إلى DB.
وهذا هو فكرة سيئة لسبب ما ؟ سوف الوصول إلى هذه الجداول من خلال GUID الرئيسية تكون بطيئة ؟
هل كان لديك تجربة مع هذا النوع من النظم ؟ كيف تحل هذه المشكلة ؟
وذلك بفضل!
دانيال
المحلول
باستخدام Guid كما المفاتيح الأساسية هو مقبول و يعتبر إلى حد ما مستوى ممارسة لنفس الأسباب التي تفكر بها.يمكن أن يبالغ التي يمكن أن تجعل الأمور قليلا مملة إلى تصحيح وإدارتها ، وذلك في محاولة للحفاظ على الخروج من كود الجداول وغيرها من البيانات المرجعية إذا كان ذلك ممكنا.
الشيء الذي لديك إلى القلق نفسك مع الإنسان للقراءة معرف.Guids لا يمكن تبادلها الناس - يمكنك أن تتخيل في محاولة لتأكيد رقم طلبك عبر الهاتف إذا كان هو guid?حتى في حاليا سيناريو قد لا يزال لديك لتوليد شيء مثل الناشر (محطة/المستخدم) معرف وبعض رقم تسلسل بحيث قد يكون عدد 123-5678 -.
ولكن هذا قد لا يرضي متطلبات العمل من وجود رقم تسلسلي.في الواقع المتطلبات التنظيمية يمكن أن يكون تأثير بعض الأنظمة (SOX ربما) تتطلب أن الفاتورة أرقام متسلسلة.في مثل هذه الحالات قد يكون من الضروره أن تولد نوعا من الأولية التي يتم إصلاحها في وقت لاحق عندما نظم مزامنة.قد تصل الأرض مع الجداول وجود OrderId (Guid) OrderNo (int) ، ProformaOrderNo (varchar) - بعض التعقيد قد زحف في.
على الأقل وجود guid كما المفاتيح الأساسية يعني أنه ليس عليك أن تفعل الكثير من التحديثات المتتالية عند المزامنة لا يحدث في نهاية المطاف - يمكنك ببساطة تحديث الإنسان للقراءة عدد.
نصائح أخرى
@SqlMenace
هناك مشاكل أخرى مع Guid, ترى Guid ليست متسلسلة ، بحيث إدراج سوف تكون مبعثرة في كل مكان ، وهذا يسبب الانقسامات الصفحة و مؤشر تجزئة
ليس صحيحا. المفتاح الأساسي != فهرس متفاوت المسافات.
إذا فهرس متفاوت المسافات هو عمود آخر ("inserted_on" الينابيع إلى الذهن) ثم إدراج سوف تكون متتابعة ولا انشقاقات الصفحة أو الإفراط في تجزئة سوف تحدث.
هذا هو تماما جيدة استخدام المعرفات الفريدة العمومية.فقط رسم ظهورهم سيكون طفيف التعقيد في العمل مع Guid على رجات طفيف حجم الفرق (16 بايت مقابل 4 بايت).
لا أعتقد أن أي من هذه الصفقة الكبيرة.
سوف الوصول إلى هذه الجداول من خلال GUID الرئيسية تكون بطيئة ؟
هناك مشاكل أخرى مع Guid, ترى Guid ليست متسلسلة ، بحيث إدراج سوف تكون مبعثرة في كل مكان ، وهذا يسبب الانقسامات الصفحة و مؤشر تجزئة
في SQL Server 2005 MS قدم NEWSEQUENTIALID() لإصلاح هذه المشكلة الوحيدة بالنسبة لك قد يكون أنه يمكنك فقط استخدام NEWSEQUENTIALID باعتبارها القيمة الافتراضية في الجدول
كنت الصحيح أن هذا هو مشكلة قديمة ، وقد أقوال اثنين من الحلول:
استخدام المعرفات الفريدة المفتاح الأساسي.ملاحظة أنه إذا كنت تشعر بالقلق إزاء القراءة يمكنك لفة الخاص بك معرف فريد بدلا من استخدام GUID.معرف فريد سيتم استخدام المعلومات عن تاريخ آلة لتوليد قيمة فريدة من نوعها.
استخدام مفتاح مركب من 'الممثل' + معرف.كل مستخدم يحصل على رقمي الفاعل معرف المفاتيح من الصفوف المدرجة حديثا استخدام الفاعل معرف وكذلك المتاحة التالية معرف.حتى إن اثنين من العناصر الفاعلة سواء إدراج صف جديد مع ID "100" ، قيد مفتاح أساسي لن تنتهك.
وأنا شخصيا أفضل كما أعتقد مركب مفاتيح حقا مملة مثل المفاتيح الخارجية.أعتقد أن الإنسان قراءة الشكوى المبالغة -- end-لا يجب على المستخدمين معرفة أي شيء عن المفاتيح الخاصة بك على أي حال!
تأكد من استخدام guid.مشط - يعتني الفهرسة الأشياء.إذا كنت تتعامل مع مشكلات في الأداء بعد ذلك فإنك سوف تكون في وقت قصير ، خبير في القياس.
سبب آخر لاستخدام Guid هو تمكين قاعدة البيانات إعادة بيع ديون.نقول لك أن تقرر تطبيق تعدد الأشكال أو الميراث أو ما إلى الزبائن الكيان.تريد الآن العملاء والموظفين أن تستمد من شخص يكون لهم حصة في الجدول.حقا وجود معرفات فريدة من نوعها يجعل نقل البيانات بسيطة.لا يوجد تسلسل أو عدد صحيح الهوية ميادين للقتال مع.
أنا مجرد الذهاب إلى نقطة لك ما هي تحسين الأداء من متتابعة Guid على مستوى Guid?, الذي يغطي GUID الحديث.
الإنسان القراءة ، النظر في تعيين معرفات الجهاز ثم باستخدام أرقام متسلسلة من تلك الآلات احتمال ممكن.وهذا يتطلب إدارة إحالة آلة معرفات ، على الرغم من.يمكن القيام به في واحد أو عمودين.
أنا شخصيا مغرم SGUID الجواب ، على الرغم من.
Guids بالتأكيد سوف يكون أبطأ (و استخدام المزيد من الذاكرة) من معيار صحيح مفاتيح ، ولكن أم أن المسألة تعتمد على نوع الحمولة النظام الخاص بك سوف نرى.اعتمادا على الخلفية الخاصة بك ديسيبل قد يكون هناك مشاكل مع فهرسة الحقول guid.
باستخدام guid يبسط فئة كاملة من المشاكل ، ولكن يجب أن تدفع ثمن هذا الجزء الأداء و أيضا debuggability - كتابة guid في تلك استفسارات اختبار الشيخوخة بسرعة!
الخلفية سوف تكون SQL Server 2005
الواجهة / تطبيق المنطق سوف يكون .صافي
بالإضافة إلى Guid, هل يمكنك التفكير في طرق أخرى لحل "دمج" الذي يحدث عند اتصال الكمبيوتر مزامنة البيانات الجديدة مرة أخرى إلى قاعدة البيانات المركزية?
أعني إذا المفاتيح رجات ، يجب أن يعاد كل شيء عند استيراد الأساس.GUIDs سوف اعفني من هذا.
باستخدام Guid حفظ لنا الكثير من العمل عندما كان علينا أن دمج قاعدتي بيانات في واحد.
إذا كانت قاعدة البيانات الخاصة بك هي صغيرة بما يكفي تحميل على الكمبيوتر المحمول والعمل معها حاليا, ربما كنت لا داعي للقلق كثيرا حول أداء الخلافات بين رجات و Guid.ولكن لا نقلل من مدى فائدة رجات عندما النامية و استكشاف الأخطاء وإصلاحها نظام!وربما كنت سوف تحتاج إلى الخروج مع بعض معقدة إلى حد ما الاستيراد/التوافق المنطق بغض النظر عن ما إذا كنت تستخدم المعرفات الفريدة العمومية ، حيث أنها قد لا تساعد كثيرا كما كنت أعتقد.
@سيمون ،
قمت برفع النقاط الجيدة جدا.كنت أفكر بالفعل عن "مؤقتة" الإنسان "للقراءة" أرقام أود أن تولد بينما حاليا أنا أريد إعادة المزامنة.ولكن أردت أن تجنب القيام مع مفاتيح خارجية ، وما إلى ذلك.
أود بداية أن ننظر إلى SQL Server Compact Edition لهذا!فإنه يساعد مع جميع القضايا الخاصة بك.
بنية تخزين البيانات في SQL Server 2005 ضغط Edition
انها مصممة خصيصا
القوة الميدانية تطبيقات ([فس]).[فس] عادة حصة واحدة أو أكثر من السمات التالية
أنها تسمح للمستخدم لأداء المهام الوظيفية في حين قطع من الشبكة الخلفية على الموقع في العميل الموقع على الطريق ، المطار أو من المنزل.
[فس] عادة ما تكون مصممة في بعض الأحيان الاتصال ، وهذا يعني أن عندما تقوم بتشغيل المستخدمين العميل التطبيق, أنها لا تحتاج إلى أن يكون شبكة اتصال من أي نوع.[فس] غالبا ما تنطوي على عدة عملاء يمكن أن والوصول إلى واستخدام البيانات من قاعدة البيانات ذات النهاية الخلفية ، سواء في توصيل وقطع الوضعية.
[فس] يجب أن تكون قادرة على تكرار البيانات من قاعدة البيانات ذات النهاية الخلفية إلى العميل قواعد البيانات حاليا الدعم.كما أنها تحتاج إلى أن تكون قادرة على تكرار أو تعديل ، أو إضافة ، أو حذف البيانات الوثائق من العميل إلى الملقم عندما يكون التطبيق قادرا على الاتصال بالشبكة
الفكر الأول الذي يتبادر إلى الذهن:لم MS تصميم قاعدة البيانات ولم DataAdapter نموذج لدعم سيناريوهات مثل هذا ؟
أعتقد أنني قرأت أن السيدة تغيير سجلات ADO النموذج الحالي بيانات نموذج لذلك يعمل دون اتصال كبيرة جدا.و هناك أيضا هذا "خدمات مزامنة" ADO.NET
أعتقد أنني رأيت التعليمات البرمجية التي تستخدم بيانات النموذج الذي يستخدم أيضا مفاتيح خارجية وأنها لا تزال تزامن تماما عند استخدام DataAdapter.Havn't محاولة الخروج من "خدمات المزامنة" على الرغم من ولكن أعتقد أنك قد تكون قادرة على الاستفادة من ذلك أيضا.
ويساعد هذا الأمل.
@بورتمان افتراضيا PK == فهرس متفاوت المسافات ، وخلق قيد مفتاح أساسي تلقائيا إنشاء فهرس متفاوت المسافات, تحتاج إلى تحديد غير متفاوت إذا كنت لا تريد ذلك متفاوت المسافات.
