Modelul listei de adiacență vs. Modelul de seturi imbricate pentru datele ierarhice MySQL? (Programare, Mysql, Model De Seturi Imbricate, Modelul Listei De Adiacență)

Gustavo Piucco a intrebat.

Există două moduri de a lucra cu date ierarhice în MySQL:

  1. Modelul listei de adiacență
  2. Modelul de seturi imbricate

O problemă majoră a modelului Modelul listei de adiacență este că trebuie să executăm o interogare pentru fiecare nod pentru a obține calea ierarhiei.

În modelul Modelul de seturi imbricate această problemă nu există, dar pentru fiecare nod adăugat este necesar să se dea o actualizare MySQL UPDATE pe toate celelalte noduri. stânga și dreapta valoare.

Datele mele ierarhice nu sunt date statice, cum ar fi categoriile de produse din comerțul electronic. Sunt înregistrarea constantă a utilizatorilor în secvență ierarhică.

În aplicația mea, în timp ce există multe înregistrări constante ale utilizatorilor, am nevoie, de asemenea, să obțin calea ierarhică până când ajung la primul nod din ierarhie.

Analizând situația mea, care dintre cele două alternative ar fi cea mai bună pentru aplicația mea?

1 răspunsuri
Renzo

Modelul de seturi imbricate nu mai este astăzi utilizat în mod obișnuit în bazele de date, deoarece este mai complex decât modelul listei de adiacență, dat fiind faptul că necesită gestionarea a doi „pointeri” în loc de unul singur. De fapt, Modelul seturilor imbricate a fost introdus în bazele de date atunci când era complex sau imposibil să se facă interogări recursive care să traverseze o ierarhie.

Începând cu 1999, SQL standard include așa-numitele expresii comune de tabel recursive, sau Recursive CTE (Recursive Common Table Expressions), care simplifică (și standardizează!) realizarea interogărilor care traversează calea recursivă într-o ierarhie cu orice număr de niveluri.

Toate marile sisteme DBMS au inclus acum această caracteristică, cu o excepție notabilă: MySQL. Dar în MySQL puteți depăși această problemă prin utilizarea procedurilor stocate. A se vedea, de exemplu, această postare de pe StackOverflow sau această postare de pe dba.stackexchange.

Deci, pe scurt, acestea sunt sfaturile mele:

  1. Dacă încă mai puteți decide ce SGBD să folosiți, luați în considerare cu tărie unele alternative: de exemplu, dacă doriți să rămâneți la o bază de date open source, utilizați PostgreSQL, folosiți modelul Adiacency List Model și folosiți CTE-uri recursive pentru interogările dvs.
  2. Dacă nu puteți schimba SGBD-ul, ar trebui totuși să folosiți modelul Adiacency List Model și să utilizați proceduri stocate precum cele citate în referințe.

UPDATE

Această situație se schimbă odată cu MySQL 8, care este în curs de dezvoltare și care va integra CTE-uri recursive, astfel încât, începând cu acea versiune, Adiacency List Model va fi mai simplu de utilizat.

Comentarii

  • Dacă mai contează, MySQL 8, aflat în prezent în dezvoltare, va avea suport pentru interogări CTE recursive. –  > Por Bill Karwin.
  • @BillKarwin, mulțumesc mult pentru informații, am actualizat răspunsul. –  > Por Renzo.