Ist PostgreSQLs ltree Modul eine gute Passform für Gewinde Kommentare?

StackOverflow https://stackoverflow.com/questions/603894

Frage

Ich betrachte mit PostgreSQL ltree Modul in meinem Anwendung mit Gewinde Kommentare zu helfen. Ich habe für eine Weile mustert es für Gewinde Kommentare zu verwenden. Ich schätze es mit Fällen helfen würde, in dem Sie einen Knoten und seine Kinder aktualisieren müssen, wie wenn Sie einen Kommentar und ihre Antworten zu verbergen.

Ich denke ltree (oder so ähnlich), es wäre nützlich, wenn sie mit einer traditionellen Adjazenzliste ( „comment_id“ / „parent_comment_id“) gekoppelt wurde.

Vor dem Sprung in dem mit ltree nehmen, ich frage mich, ein paar Dinge:

  1. Sind Sie, oder haben Sie verwendet ltree? Ist es das, was man nennen könnte „Produktion bereit“?
  2. Wenn ja, welche Probleme haben Sie dabei, es zu lösen? Hat es einen guten Job machen?
  3. Halten Sie es für eine gute Passform für a Gewindekommentarsystem?
    1. Wenn Sie es verwendet, was haben Sie dabei für den „Text“ einen Teil des Weges? Haben Sie so etwas wie DMOZ Beispiel einrichten sie „Top.Astronomy.Cosmology“ oder stützen sie auf so etwas wie der Primärschlüssel „1.403.29.5“?
      2. verwenden
    2. Gibt es einen besseren Weg, dies zu tun? Ich bin ein bisschen nervös, eine verschachtelte Liste Ansatz - alles, was ich gelesen habe, lässt vermuten, dass es ist nicht alles zu heiß mit Aktualisierungen oder Einfügungen (nicht Sie die ganze Sache neu zu ordnen haben?). Ich bin auch keine CS-Dur und diese Art von Datenstruktur ist etwas, was ich in der Zukunft vergessen könnte. Ist jemand mit verschachtelten Listen für Kommentare oder etwas ähnliches?

Wenn es keine Hilfe, hier ist das Schema Ich erwäge: 

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

Die "Pfad" Spalte von ltree verwendet, würde in etwa so aussehen: 

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

Gibt es etwas falsch mit dem Primärschlüssel im Pfad? Sollte ich auf dem Weg einschließlich der eigenen Primärschlüssel der Knoten sein? Wenn ich das täte, würde es Sinn machen, einen eindeutigen Index auf sie setzt als Einschränkung zu dienen?

War es hilfreich?

Lösung

  1. Ja und ja;
  2. Hierarchie von Abschnitten in einer Wissensbasis (eine der Implementierungen);
  3. Ja;

Die Definition von einem der Tische in Frage: 

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

Die „Pfad“ Spalte verwendet den Primärschlüssel als Etikett.

Eine Probe von dem aktuellen Inhalt der Tabelle (in Bezug auf die Primärschlüssel und die „Pfad“ Spalte): 

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

Andere Tipps

Ich empfehle jedem hierarchischen Beziehungen in SQL Implementierung lesen Joe Celko der Bäume und Hierarchien in SQL für Smarties .

Links beliebige Tief Eltern-Kind-Verfahrgeschwindigkeit kann sehr ineffizient sein, wenn nur eine parent_id verwenden. Das Buch beschreibt Techniken, die diesen Zugang schnell zu machen.

Eine Strategie (die ich verwenden passieren) kann auch kostenlos in dieser Serie von Artikeln zu finden:

Version 8.4 von PostgreSQL wird Common Table Expressions-Funktionalität in den Kern mit WITH und WITH... RECURSIVE Ausdrücke werden zu bringen. Wenn Sie alten Code sind zu modifizieren, sollten Sie warten, bis 8.4 freigegeben wird, wie dann werden Sie nicht über Unverträglichkeiten zwischen ltree kümmern und der neuen Core-Syntax. Wenn Sie mit alten Code arbeiten, oder wollen nicht für 8.4 warten, werden Sie wahrscheinlich sicherstellen möchten Sie Code schreiben, leicht übersetzbar in die neue Syntax ist, vor allem, wenn Sie ein altes Schema sind zu ändern oder eine neue Gestaltung ein.

Siehe auch:

scroll top