क्या PostgreSQL के Ltree मॉड्यूल थ्रेडेड टिप्पणियों के लिए एक अच्छा फिट है?

Question

मैं थ्रेडेड टिप्पणियों में सहायता के लिए मेरे आवेदन में PostgreSQL के Ltree module का उपयोग करने पर विचार कर रहा हूं। मैं थ्रेडेड टिप्पणियों के लिए उपयोग करने के लिए थोड़ी देर के लिए इसे खा रहा हूं। मुझे लगता है कि यह उन मामलों के साथ मदद करेगा जहां आपको नोड और उसके बच्चों को अपडेट करने की आवश्यकता है, जैसे कि जब आप कोई टिप्पणी और उसके उत्तरों को छिपाना चाहते हैं।

मैं ltree (या ऐसा कुछ) सोच रहा हूं, यह उपयोगी होगा अगर यह एक पारंपरिक आसन्नता सूची ("comment_id"/"parent_comment_id") के साथ मिलकर उपयोगी हो।

1. , आप हैं या आप, ltree का इस्तेमाल किया है:

   ltree का उपयोग कर में डुबकी लेने से पहले, मैं कुछ चीजें सोच रहा हूँ? क्या यह "उत्पादन तैयार" कह सकता है?

2. यदि हां, तो हल करने के लिए आप किस समस्या का उपयोग करते थे? क्या यह अच्छा काम करता है?
3. क्या आपको लगता है कि यह थ्रेडेड टिप्पणी प्रणाली के लिए एक अच्छा फिट है?
   4. यदि आपने इसका इस्तेमाल किया, तो आपने पथ के "पाठ" भाग के लिए क्या उपयोग किया? क्या आपने डीएमओजेड उदाहरण की तरह कुछ स्थापित किया है, तो वे "टॉप.एस्ट्रोनोमी। कॉस्मोलॉजी" का उपयोग करते हैं या इसे प्राथमिक कुंजी "1.403.29.5" जैसे किसी आधार पर आधार देते हैं?
   5. क्या ऐसा करने का कोई बेहतर तरीका है? मैं एक नेस्टेड सूची दृष्टिकोण का उपयोग करके थोड़ा परेशान हूं - मैंने जो कुछ भी पढ़ा है, वह सुझाव देता है कि यह अद्यतन या इन्टरनेट के साथ गर्म नहीं है (क्या आपको पूरी चीज़ को फिर से व्यवस्थित नहीं करना है?)। मैं एक सीएस प्रमुख भी नहीं हूं और इस तरह की डेटा संरचना भविष्य में कुछ भूल सकती है। क्या कोई टिप्पणी के लिए नेस्टेड सूचियों का उपयोग कर रहा है या ऐसा कुछ है?

अगर यह किसी भी मदद की है, यहाँ स्कीमा मैं विचार कर रहा हूँ है:

:

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 
); 

"पथ" स्तंभ, ltree द्वारा इस्तेमाल किया, कुछ ऐसा दिखाई देगा

<thread_id>.<parent_comment_id_#1>.<parent_comment_id_#2>.<my_comment_id> 

क्या पथ में प्राथमिक कुंजी का उपयोग करने में कुछ गड़बड़ है? क्या मुझे पथ में नोड की अपनी प्राथमिक कुंजी शामिल करनी चाहिए? अगर मैंने किया, तो क्या यह एक बाधा के रूप में सेवा करने के लिए एक अद्वितीय सूचकांक डालने का अर्थ होगा?

Answer 1

1. हाँ और हाँ;
2. ज्ञान आधार में अनुभागों का पदानुक्रम (कार्यान्वयन में से एक);
3. हां;

प्रश्न में तालिकाओं में से एक की परिभाषा:

            Table "knowledgebase.section" 
      Column   |   Type   |         Modifiers 
----------------------------+--------------------------+----------------------------------------------------------------------------- 
section_sid    | integer     | not null default nextval('knowledgebase.section_section_sid_seq'::regclass) 
section     | character varying  | not null 
description    | character varying  | 
path      | ltree     | not null 
is_active     | boolean     | not null default true 
role_sid     | integer     | not null 
last_modified_by   | integer     | not null 
creation_datetime   | timestamp with time zone | not null default now() 
last_modification_datetime | timestamp with time zone | not null default now() 
is_expanded    | boolean     | not null default false 
section_idx    | tsvector     | 
Indexes: 
    "section_sid_pkey" PRIMARY KEY, btree (section_sid) 
    "section_section_key" UNIQUE, btree (section) 
    "idxsection_idx" gist (section_idx) 
    "path_gist_idx" gist (path) 
Foreign-key constraints: 
    "last_modified_by_fkey" FOREIGN KEY (last_modified_by) REFERENCES "user"."role"(role_sid) ON UPDATE CASCADE ON DELETE RESTRICT 
    "role_sid_fkey" FOREIGN KEY (role_sid) REFERENCES "user"."role"(role_sid) ON UPDATE CASCADE ON DELETE RESTRICT 
Triggers: 
    section_idx_update BEFORE INSERT OR UPDATE ON knowledgebase.section FOR EACH ROW EXECUTE PROCEDURE tsearch2('section_idx', 'section') 

"पथ" स्तंभ लेबल के रूप में प्राथमिक कुंजी का उपयोग करता है।

कि मेज की वर्तमान सामग्री (प्राथमिक कुंजी और "पथ" स्तंभ के बारे में) का एक नमूना:

section_sid | path 
-------------+------- 
      53 | 34.53 
      56 | 56 
      55 | 29.55 
      35 | 35 
      54 | 34.54 
      37 | 30.37 
      ... | ... 

Answer 2

पोस्टग्रेएसक्यूएल का संस्करण 8.4 WITH और WITH... RECURSIVE अभिव्यक्तियों के साथ कोर में सामान्य तालिका अभिव्यक्ति कार्यक्षमता लाएगा। यदि आप पुराने कोड को संशोधित कर रहे हैं, तो आप 8.4 तक जारी होने तक प्रतीक्षा कर सकते हैं, तब तक आपको लेट्री और नए कोर सिंटैक्स के बीच किसी भी असंगतताओं के बारे में चिंता करने की आवश्यकता नहीं होगी। यदि आप पुराने कोड के साथ काम कर रहे हैं, या 8.4 के लिए इंतजार नहीं करना चाहते हैं, तो आप शायद यह सुनिश्चित करना चाहते हैं कि आप कोड लिखें जो आसानी से नए वाक्यविन्यास के लिए अनुवाद योग्य है, खासकर यदि आप पुरानी स्कीमा बदल रहे हैं या एक नया डिजाइन कर रहे हैं एक।

यह भी देखें:

• The 8.4 manual entry on WITH queries and CTEs
• A writeup with examples on the 8.4 implementation of CTEs

Answer 3

मेरा सुझाव है एसक्यूएल में श्रेणीबद्ध संबंधों को लागू किसी Joe Celko's Trees and Hierarchies in SQL for Smarties पढ़ें।

Traversing मनमाना गहराई माता-पिता बच्चे को लिंक बहुत अक्षम जब सिर्फ एक PARENT_ID का उपयोग कर किया जा सकता है। पुस्तक उन तकनीकों का वर्णन करती है जो इस पहुंच को तेजी से बनाती हैं।

एक रणनीति (जो मैं उपयोग करने के लिए होता है) भी लेख की इस श्रृंखला में मुक्त करने के लिए पाया जा सकता है:

• Part 1 (अनुभाग "एसक्यूएल में पेड़" के लिए देखो) (Wayback link)
• Part 2 (Wayback link)
• Part 3 (Wayback link)
• Part 4 (Wayback link)