جدول مع الكثير من الأعمدة

Question

إذا كان لدى طاولتي عددًا كبيرًا من الأعمدة (أكثر من 80) ، فهل يمكنني تقسيمها إلى عدة جداول ذات علاقة من 1 إلى 1 أو فقط احتفظ بها كما هي؟ لماذا ا؟ شاغلي الرئيسي هو الأداء.

ملاحظة - طاولتي بالفعل في الشكل العادي الثالث.

PS2 - أنا أستخدم MS SQL Server 2008.

PS3 - لا أحتاج إلى الوصول إلى جميع بيانات الجدول في وقت واحد ، ولكن لدي 3 فئات مختلفة من البيانات داخل هذا الجدول ، والتي يمكنني الوصول إليها بشكل منفصل. إنه شيء مثل: تفضيلات الأعضاء ، حساب الأعضاء ، ملف تعريف العضو.

Answer 1

80 عمودًا ليس كذلك ...

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

أود أن تقلق بشأن هذا (يحتمل) من وجهة نظر الصيانة. كلما زاد عدد أعمدة البيانات في جدول واحد ، أصبح دور هذا الجدول في مخططك الكبير أقل فهمًا. أيضًا ، إذا كنت تستخدم عادةً فقط مجموعة فرعية صغيرة من البيانات ، وكل الأعمدة الـ 80 ليست مطلوبة دائمًا ، فقد يساعد الانقسام إلى جداول 2+ في الأداء.

Answer 2

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

Answer 3

أخذ مسار آخر ، من وجهة نظر الصيانة والاختبار ، إذا قلت أن لديك 3 مجموعات مميزة من البيانات في جدول واحد وإن كان ذلك مع نفس المعرف الفريد (على سبيل المثال ، قد يكون من المنطقي تقسيمه إلى جداول منفصلة .

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

أيضًا لأغراض Audit Trail إذا كنت ترغب في تتبع آخر معرف المستخدم/الطابع الزمني لتغيير بيانات الأعضاء. إذا كان تطبيق المسؤول يسمح بتحديث التفضيلات/تفاصيل الحساب/تفاصيل الملف الشخصي بشكل منفصل ، فمن المنطقي جعلها في جداول منفصلة لتتبع التحديثات بسهولة أكبر.

ليست إجابة SQL/Performan

Answer 4

يعتمد على ما هي هذه الأعمدة. إذا كنت قد حصلت على حقول مكررة مشفرة مثل Colour1 و Colour2 و Colour3 ، فهذه مرشحون لجداول الأطفال. القاعدة العامة الخاصة بي هي إذا كان هناك أكثر من حقل من نفس النوع (اللون) ، فيمكنك أيضًا رمزًا لـ N ، وليس رقمًا ثابتًا.

روب.

Answer 5

1-1 قد يكون أسهل ، إذا قلت الأعضاء _info ؛ Member_pref ؛ الملف الشخصي للعضو. يمكن أن يؤدي وجود العديد من الأعمدة إلى تشغيله إذا كنت تريد الكثير من Varchar (255) حيث يمكنك تجاوز الحد الأقصى للرقم ، وهذا يجعله مربكًا للغاية.

فقط تأكد من أن لديك قيود مفاتيح Forgein الصحي