Newsgroup: it.comp.software.database
Titolo: modellare un albero con DB

come fareste per raccogliere dati in maniera gerarchica?
mi spiego: a partire da delle categorie di livello più elevato, per 
esempio
- lavoratori
- studenti
- pensionati
...
e poi, per i lavoratori:
- artigiani
- autonomi
- dipendenti
e poi, per gli autonomi:
-informatici
-commercialisti
...
insomma creare una struttura che preveda l'incapsulamento di ogni 
sottocategoria dentro una categoria.
pensavo una cosa del tipo:
categoria(nomePK)
sottocategoria(nomePK, categoriasuperiore)
ma c'è il problema che una sottocategoria potrebbe far parte di 
diverse categorie, il che però potrebbe anche andar bene ma non 
sempre. e non parliamo del fatto che si potrebbe cambiare idea in un 
secondo momento e voler inserire una categoria da un'altra parte...
come consigliereste di fare?
non chiedo la soluzione, ma piuttosto un parere se col costrutto 
"check" o con i trigger riesco a gestire la cosa, poi me li studio 
io, non voglio approfittare di consulenze gratuite :-))
spero di esser stato chiaro e grazie OO a chi mi risponderà!
-- 
minollo
http://www.youtube.com/watch?v=uuOc7Eopiw4

 diverse categorie, 
questo complica le cose, devi usare almeno una tabella aggiuntiva, io
farei così:
tabella categorie:
id_categoria
categoria
altri dati
tabella parentele:
id
id_categoria_figlio
id_categoria_padre
dove figlio e padre sono entrambe relative ad id_categoria della prima
tabella. 
selezione di tutti i figli  di una categoria X :
select * from categorie as c join parentele as p on
p.id_categoria=c.id_categoria_figlio where p.id_categoria_padre=X
selezione di tutti i padri di una categoria Y:
select * from categorie as c join parentele as p on
p.id_categoria=c.id_categoria_padre where p.id_categoria_figlio=Y
per non fare casini suggerirei di mettere id_categoria_figlio e
id_categoria_padre come foreign keys ad id_categoria con la clausola on
delete cascade.

 prima tabella. 
ok, lavoro su questo spunto.
grazie e complimenti per la risposta record.
Codd vi fa una pippa (scherzo, ringraziamenti anche al "nostro")
-- 
minollo
http://www.youtube.com/watch?v=uuOc7Eopiw4

 Codd vi fa una pippa 
eh beh!

L'articolo fa la "solita", ormai obbligatoria, confusione
tra concetti differenti: prima parla di database SQL, poi vi si
riferisce come "modello relazionale". Tragica differenza.
Successivamente la dose aumenta affermando che le tabelle sono
semplicemente una "flat list", facendo confusione tra rappresentazione
grafica delle tabelle e relativa interpretazione (le tabelle
rappresentano relazioni di grado N in cui N e` un arbitrario numero di
dimensioni, altro che flat!).
La confusione tra livello fisico e logico prosegue alla grande tirando
in ballo l'XML, ormai una baldracca in svendita (dove sono i "dbms
XML" che dovevano seppellire gli altri? Ma lo sa che il modello
relazionale e` stato introdotto per rimpiazzare i problematici
database gerarchici?).
Il modello relazionale puo' rappresentare qualunque struttura,
mentre l'XML ha una preimpostata _SINTASSI_ gerarchica.
Grosso errore, la sintassi non e` semantica; ancora confusione tra
struttura rappresentata e rappresentazione.
Il finale e` comico: cita Celko, ma non credo che sia al corrente
del modo in cui Joe parla di MySQL sui newsgroup :-)) 

 del modo in cui Joe parla di MySQL sui newsgroup :-))
cosa dice?
-- 
minollo
http://www.youtube.com/watch?v=uuOc7Eopiw4

 cosa dice?
http://groups.google.it/group/comp.databases.ibm-db2/browse_thread/thread/a4980efca8c92884
Ove spiega anche l'origine della parola "kludge", cesso.
http://groups.google.it/group/microsoft.public.sqlserver.replication/browse_thread/thread/a1e7ed6bfa0a4c55/f4f7f9f8a2392919?hl=it#f4f7f9f8a2392919

 [...]
Ciao  Manlio

 a 3 valori.
perchè bacate?
come si potrebbe fare senza i NULL e la logica a 3 valori che ne 
consegue?
-- 
minollo
http://www.youtube.com/watch?v=uuOc7Eopiw4

 ne consegue?
Trovo curiosa questa domanda... i null e la 3VL sono l'anomalia
rispetto al normale modo di pensare e di fare programmi.
BTW, in vari modi, es. decomposizione in piu` tabelle. 

"Manlio Perillo"


Non c'e` bisogno di avere un prodotto in mano, per dimostrare
la correttezza (o il suo contrario) di un linguaggio, basta
un'analisi ben fatta... ad ogni modo occasionalmente vengono
fatti prototipi proof-of-concept scaricabili dai siti delle
universita`.
Andando oltre, riusciresti ad immaginare una versione dell'SQL
senza i NULL? o a 2VL?
Io credo che non solo sia fattibile, ma anche che questo e`
esattamente quello che molti dba GIA' FANNO quando impongono le
colonne a "not null" per evitarsi i relativi problemi...
Comunque, non e` che servano grossi stravolgimenti, basta qualche
limatura anche al "nostro" SQL; vedasi ad esempio le modifiche
fatte da questo dbms all'SQL per correggere alcuni errori
(prodotto realmente in commercio):
http://www.firstsql.com/iexist.htm
Chiaramente si crea una versione dell'SQL incompatibile
con le altre... questo e` parte dell'enorme difficolta` di
staccarsi dallo standard SQL che ormai copre il 99,9% del
mercato. Sono i reparti marketing che ti dicono che
produrre per 0,1% del mercato e` prima di tutto un suicidio
commerciale; da qui il relativo appiattimento del mercato che
dicevi sopra. 

 [...]
Ciao  Manlio

 BTW, in vari modi, es. decomposizione in piu` tabelle.
Che succede se crei una view, la cui query fa un outer join tra due 
tabelle; join che produce dei NULL?
Ciao  Manlio

"Manlio Perillo"


Difatti l'outer join non e` un'operazione relazionale... Gli
operatori originali (per come definiti da Codd) contemplano solo
il NATURAL JOIN, che in SQL corrisponde all'INNER JOIN.