mysql كيفية تنفيذ التعليقات والمقتطفات في قاعدة البيانات



قاعدة بيانات جاهزة (6)

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

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

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

السؤال هو كيفية تصميم قاعدة البيانات بطريقة صحيحة وفعالة ومرنة ، بحيث يمكن تخزين التعليقات لجداول مختلفة ، ويحب أن يكون للجداول والعلامات المختلفة. بعض نمط التصميم كإجابة سيكون أفضل؛)

وصف تفصيلي : لدي جدول User مع بعض بيانات المستخدم ، و 3 جداول إضافية: Photo مع Photo الفوتوغرافية ، Articles مع المقالات ، Places مع الأماكن . أريد تمكين أي مستخدم تم تسجيله من:

  • التعليق على أي من تلك الجداول الثلاثة

  • وضع علامة على أي منهم كما يحب

  • ضع علامة على أي منهم باستخدام بعض العلامات

  • أريد أيضًا احتساب عدد إبداءات الإعجاب لكل عنصر وعدد مرات استخدام علامة معينة.

النهج الأول :

أ) بالنسبة إلى العلامات ، سأقوم بإنشاء جدول جدول Tag [TagId, tagName, tagCounter] ، ثم سأقوم بإنشاء جداول العلاقات بين Photo_has_tags لـ: Photo_has_tags ، Place_has_tag ، Place_has_tag .

ب) نفس التهم للتعليقات.

ج) سأقوم بإنشاء جدول LikedPhotos [idUser, idPhoto] ، LikedArticles[idUser, idArticle] ، LikedPlace [idUser, idPlace] . سيتم احتساب عدد من الإعجابات عن طريق الاستعلامات (التي أفترض سيئة). و...

أنا حقا لا أحب هذا التصميم للجزء الأخير ، فإنه رائحة سيئة بالنسبة لي ؛)


النهج الثاني :

سأقوم بإنشاء جدول ElementType [idType, TypeName == some table name] والذي سيتم نشره من قبل المسئول (me) بأسماء الجداول التي يمكن أن يتم إبداء الإعجاب بها أو التعليق عليها أو وضع علامات عليها . ثم سأقوم بإنشاء الجداول :

a) LikedElement [idLike, idUser, idElementType, idLikedElement] ونفس الشيء للتعليقات LikedElement [idLike, idUser, idElementType, idLikedElement] ذات الأعمدة المناسبة لكل منها. الآن ، عندما أريد إنشاء صورة ، سأدرجها:

typeId = SELECT id FROM ElementType WHERE TypeName == 'Photo'
INSERT (user id, typeId, photoId)

وللأماكن:

typeId = SELECT id FROM ElementType WHERE TypeName == 'Place'
INSERT (user id, typeId, placeId)

وهكذا ... أعتقد أن النهج الثاني أفضل ، ولكنني أشعر أيضًا أن هناك شيء مفقود في هذا التصميم أيضًا ...

في الماضي ، أنا أيضا أتساءل أي أفضل مكان لتخزين مضادة لعدد المرات التي كان العنصر يحب. يمكنني التفكير في طريقتين فقط:

  1. في عنصر ( Photo/Article/Place ) الجدول
  2. عن طريق اختيار العد ().

آمل أن يكون شرحي للقضية أكثر شمولية الآن.


Answer #1

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

إذا لم يكن لصالح واحد يتطلب عدد أقل من الجداول

في هذه الحالة:

  1. أضف تعليقًا: إما أن تختار جدولًا معينًا / كثيرًا أو تُدرج في جدول مشترك بمعرّف محدد معروف لما يتم الإعجاب به ، وأعتقد أن رمز العميل سيكون أبسط قليلاً في حالتك الثانية.
  2. العثور على تعليقات للعنصر: هنا يبدو أن استخدام جدول مشترك يكون أسهل قليلاً - لدينا فقط معلمة طلب بحث منفرد حسب نوع الكيان
  3. العثور على تعليقات من قبل شخص حول نوع واحد من الأشياء: استعلام بسيط في كلتا الحالتين
  4. العثور على جميع التعليقات من قبل شخص عن كل الأشياء: هذا يبدو قليلا في كلتا الحالتين جنرال موتورز.

أعتقد أن أسلوب "التمييز" الخاص بك ، الخيار 2 ، يؤدي إلى استعلامات أبسط في بعض الحالات ولا يبدو أسوأ بكثير في الحالات الأخرى ، لذا سأذهب معه.


Answer #2

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


Answer #3

هذه فكرة عامة ، من فضلك لا تولي اهتماما كبيرا لتسمية أسماء الحقول ، ولكن أكثر للعلاقة والبنية

سيحصل هذا pseudocode على جميع تعليقات الصورة مع معرف 5
حدد * من الإجراءات
WHERE actions.id_Stuff = 5
AND actions.typeStuff = "photo"
AND actions.typeAction = "comment"

سيحصل هذا pseudocode على جميع الإعجابات أو المستخدمين الذين أبدوا إعجابهم بالصورة التي تحمل الرقم 5
(يمكنك استخدام count () للحصول على مقدار الإعجابات فقط)

SELECT * FROM actions  
WHERE actions.id_Stuff = 5  
AND actions.typeStuff="photo"  
AND actions.typeAction = "like"  

Answer #4

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

مصطلح علاقة الكيان لهذا هو "الفئة" (انظر دليل طرق ERwin ، القسم: "العلاقات بين النوع الفرعي"). رمز الفئة هو:

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

راجع للشغل ، هناك ما يقرب من 3 طرق لتنفيذ "فئة ER":

  • جميع الأنواع في جدول واحد.
  • جميع أنواع الخرسانة في جداول منفصلة.
  • جميع أنواع الخرسانة والتجريد في جداول منفصلة.

ما لم يكن لديك متطلبات أداء صارمة للغاية ، ربما يكون النهج الثالث هو الأفضل (بمعنى أن الجداول الفعلية تتطابق مع 1: 1 مع الكيانات في الرسم البياني أعلاه).


Answer #5

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

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

إذا كان هذا مشروعًا رجلًا واحدًا ، فقم ببرمجة واجهة قاعدة البيانات في عمليات بسيطة باستخدام الإجراءات المخزنة: add_user و update_user و add_comment و add_like و upload_photo و list_comments وما إلى ذلك. لا تقم بتضمين المخطط في سطر واحد من الشفرة. بهذه الطريقة ، يمكن تغيير مخطط قاعدة البيانات دون التأثير على أي رمز: يجب أن تعرف الإجراءات المخزنة فقط حول المخطط.

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


Answer #6

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

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




database-design