Newsgroup: it.comp.software.database
Titolo: Parere su struttura database

Salve a tutto il ng,
ho un parere da chiedervi sulla struttura di un database. Com'è noto a
tutti, il modello ER per la progettazione di un database prevede che ogni
tabella mappi una entità ben definita. Per esempio, se volessi rappresentare
l'entità "Cliente", potrei prevedere un record di questo tipo:
CodCli   DesCli    P_IvaCliente    CodFiscCliente  RagSoc .....
e via andare. Ora mi sono imbattuto per un progetto in una situazione in cui
un DBMS è completamente destrutturato, ossia tranne che per le chiavi
primarie, la struttura delle tabelle è simile alla seguente:
Chiave1, ... , ChiaveN, CodiceDato, ValoreDato.
Tramite CodiceDato assegno a valoreDato un significato ben preciso tramite
una tabella di anagrafica: così per la tabella cliente potrei avere una
AnagraficaValoriCliente:
Codice    Significato
001          Partita Iva
002          Codice Fiscale
003          Ragione Sociale
004          Indirizzo
e via andare; per rappresentare il cliente C anzichè avere una tupla, 
contenente i suoi dati,  ne avrei N: per ricostruire l'informazione 
completa, dovrò ricorrere a viste e join opportuni. Ora, questa struttura 
dati è certamente flessibile, ma a me sembra - al di là del fatto che resta 
per il modello ER concettualmente sbagliata - un po' un rischio per le 
performance. Il fatto è che non è la prima volta che mi imbatto in soluzioni 
di questo tipo.
Chiedo a voi un parere.
Saluti,
    Scorpio.

    Scorpio.
Ciao 

Colgo l'occasione per fare un riepilogo degli schemi/modelli etc.
(da integrare e correggere liberamente)
Concettuale (rappresentazione ad alto livello):
E/R, RM/T, UML, ORM (Object-Role Modeling), Universal Relation(?)
Logico (schema formale nel database):
Teoria Relazionale, Gerarchico, Reticolare, EAV, Binary, MVDB,
Object Oriented, XML Document
Physical Layer (strutture su disco):
Tabulare, Isam, Columnar, TransRelational, Geospatial, Multimediali,
XML file


No, non č proprio questo il caso. Anzi.
Scorpio. 

 delle concessionarie (->googlatina)
E' per caso assimilabile ad un problema che ho avuto? Un cliente ha gli
articoli che possono variare in alcune sue parti (colore, forma,
materiale), che abbiamo strutturato con una tabella correlata all'articolo
del tipo
ARTICOLO, TIPO_VARIANTE, COD_VARIANTE
1, Colore, ROS
1, Colore, BLU
1, Colore, VERD
1, Forma, ROTONDO
1, Forma, QUADRATO
2,...
9999,...
A sua volta il COD_Variante *può* avere un record correlato fra gli
articoli, ovvero la Materia Prima "colore" Rossa.
L'anno precedente venivano create combinazioni di articoli per tutti i casi
possibili, ovvero circa 200/300 mila articoli. Impossibile da manutenere
ovviamente.
C'erano soluzioni migliori?

 Io ho sostenuto lo stesso e mi volevano picchiare :-)
ahahah a far bene le cose spesso si rischia...
Se ti serve qualche riferimento autorevole, Celko dovrebbe bastare:
http://groups.google.it/groups?as_q=eav&as_ugroup=comp.databases.theory&as_uauthors=celko

 C'erano soluzioni migliori?
Normalizzare tutto; dovrebbe risultare una fatica minore.

 [...]
Saluti e grazie   Manlio Perillo

 Normalizzare tutto; dovrebbe risultare una fatica minore.
Devo dire che adesso, l'applicativo funziona abbastanza bene, certo erano
state fatte delle analisi errate in partenza, e ho dovuto poi lavorare di
codice, ma a livello di struttura va abbastanza bene, anche perchč le
tipologie di variante sono circa 10, sono fisse (da 50 anni), certo che
nell'ottica di fare uno schema "universale".

 articoli senza includermi le varianti?
Imho gli articoli base saranno PF (prodotti finiti) gli altri potrebbero
essere considerate MP (materie prime) o quello che vuoi.
Quindi sarà SELECT * FROM ARTICOLI WHERE TIPO_INVENTARIO='PF'
o qualcosa di simile.



Non mi piace perchè, nel mio schema, la colonna TIPO_INVENTARIO è 
ridondante.
Io pensavo a qualcosa tipo
SELECT * from articoli 
WHERE id_articolo NOT IN (SELECT parent_in IN varianti)
Ma mi sembra abbastanza inefficiente, considerando che è la query più 
usata.
Manlio Perillo

 usata.
Non mi intendo molto di struttura dei DB, dai tempi in cui vai a scuola e
ti spiegano le varie regole.
Purtroppo nella vita reale spesso ho bisogno di sviluppare per "ieri", e
molte raffinatezze si lasciano perdere per velocizzare/semplificare.
Di sicuro prima di fare una select NOT IN metto 3 campi inutili piuttosto.
Gią meglio se trasformi la NOT IN in una JOIN.
SELECT articoli.* 
FROM articoli  LEFT JOIN varianti ON art.id_articolo = varianti.parent_id
WHERE varianti.parent_id IS NULL
O qualcosa del genere, sto per andare in ferie... :)

 O qualcosa del genere, sto per andare in ferie... :)
Probabilmente una soluzione alternativa è aggiungere un campo, nella 
tabella articoli, 'variazione_di' dove viene memorizzato l'articolo di 
cui questa è una variazione.
Il problema è che nella maggioranza dei casi questo valore sarà NULL, e 
non è una bella cosa.
Manlio Perillo


Grazie per le dritte.
Scorpio. 

Ma che bello è lo stesso dilemma su cui mi sto scervellando in questo 
ultimo mese.
Ho visto in un db una struttura del tipo:
id	idtabella	idanalisi	valore
1	2		5		24
2	5		10		pippo
.
.
.
7	9		11		20061219
La cosa traumatica di questa struttura secondo me è la definizione del 
campo "VALORE" che per ovvie ragioni viene definito come stringa 
(addirittura come memo). Io lo trovo sbagliatissimo anche perchè se 
nella tabella identificata con ID 2 ci sono solo valori numerici sarà un 
bel casino effettuare ad esempio una media sui valori. A questo punto 
meglio una tabella con tutti i campi. Oltre a garantire la leggibilità a 
chiunque per necessità dovesse avere bisogno di un accesso diretto al 
DB, si avrebbe indubbiamente un certo incremento di prestazioni. Le 
tabelle del db hanno mediamente 30 campi l'una, sempre riempiti, per 
almeno una 10ina di tabelle. Diciamo una media di 300 record a 
inserimento. In questa tabella a oggi ci sono oltre 500.000 record 
quando con una struttura sicuramnte più lunga da generare si sarebbe 
avuto un numero inferiore di record per tabella. Oltretutto questo 
sistema è indubbiamente comodo se la struttura della tabella non è mai 
definita ma di contro le prestazioni e le chiavi avranno grossi problemi.
Che ne dite?

 chiavi avranno grossi problemi.
Beh, discorso molto simile all'EAV: e` comodo solo in fase di
inserimento e definizione dello schema, ma di contro e` terribile
in tutte le altre fasi.
Oltre ai discorsi facilita`/prestazioni, quello che realmente deve
far preoccupare e` che un design di questo tipo e` estremamente
debole dal punto di vista della qualita` dei dati.

 debole dal punto di vista della qualita` dei dati.
Pensa che chi ha progettato il database che ho citato all'inizio del 3d, 
dice
che l'utilizzo di tabelle cosě destrutturate addirittura agevola le 
prestazioni.
Il mondo č davvero molto vario.
Scorpio. 

 Il mondo è davvero molto vario.
Eppure io ne vedo un mucchio di database così... Sembra quasi che questo 
sia il "nuovo" orientamento per realizzare le strutture dei DB.

 debole dal punto di vista della qualita` dei dati.
Una variante in un DB che ho visionato era la presenza di una colonna 
per ogni tipo di dato:
id	idtabella	idcolonna	valore_stringa	valore_numerico	valore_data
Mi pare che terminasse così.

 sia il "nuovo" orientamento per realizzare le strutture dei DB.
In effetti questo design e` un mix tra l'immediatezza di comprensione
e implementazione, ed il fascino oscuro di non dover sbattersi
a studiare. Ne prevedo un costante successo. 

 Il mondo č davvero molto vario.
Il mondo e` bello perche' e` avariato.

 id idtabella idcolonna valore_stringa valore_numerico valore_data
Cappero... si e` evoluto! 

 Cappero... si e` evoluto! 
Eheheheheh solo che a ogni insert o update ti devi testare se il valore 
è un numero, un testo o una data o più semplicemente ti crei una tabella 
correlata al campo idcolonna con la tipologia di dato richiesto... ma 
che casino... adesso poi che le tabelle si possono modificare più 
facilmente inserendo le colonne non per forza alla fine... bah non so se 
ha senso... certo che se i dati necessari nella tabella variano spesso 
forse è un problema la struttura tabellare a vantaggio della struttura 
più dinamica.
Ma se la struttura fosse questa di cui stiamo parlando... ma esiste una 
procedura tipo il "trasponi" di excel che ti crea la tabella? perchè 
così sarebbe molto meglio...