it-swarm.asia

الاستخدام الصحيح لجداول البحث

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

لنفترض أن لدي جدول يسمى الموظفين:

ID  LName   FName   Gender  Position
1   Doe     John    Male    Manager
2   Doe     Jane    Female  Sales
3   Smith   John    Male    Sales

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

ID  Position
1   Manager
2   Sales

ولكن إلى أي مدى يمكنني الاستمرار في تقسيم المعلومات إلى جداول بحث أصغر قبل أن تصبح غير قابلة للإدارة؟ يمكنني إنشاء جدول جنس ولدي 1 يتوافق مع ذكر و 2 يتوافق مع أنثى في جدول بحث منفصل. حتى يمكنني وضع LNames و FNames في جداول. يتم استبدال جميع إدخالات "John" بمفتاح خارجي 1 يشير إلى جدول FName الذي يشير إلى أن معرف 1 يتوافق مع John. إذا ذهبت إلى أسفل حفرة الأرنب هذه على هذا النحو ، على الرغم من ذلك ، يتم تقليل جدول الموظفين إلى فوضى من المفاتيح الأجنبية:

ID  LName   FName   Gender  Position
1   1       1       1       1
2   1       2       2       2
3   2       1       1       2

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

25
Brad Turner

ولكن إلى أي مدى يمكنني الاستمرار في تقسيم المعلومات إلى جداول بحث أصغر قبل أن تصبح غير قابلة للإدارة؟ يمكنني إنشاء جدول جنس ولدي 1 يتوافق مع ذكر و 2 يتوافق مع أنثى في جدول بحث منفصل.

أنت تخلط بين مشكلتين مختلفتين. قضية واحدة هي استخدام جدول "بحث"؛ والآخر هو استخدام مفاتيح بديلة (أرقام الهوية).

ابدأ بهذا الجدول.

ID  LName   FName   Gender  Position
1   Doe     John    Male    Manager
2   Doe     Jane    Female  Sales
3   Smith   John    Male    Sales

يمكنك إنشاء جدول "بحث" لمواقف مثل هذه.

create table positions (
  pos_name varchar(10) primary key
);

insert into positions
select distinct position 
from employees;

alter table employees
add constraint emp_fk1
foreign key (position) 
  references positions (pos_name);

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

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

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

22
Mike Sherrill 'Cat Recall'

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

  • النوع يصف نفسه ذاتيًا (قل M أو F) ، مقيد بقيمتين ، ويمكن فرضه مع قيد CHECK. لن تضيف أجناس جديدة (تجاهل أصوات الصواب السياسية)
  • الاسم الأول "John" ليس جزءًا من مجموعة محدودة ومقيدة من البيانات: المجموعة المحتملة من البيانات ضخمة إلى حد لا حدود لها بشكل فعال لذا لا ينبغي أن يكون البحث

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

أيضًا ، بمجرد أن يكون لديك مليون موظف ، يكون تخزين PositionID أصغر بكثير من varchar.

دعونا نضيف عمودًا جديدًا "عملة الراتب". سأستخدم جدول بحث هنا مع مفتاح CHF ، GBP ، EUR ، USD إلخ: لن أستخدم مفتاحًا بديلاً. يمكن تقييد هذا بقيد CHECK مثل الجنس ولكنه عبارة عن مجموعة محدودة من البيانات القابلة للتوسيع مثل Position. أعطي هذا المثال لأنني سأستخدم المفتاح الطبيعي حتى لو ظهر في مليون صف من بيانات الموظف على الرغم من كونه رقم (3) بدلاً من أن يكون صغيرًا جدًا

لذا ، لتلخيص ، يمكنك استخدام جداول البحث

  1. حيث لديك مجموعة بيانات محدودة وقابلة للتوسيع في عمود
  2. حيث لا يصف نفسه
  3. لتجنب شذوذ تعديل البيانات
8
gbn

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

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

لإعادة استخدام الاقتباس المفضل

"قال لي رجل حكيم ذات مرة" تطبيع حتى يضر ، يتغير إلى أن يعمل ".

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

خذ هذا المثال المختصر للجداول ذات التسوية العالية من نظام حقيقي

CREATE TABLE PROPERTY
(ID                          NUMBER(9)           NOT NULL);

CREATE TABLE PROPERTY_TYPE
(ID                          NUMBER(9)           NOT NULL);

CREATE TABLE PROPERTY_LOCALE 
PROPERTY_ID                  NUMBER(9)           NOT NULL,
(LOCALE_ID                   NUMBER(9)           NOT NULL,  --language 
VALUE                        VARCHAR2(200)       NOT NULL);

CREATE TABLE PROPERTY_DEPENDENCY
(PROPERTY_ID                 NUMBER(9)           NOT NULL,
 PARENT_PROPERTY_ID          NUMBER(9)                   ,
 PROPERTY_TYPE_ID            NUMBER(9)           NOT NULL);

تقوم هذه الجداول بإعداد قائمة مرتبطة بالخصائص الفردية والخصائص الفرعية الأصل ويتم استخدامها هنا

  CREATE TABLE CASE_PROPERTY
  (ID                        NUMBER(9)           NOT NULL,
  PARENT_ID                  NUMBER(9),
  CASE_ID                    NUMBER(9)           NOT NULL,
  PROPERTY_ID                NUMBER(9),
  PROPERTY_TYPE_ID           NUMBER(9)           NOT NULL);

يبدو هذا جيدًا: احصل على جميع الحالات باستخدام property_id في تحديد واحد

دعونا نحصل على قائمة للاختيار من بينها

 Select pl.value, pd.property_id
 from property_locale pl, property_dependency pd
 where pl.property_id = pd.property_id
 and pd.property_type_id = 2;  --example number

جرب الآن تحديد جميع خصائص الحالة إذا كانت تحتوي على property_types من 3 و 4 و 5 ، أو لا ...

SELECT   cp2.case_id,
         (SELECT   pl.VALUE
            FROM   case_property cp, property_locale pl
           WHERE       cp.property_id = pl.property_id
                   AND CP.PROPERTY_TYPE_ID = 2
                   AND pl.locale_id = 2
                   AND cp.case_id = cp2.case_id)
            AS VALUE1,
         (SELECT   pl.VALUE
            FROM   case_property cp, property_locale pl
           WHERE       cp.property_id = pl.property_id
                   AND CP.PROPERTY_TYPE_ID = 34
                   AND pl.locale_id = 2
                   AND cp.case_id = cp2.case_id)
            AS VALUE2,
         (SELECT   pl.VALUE
            FROM   case_property cp, property_locale pl
           WHERE       cp.property_id = pl.property_id
                   AND CP.PROPERTY_TYPE_ID = 4
                   AND pl.locale_id = 2
                   AND cp.case_id = cp2.case_id)
            AS VALUE3
  FROM   case_property cp2
 WHERE   cp2.case_id = 10293  

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

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

5
kevinsky