هل هناك معيار/اتفاقية ترتيب الأعمدة في جدول قاعدة بيانات التعريف ؟

Question

هل هناك معيار/اتفاقية كيف الأعمدة يجب أن يكون أمر في تعريف جدول قاعدة بيانات ، وإذا كان الأمر كذلك ما هو الدافع لهذا المعيار ؟ (إيجابيات/سلبيات)

على سبيل المثال ، يجب أن المفتاح الأساسي يكون أول عمود ؟ يجب على مفاتيح خارجية مباشرة اتبع مفتاح أساسي أو ينبغي أن توضع في أقصى اليمين من الجدول ؟

إذا كان هناك فرق بين الاتفاقيات المختلفة ، قواعد البيانات ، DBMS في هذه الحالة هو Microsoft SQL Server 2005.

شكرا /إريك

Answer 1

أنا لست على علم بأي معيار ، لكن طريقة هيكل لدينا وcolums هو

1. المفتاح الأساسي(s)
2. أي المفاتيح الخارجية
3. البيانات

لدينا كبيرة أعمدة البيانات ، مثل التعليقات في نهاية المطاف.فإنه يجعل من السهل لعرض أكبر قدر ممكن من البيانات في "محلل استعلام" دون الحاجة إلى التمرير إلى اليمين.

Answer 2

أنا دائما بنية الجداول مثل هذا:

1. المفتاح الأساسي(s)
2. 'تتبع' الأعمدة (DateModified, ModifiedBy وكذا)
3. أي المفاتيح الخارجية
4. البيانات

Answer 3

وأنا لست متأكدا من الاتفاقيات مجموعة كننا دائما وضع ID / عمود المفتاح الأساسي باعتباره العمود الأول في الجدول. أفترض انها مجرد لأنه يجعل من أكثر وضوحا لرؤية كيه. وأنا أقول أيضا اتباع أنه مع الحقول كيه لكن بعد ذلك لا يوجد معيار حقيقي، هل يمكن ربما القيام بذلك عن طريق نوع البيانات؟

وأيضا، ليس تعيين هذه من أفضل الممارسات، مجرد اختيار شخصي.

Answer 4

لا أحد أعرفه. يمكنك إعادة ترتيب دائما الأعمدة أثناء مختارة على أي حال، لذلك لا يهم ما لم يكن هناك بعض التحسين غامض حقا يمكنك القيام به على بعض قواعد البيانات عن طريق طلب الأعمدة بشكل مناسب.

Answer 5

وليس هناك معيار الرسمي الذي أنا على علم، ولكن الممارسة العادية هو وضع المفتاح الأساسي لأول مرة (انها عادة ما تكون بديل) ثم مجموعة الحقول الأخرى التي الوظيفة. حتى في جدول "شخص" واحد من شأنه مجموعة الحقول التي تحتوي على بيانات عنوان الشخص معا. معظم الناس إضافة FKS، والفهارس وغيرها من القيود خارج الجدول definion السليم.

Answer 6

وملم .. وأعرف أن هناك أي قيود. انها مجرد مسألة وضوح.

Answer 7

وأنا أتفق مع معظم الوظائف أعلاه، المفتاح الأساسي لأول مرة (على الأقل). والباقي هو تفضيل شخصي. إذا كان لديك معيار ثم الحفاظ على هذا المعيار.

وأنا لا تفضل الاحتفاظ الأعمدة إلى حد ما من الناحية المنطقية معا. أحيانا بنية بيانات تطبيع كامل غير مناسب بحيث يكون لديك "الكيانات الصغيرة" تخزين على طاولة واحدة (أي ليس إزالة القيم الخالية). على سبيل المثال سيكون حقول العنوان، أو هاتف مختلف، والهاتف المحمول، والأعمدة هاتف العمل وضعت معا.

وأبرز مثال أستطيع أن أعطي هو كيف لا تفعل ذلك. إذا مطور autogenerates مخطط ويتم إنشاء الأعمدة بالترتيب الأبجدي (وكانت مخبأة حتى PK في منتصف بنية الجدول) ثم وهذا هو الأكثر مزعج.

Answer 8

وكما في edoode: -

Primary key(s) 
'Tracking' columns (DateModified, ModifiedBy and such) 
Any foreign keys 
Data 

وبالاضافة الى ذلك

Fixed width 'not null' columns
Fixed width 'nullable' columns
Variable Width columns VARCHAR NVARCHAR etc.
CLOBS
BLOBS 

ويمكنك الحصول على ويني تيني من أي وقت مضى زيادة في الأداء طفيفة حتى إذا كنت عصا الأعمدة التي قد تختلف في الطول في الجزء السفلي من الجدول.