قاعدة بيانات Messenger (الجزء الأول): تصميم الإطار الأساسي

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

• الجزء 1: تصميم الإطار الأساسي
• الجزء 2: تقسيم "الربح"

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

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

الخطوة 1: بعض تفاصيل الأعمال

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

وما هي مهام الشركة؟.. لننظر إلى مثال فاسيلي، رئيس قسم التطوير.

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

دعونا نتناول قائمة الاحتياجات "الواضحة" هذه في الوقت الحالي.

دون فهم التفاصيل التطبيقية للمشكلة والقيود المفروضة عليها، التصميم فعالة مخطط قاعدة البيانات لحلها يكاد يكون من المستحيل.

الخطوة 2: الحد الأدنى من الدائرة المنطقية

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

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

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

يرسم الرسوم البيانية بسيطة قدر الإمكان - معظم الأشخاص الذين ستعرضهم عليهم ليسوا خبراء في قراءة UML/IDEF. ولكن تأكد من الرسم.

الخطوة 3: رسم هيكل الجدول

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

سيبدو هيكل الجدول المسودة في قاعدة بياناتنا كما يلي:
الجداول : رو

CREATE TABLE "Тема"(
  "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

CREATE TABLE "Сообщение"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "Автор"
    uuid
, "ДатаВремя"
    timestamp
, "Текст"
    text
);

CREATE TABLE "Адресат"(
  "Сообщение"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Сообщение", "Персона")
);

CREATE TABLE "Файл"(
  "Файл"
    uuid
      PRIMARY KEY
, "Сообщение"
    uuid
, "BLOB"
    uuid
, "Имя"
    text
);

الجداول: إن

CREATE TABLE theme(
  theme
    uuid
      PRIMARY KEY
, document
    uuid
, title
    text
);

CREATE TABLE message(
  message
    uuid
      PRIMARY KEY
, theme
    uuid
, author
    uuid
, dt
    timestamp
, body
    text
);

CREATE TABLE message_addressee(
  message
    uuid
, person
    uuid
, PRIMARY KEY(message, person)
);

CREATE TABLE message_file(
  file
    uuid
      PRIMARY KEY
, message
    uuid
, content
    uuid
, filename
    text
);

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

الخطوة الرابعة: اكتشف الاحتياجات غير الواضحة

هذا كل شيء، لقد قمنا بتصميم قاعدة بيانات يمكنك من خلالها الكتابة بشكل مثالي و بطريقة أو بأخرى لقراءة.

دعونا نضع أنفسنا مكان مستخدم خدمتنا - ماذا نريد أن نفعل بها؟

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

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

قد يتم وضع مهام المستخدم غير المقصودة بالخط العريض عبور على الإنتاجية.

الخطوة 5: إزالة التطبيع الذكية

سيتم حل كلتا المشكلتين من خلال الجداول الإضافية التي سنحلها تكرار جزء من البياناتمن الضروري تكوين مؤشرات مناسبة لمهامنا عليها.


الجداول : رو

CREATE TABLE "РеестрСообщений"(
  "Владелец"
    uuid
, "ТипРеестра"
    smallint
, "ДатаВремя"
    timestamp
, "Сообщение"
    uuid
, PRIMARY KEY("Владелец", "ТипРеестра", "Сообщение")
);
CREATE INDEX ON "РеестрСообщений"("Владелец", "ТипРеестра", "ДатаВремя" DESC);

CREATE TABLE "УчастникТемы"(
  "Тема"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Тема", "Персона")
);

الجداول: إن

CREATE TABLE message_registry(
  owner
    uuid
, registry
    smallint
, dt
    timestamp
, message
    uuid
, PRIMARY KEY(owner, registry, message)
);
CREATE INDEX ON message_registry(owner, registry, dt DESC);

CREATE TABLE theme_participant(
  theme
    uuid
, person
    uuid
, PRIMARY KEY(theme, person)
);

قمنا هنا بتطبيق طريقتين نموذجيتين تستخدمان عند إنشاء الجداول المساعدة:

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

في الجزء التالي من المقال سنتحدث عنه تنفيذ التقسيم في هيكل قاعدة البيانات لدينا.

المصدر: www.habr.com