Entitate cu design de performanță a bazelor de date personalizate

Trebuie să construiesc o aplicație în care există entități generice (să spunem articole, pagini, noduri ) unde utilizatorul poate adăuga câmpuri personalizate.

Am văzut abordarea pe care o utilizează cel mai popularul CMS (wp, drupal) pentru a obține acest obiectiv; Toate acestea au tabelul de bază cu câmpurile minime (de exemplu, titlul și corpul) și apoi deletesc toate celelalte câmpuri în alte tabele, de exemplu:

table node
id | title | body

table field_foo
node_id | field_type | field_value

table field_bar
node_id | field_type | field_value
// and so on

Acest lucru, într-un mediu plin de mvc este destul de logică; Controlerul de câmp manipulează fiecare câmp separat.

Dar vorbind despre performanță, încărcarea unui singur nod va necesita mai multe interogări - sau multe conexiuni.

Am luat o altă abordare (chiar și pentru că aplicația mea nu oferă niciun câmp de bază): pentru fiecare câmp i se adaugă o nouă coloană pe tabela de bază care va stoca o valoare brut , apoi un tabel pentru fiecare câmp care are nevoie de el (mai multe câmpuri, de exemplu, sau trimitere la alte entități) și un tabel relație cu doar indexuri entity_id | field_id (tabelul respectiv face de fapt alte tipuri de locuri de muncă, ca urmare a versiunilor și a relațiilor dintre entități)

Deci, cu o singură interogare, obțin toate datele prime dintr-o entitate, atunci controlorul de câmp știe (când este necesar) cum și unde să încarce valorile real din acele câmpuri.

Tipul coloanei din tabelul date (table_entity_data) este cea mai bună estimare pentru datele câmpului: pentru text este text, pentru zecimal este zecimal; numai pentru mai multe câmpuri (care au valoarea lor în afara tabelului) este array (iar tipul real de date este în coloana _field_foo_value.entity_value_)

Presupunând că structura entității nu se va schimba de multe ori, am încercat să normalizez structura.

Având în vedere că alte proiecte mari se ocupă de acest lucru într-un mod foarte diferit, am ajuns să mă îndoiesc de implementarea mea și mă întrebam ce fel de problemă se va întâmpla cu structura mea hibryd :

table entity
id

table entity_data
entity_id | field_foo_rav_value | field_bar_raw_value

table relations
entity_id | entity_field_id | field_id_value

table field_foo_value
field_value_id | entity_value

// lets say field_bar is a single text field, there no will be another table:
// entity_data.field_bar_raw_value contains the real value

Vreo idee?

p.s: stiu ca aceasta intrebare este generica cu amabilitate, nu ezitati sa semnalizati daca nu este cazul.

2

1 răspunsuri

Se pare că reinventați EAV

http://www.google.com/search?q=entity+attribute + valoare + antipattern

Dezavantajele sunt că eliminați toate tipurile de siguranță și structură pe care o bază de date relațională le poate oferi.

Într-o lume ideală, probabil că doriți unul dintre:

  1. Permiteți construirea unei mese adecvate
  2. Utilizați o bază de date non-relațională
2
adăugat
Dezavantajele sunt faptul că eliminați toate tipurile de siguranță și structură pe care le poate furniza o bază de date relațională. mmmh nu, im folosind tipul datat corect, nu am vorbit despre asta .. lasă-mă să-mi actualizez întrebarea
adăugat autor Strae, sursa
PostgreSQL - comunitatea Română
PostgreSQL - comunitatea Română
5 participanți

Comunitatea română a programatorilor PostgreSQL.