كيف يمكنني تنفيذ تعليقات الخيوط؟

Question

أقوم بتطوير تطبيق ويب يمكنه دعم التعليقات الخيوط. أحتاج إلى القدرة على إعادة ترتيب التعليقات بناء على عدد الأصوات الواردة. (مماثلة لرئيس التعليقات الخيوط تعمل في reddit)

أحب أن أسمع المدخلات من المجتمع حتى في كيفية القيام بذلك.

كيف يمكنني تصميم تعليقات جدول؟ هنا هي الهيكل الذي أستخدمه الآن:

Comment
    id
    parent_post
    parent_comment
    author
    points

ما هي التغييرات التي يجب القيام بها لهذا الهيكل؟

كيف يمكنني الحصول على التفاصيل من هذا الجدول لعرضها بالطريقة الصحيحة؟ (التنفيذ بأي لغة موضع ترحيب. أريد فقط أن أعرف كيفية القيام بذلك بأفضل طريقة ممكنة)

ما هي الأشياء التي أحتاج إليها لرعاية أثناء تنفيذ هذه الميزة بحيث يكون هناك تحميل أقل في وحدة المعالجة المركزية / قاعدة البيانات؟

شكرا مقدما.

Answer 1

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

يحتوي الجدول الخاص بك على ميزة يمكنك جلب جميع التعليقات على وظيفة في 1، عن طريق التصفية على potionpost. كما حددت الوالد التعليق في كتاب الكتب المدرسية / ساذجة، يجب عليك بناء الشجرة في الذاكرة (انظر أدناه). إذا كنت ترغب في الحصول على الشجرة من DB، فأنت بحاجة إلى طريقة مختلفة لتخزين الشجرة: راجع وصفي لنهج مسبق Calc القائم هنا:http://www.llblgen.com/tinyforum/gotomessage.aspx؟messageid=17746&threadid=3208.او بواسطة باستخدام أشجار متوازنة وصفها Celko هنا:

أو نهج آخر:http://www.sqlteam.com/article/mor-tries-herarchies-in-sql.

إذا جلبت كل شيء في تسلسل هرمي في الذاكرة وبناء الشجرة هناك، فقد يكون الأمر أكثر كفاءة بسبب حقيقة أن الاستعلام بسيط للغاية: حدد .. من التعليق حيث protePost = @ order by palentComment ASC

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

Answer 2

أشياء زوجين للتعبير أيضا ...

1) عندما تقول "نوع مثل Reddit" بناء على المرتبة أو التاريخ، هل تعني المستوى الأعلى أو كل شيء؟

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

لقد كنت أبحث في ltree. وحدة لل postgresql. يجب أن تجعل عمليات قاعدة البيانات التي تنطوي على أجزاء من الشجرة أسرع قليلا. يتيح لك أساسا إنشاء حقل في الجدول يشبه:

ltreetest=# select path from test where path <@ 'Top.Science';
                path                
------------------------------------
 Top.Science
 Top.Science.Astronomy
 Top.Science.Astronomy.Astrophysics
 Top.Science.Astronomy.Cosmology

ومع ذلك، لا يضمن أي نوع من النزاهة المرجانية من تلقاء نفسها. بمعنى آخر، يمكنك الحصول على سجلات ل "Top.science.astronomy" دون وجود سجل ل "Top.science" أو "Top". ولكن ما يسمح لك به هو أشياء مثل:

-- hide the children of Top.Science
UPDATE test SET hide_me=true WHERE path @> 'Top.Science';

أو

-- nuke the cosmology branch
DELETE FROM test WHERE path @> 'Top.Science.Cosmology';

إذا كان جنبا إلى جنب مع نهج "التعليقات" التقليدية / "Parent_id" باستخدام الإجراءات المخزنة، فأنا أفكر في أنه يمكنك الحصول على أفضل ما في العالمين. يمكنك بسهولة اجتياز شجرة التعليق في قاعدة البيانات باستخدام "مسار" وما زلت تضمن تكامل مرجعي عبر "تعليق_ID" / "PARTER_ID". أتصور شيء مثل:

CREATE TABLE comments (
comment_id SERIAL PRIMARY KEY,
parent_comment_id int REFERENCES comments(comment_id) ON UPDATE CASCADE ON DELETE CASCADE,
thread_id int NOT NULL  REFERENCES threads(thread_id) ON UPDATE CASCADE ON DELETE CASCADE,
path ltree NOT NULL,
comment_body text NOT NULL,
hide boolean not null default false
);

تبدو سلسلة المسار للتعليق

<thread_id>.<parent_id_#1>.<parent_id_#2>.<parent_id_#3>.<my_comment_id>

وبالتالي، فإن التعليق الجذر لمؤشر الصفحات "102" مع تعليق "1" سيكون له طريق من:

102.1

والطفل الذي هو "3" هو:

102.1.3

بعض الأطفال من "3" وجود معرف "31" و "54" سيكون:

102.1.3.31
102.1.3.54

لإخفاء العقدة "3" وأطفالها، كنت تصدر هذا:

UPDATE comments SET hide=true WHERE path @> '102.1.3';

أنا dunno على الرغم من - قد يضيف النفقات العامة دون ديع. بالإضافة إلى أنني لا أعرف مدى الحفاظ على LTREE جيدا.

Answer 3

تصميمك الحالي جيد أساسا التسلسلات الهرمية الصغيرة (أقل من ألف عنصر)

إذا كنت ترغب في جلب على مستوى Certian أو عمق، أضف عنصر "مستوى" إلى هيكلك وحسب حجمه كجزء من حفظ

إذا كان الأداء مشكلة استخدام ذاكرة التخزين المؤقت لائقة

Answer 4

أضف الحقول الجديدة التالية إلى Tabel أعلاه:

• Thread_id: معرف لجميع التعليقات المرفقة كائن معين

• التاريخ: تاريخ التعليق (يسمح بتقديم التعليقات بالترتيب)

• رتبة: التعليق المرتبة (يسمح بإحضار أمر التعليق حسب الترتيب)

باستخدام هذه الحقول ستكون قادرا على:

1. جلب جميع التعليقات في مؤشر ترابط واحد
2. ترتيب التعليقات في موضوع إما عن طريق التاريخ أو المرتبة

لسوء الحظ، إذا كنت ترغب في الحفاظ على استفساراتك DB قريبة من SQL Standard، فستحصل على إعادة إنشاء الشجرة في الذاكرة. تقدم بعض DBS استفسارات خاصة للبيانات الهرمية (Fe Oracle)

./alex.