معظم هيكل البيانات كفاءة لتمثيل التعليقات الخيوط في جافا؟

Question

أريد أن تمثل التعليقات الخيوط في جاوة. هذا من شأنه أن يبدو مشابها للطريقة التي يرتبط بها التعليقات reddit.com.

hello
   hello
      hello
      hello
   hello
   hello
      hello

كما في المثال أعلاه، يتم تداخل الردود في HTML مع المسافة البادئة المناسبة لتعكس علاقتها بالتعليقات السابقة.

ماذا ستكون طريقة فعالة لتمثيل هذا في جافا؟

أنا أفكر نوعا ما من هيكل بيانات شجرة سيكون مناسبا.

ولكن هل هناك واحد على وجه الخصوص الذي سيكون الاكثر فعاليه لتقليل اجتيازات شجرة؟

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

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

Answer 1

أود استخدام مستويات القوائم المرتبطة.

message1
    message2
        message3
        message4
    message5
    message6
        message7

سيكون لكل عقدة مؤشرا له:

- forward sibling  (2->5, 3->4, 5->6,                   1/4/6/7->NULL).
- backward sibling (4->3, 5->2, 6->5,                   1/2/3/7->NULL).
- first child      (1->2, 2->3, 6->7,                   3/4/5/7->NULL).
- parent           (2->1, 3->2, 4->2, 5->1, 6->1, 7->6,       1->NULL).

داخل كل مستوى، سيتم فرز الرسائل في القائمة عن طريق عدد الأصوات (أو أي درجة أخرى تريد استخدامها).

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

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

• message2 -> message6
• message6 -> message5
• message5 -> NULL.

تحصل:

message1
    message2
        message3
        message4
    message6
        message7
    message5

إذا استمر حتى يصاب بصوت أكثر message2, ، يحدث ما يلي:

• message6 -> message2
• message2 -> message5

و مؤشر الطفل الأول message1 تم تعيين إلى message6 (كان message2)، لا يزال سهلا نسبيا، للحصول على:

message1
    message6
        message7
    message2
        message3
        message4
    message5

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

Answer 2

الشجرة هي صواب (مع getLastsiblings و getnextsibling)، ولكن إذا كنت تخزين / استعلام البيانات، فمن المحتمل أنك تريد تخزين سلالة لكل إدخال، أو رقم بواسطة اجتياز Preventer:

http://www.sitepoint.com/article/hierarchical-data-database/2/

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

أنظر أيضا:

SQL - كيفية تخزين وتنقل التسلسلات الهرمية؟ http://www.ibase.ru/devinfo/dbmstrees/sqltries.html. (هذا المخطط يدعو أيضا شجرة Celko)

Answer 3

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

يبدو وكأنه التحسين المبكر بالنسبة لي، ربما حتى التحسين الخاطئ.

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