سؤال

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

على سبيل المثال، إذا كان لدي قائمة بالأشخاص

CREATE TABLE people (
  id       INTEGER PRIMARY KEY,
  name     VARCHAR(100),
  active   BOOLEAN,
  ...
);

وهذا يعني أنه للحصول على قائمة بالأشخاص النشطين، يجب عليك استخدامها

SELECT * FROM people WHERE active=True;

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

الفضول يلفت الانتباه...

يحرر: يجب أن أوضح أنني أتناول هذا من منظور نقي.أستطيع أن أرى كيف أن أرشفة البيانات قد تكون ضرورية لكميات كبيرة من البيانات، ولكن هذا ليس ما أقصده.إذا قمت بإجراء SELECT * FROM من الأشخاص، فسيكون من المنطقي بالنسبة لي أن تكون هذه الإدخالات "نشطة" إلى حد ما

شكرًا

هل كانت مفيدة؟

المحلول

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

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

CREATE TABLE people
(
   id       NUMBER(10),
   name     VARCHAR2(100),
   active   NUMBER(1)
)
PARTITION BY LIST(active)
(
   PARTITION active_records VALUES (0)
   PARTITION inactive_records VALUES (1)
);

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

بالمناسبة، يبدو أن هذا تكرار هذا سؤال، كمبتدئ يجب أن أسأل، ما هو الإجراء المتبع في التعامل مع التكرارات غير المقصودة؟

يحرر: كما هو مطلوب في التعليقات، قدم مثالاً لإنشاء جدول مقسم في أوراكل

نصائح أخرى

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

نحن نستخدم التعداد ('ACTIVE','INACTIVE','DELETED') في معظم الجداول بحيث يكون لدينا بالفعل علامة ثلاثية.أجد أنه يعمل بشكل جيد بالنسبة لنا في مواقف مختلفة.قد تختلف المسافة المقطوعة الخاصة بك.

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

وهذا يؤدي إلى النقطة التالية:لماذا ستحركه؟يتطلب الجدول المفهرس بشكل صحيح عملية بحث إضافية واحدة عندما يتضاعف الحجم.أي تحسن في الأداء لا بد أن يكون ضئيلا.ولماذا قد تفكر في الأمر حتى المستقبل البعيد عندما تواجه بالفعل مشكلات في الأداء؟

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

يحتوي هذا الجدول على بيانات عن الأشخاص، بغض النظر عن الحالة الحالية لبياناتهم.

العلم النشط قبيح نوعًا ما، لكنه بسيط ويعمل بشكل جيد.

يمكنك نقلهم إلى جدول آخر كما اقترحت.أقترح النظر في النسبة المئوية للسجلات النشطة/غير النشطة.إذا كان لديك أكثر من 20 أو 30% من السجلات غير النشطة، فقد تفكر في نقلها إلى مكان آخر.خلاف ذلك، انها ليست مشكلة كبيرة.

نعم، نحن سوف نفعل ذلك.لدينا حاليًا العمود "active='T/F'" في العديد من جداولنا، وذلك بشكل أساسي لإظهار الصف "الأحدث".عند إدراج صف جديد، يتم وضع علامة F على الصف T السابق للاحتفاظ به لأغراض التدقيق.

الآن، نحن ننتقل إلى نهج الجدولين، عندما يتم إدراج صف جديد، يتم نقل الصف السابق إلى جدول المحفوظات.وهذا يمنحنا أداءً أفضل في معظم الحالات - بالنظر إلى البيانات الحالية.

التكلفة أعلى قليلاً من الطريقة القديمة، في السابق كان عليك التحديث والإدراج، الآن عليك الإدراج والتحديث (أي بدلاً من إدراج صف T جديد، يمكنك تعديل الصف الموجود بكل البيانات الجديدة)، وبالتالي فإن التكلفة هو مجرد تمرير صف كامل من البيانات بدلاً من تمرير التغييرات فقط.وهذا لن يكون له أي تأثير.

تتمثل فائدة الأداء في أن فهرس الجدول الرئيسي الخاص بك أصغر بكثير، ويمكنك تحسين مساحات الطاولة الخاصة بك بشكل أفضل (لن تنمو كثيرًا!)

تعتبر العلامات الثنائية مثل هذه في مخططك فكرة سيئة.خذ بعين الاعتبار الاستعلام

SELECT count(*) FROM users WHERE active=1

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

ALTER TABLE users ADD INDEX index_users_on_active (active)

يستثني!!هذا الفهرس عديم الفائدة لأن العدد الأساسي في هذا العمود هو اثنان بالضبط!سيتجاهل أي مُحسِّن استعلام قاعدة البيانات هذا الفهرس نظرًا لانخفاض عدد العناصر فيه وسيجري فحصًا للجدول.

قبل ملء مخططك بعلامات مفيدة، فكر في كيفية الوصول إلى تلك البيانات.

https://stackoverflow.com/questions/108503/mysql-advisable-number-of-rows

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

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

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

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

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

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

نحن نستخدم طريقة "الانتقال إلى جدول الفصل" حيث لم تعد هناك حاجة إلى البيانات ولا تعد البيانات جزءًا من العلاقة.

الوضع يملي الحل حقًا، وأعتقد:

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

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

لا - هذا شيء شائع جدًا - هناك بعض الاختلافات اعتمادًا على متطلبات محددة (لكنك قمت بتغطيتها بالفعل):

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

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

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

أيضًا، من "المنظور النقي"، يجب تسمية الجدول بشخص، وليس أشخاص، لأن اسم العلاقة يعكس صفًا، وليس المجموعة بأكملها.

فيما يتعلق بفهرسة المنطقية، لماذا لا:

ALTER TABLE users ADD INDEX index_users_on_active (id, active) ;  

ألن يؤدي ذلك إلى تحسين البحث؟
ومع ذلك لا أعرف مقدار هذه الإجابة التي تعتمد على النظام الأساسي.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top