Olimpo Informatico

[freemind]

Buonasera forum,
sono qui per discutere con voi sull'approccio da utilizzare per una parte di database che sto preparando.

Il post è un po' lungo quindi se non avete tempo/voglia di leggerlo, non iniziate neppure perchè è una rottura di scatole per me, figuriamoci per voi...

Lo scopo
Il programma dovrà memorizzare in un db (al momento non importa che tipo di dbms anche se sarà relazionale) un certo numero di informazioni più o meno complesse.
Queste informazioni saranno di vario tipo e disomogenee tra loro.
Ci sarà la possibilità di catalogarle in vari modi, raggrupparle etc...

Il problema
Al db mi ci attaccherò tramite Active Record e fin qui no problem.
La struttura che riguarda queste informazioni è schematizzata qui sotto:



I rettangoli rappresentano le tabelle (nel layer fisico, non quello logico).
L'informazione è rappresentata dalla tabella node e questa conterrà tutte le colonne comuni a tutti i tipi di informazione (id, nome, descrizione, data di creazione, utente etc...).
Linkate 1:1 a questa ci saranno tante tabelle node_<type> e nell'immagine di esempio abbiamo che type vale file oppure text.
Questa struttura è giustificata dal fatto di dover rappresentare tramite classi le tabelle e soprattutto perchè i nodi devono poter essere gestiti in maniera globale quando si fanno le ricerche semplici (in pratica quelle sulla tabella node) ma anche in maniera specifica quando si parla di un certo tipo.
Inoltre non c'è motivo di riportare tutte le colonne comuni in tutte le tabelle dei tipi perchè si avrebbe solo ridondanza dato che tramite active record è possibile simulare determinati tipi di ereditarietà che nel mio caso è una sorta di Class Inheritance Strategy.

Ora, sarà necessario implementare 3 tipi di ricerche: semplice, avanzata e specifica.

La semplice, come detto prima, riguarda di fatto tutte le informazioni contenute nella tabella node e non entrà nel dettaglio dei singoli campi (se volgiamo vederla in sql potremmo pensare ad una select che confronta tutte colonne al valore del filtro con una like bilaterale).

Le altre due verranno qui sotto descritte.

I vari tipi di nodo avranno almeno un campo che rappresenta il contenuto principale dello stesso (per i testi sarà proprio il testo, per un file il suo contenuto) ma ogni tipo avrà potenzialmente un numero diverso di questi campi.

Dato che il sistema finale dovrà esser plasmabile, deve essere possibile a regime poter aggiungere altri tipi di nodo senza dover tutte le volte ritoccare il motore di ricerca perchè se no dopo due volte uno sviluppatore si impicca.

La ricerca avanzata dovrà cercare dentro ai campi di node tramite un filtro evoluto (del tipo: nome=...., descrizione=...., data di creazione compresa tra... e ... etc...) e dentro questi campi (indipendentemente dalla tabella di appartenenza).
E' chiaro che se questi fossero definiti dentro le specifiche tabelle, per ogni nuovo nodo corrisponderebbe un nuovo pezzo di codice del motore di ricerca mentre qui si vuole evitare che il core venga ripreso più del dovuto.

Io ho pensato allora ad una sorta di EAV.
Questo tipo di struttura per quanto dinamica sia a me piace poco perchè molto pesante da gestire e molto lenta dato che non è possibile risalire ad una riga con una sola query; resta il pregio appunto di poter essere plasmabile a piacimento e soprattutto a parità di tipo non è detto che il numero di attributi sia lo stesso.
A me non interessa questa caratteristica perchè se è vero che ogni tipo di nodo avrà un certa struttra, questa è nota a priori e comunque sempre uguale per tutte le istanze dello stesso tipo.

Normalmente l'idea base dell'EAV prevede che per ogni tipo di attributo ci sia una tabella apposta perchè non ha senso mettere una data dentro ad un longblob (per dirne uno) e questo normalmente complica ulteriormente le cose.

Io però non sono riuscito a trovar nulla di meglio di questo e ho schematizzato la cosa così:




Alla tabella node si vedono linkate in 1:n alcune tabelle fulltext_attribute_[n] con n un certo tipo di dato (int, varchar, text, date etc...) che conterranno gli attributi di tipo n per i vari nodi.
Per esempio qui dentro per i nodi di tipo file ci saranno delle righe nella tabella fulltext_attribute_longblog nella forma: id, node_id, name con i rispettivi valori dentro a fulltext_value_logblob nella forma attribute_id,value.

La ricerca specifica, infine, cercherà dentro ai nodi di un certo tipo di tirerà in ballo tutte le tabelle interessate da quel tipo quindi il fatto di avere questa struttura così strana non è un problema.

Ora, dopo tutto questo papiro la domanda è:
Avete un'idea migliore?

Spero di esser stato chiaro.

Bau

[SverX]

Dato che un requisito è

[freemind]

Purtroppo non mi sta venendo in mente nulla di diverso...

Comunque proprio semplice non è gestire una roba del genere con un AR: vorrei arrivare ad avere le istanze dei sottotipi già con al loro interno le proprietà sparse per le varie tabelle di appoggio mantenendo l'active record stabile (quindi senza perdere le sue caratteristiche).

Bau

[freemind]

Pensa pensa pensa...
Dunque, studiando un po' il manuale dell'active record che andrò ad usare ho scoperto un po' di cosine interessante tra cui il modo di accedere ai metadati delle tabelle che l'ar usa per determinare la strutture delle tabelle.
Ebbene, sono riuscito in una simulazione di prova, sfruttando le informazioni suddette a evitare di dover costruire quella struttura così infame.
Posso salvare i vari campi nelle tabelle node_<type> e con il motore di ricerca a costruire la mega-query di ricerca determinando per ogni tabella le colonne che mi interessano evidenziandole in qualche modo (tutti i nomi iniziano per un prefisso oppure la classe corrispondente avrà una proprietà che elenca queste colonne).

Facendo così sono riuscito a trovare una forma più naturale sia per il db che per il layer logico.

bau