Piccolo progetto di studio - Intranet aziendale

[Earendill]

Buongiorno a tutti,
premetto che sono nuovo nella progettazione software e sto cercando di sbrogliare un problema di progettazione del database per me nuovo.
Ho delle entità quali:

Nazioni
Città
Sedi
Uffici
Progetti
Task
Persone

Vorrei astrarre queste entità a una classe generica chiamata Oggetti in quanto vorrei, con una certa flessibilità, applicare delle funzionalità quali Community, Condivisione Documenti, Messaggistica ed altro, senza doverle riprogrammarle per ognuno di essi.

Vorrei proporre una relazione Molti a Molti tra ognuno di questi oggetti (laddove non sia consigliato vorrei inibirlo a livello di codice).

Ognuno di questi oggetti ha naturalmente degli attributi completamente diversi.

Pensavo di fare una tabella Oggetti con il solo ID e ENTITA, mentre le altre Entità avrebbero una chiave esterna che riprende l'oggetto. In seguito, il resto delle tabelle riguardanti le funzionalità aggiuntive, le legherei con una chiave esterna sull'oggetto e non sulla singola entità.

Ho qualche dubbio sull'associazione molti a molti tra gli oggetti in quanto richiederebbe il traversing con parecchie funzioni ricorsive. Ho sentito parlare della struttura Closure Table per gestire gerarchie multi padre ma non trovo molta documentazione o informazioni sulla reale efficacia.

Sono sulla buona strada? avete qualcosa da consigliarmi?

[starfred]

Ciao, forse non ho capito bene il problema, tuttavia generalmente nei casi di progettazione db si fa prima uno schema ER, si scrivono le dipendenze e dopo di che si fanno le normalizzazioni in forma normale di Boyce e Codd.
Te l'ho detta molto grezzamente ma il concetto spero di averlo espresso bene :)
Nei db difficilmente ci si "inventa" qualcosa a livello di progettazione. Se ti piace l'argomento ti consiglio la bibbia "Database System Concepts - Silberschatz"

[Earendill]

Stavo ragionando se utilizzare una relazione molti a molti sull'elemento base o utilizzare qualche metodo tipo la "closure table" spiegata abbastanza bene le libro "SQL Antipattern" ma sul quale trovo (in internet) molti pochi casi pratici di utilizzo.
Ho già uno schema relazionale e un diagramma ER .. Magari faccio una scansione e li condivido.

Grazie mille

[Earendill]

nel diagramma ER ho chiamato gli Oggetti , Elementi
Naturalmente gli attributi non sono completi,mi spiace se non ho utilizzato l'annotazione standard per il diagramma.

https://www.dropbox.com/s/e2d67vf0ylvo95c/S22BW-414030710550.pdf

[marco.r]

Non penso che la closure table sia quello che ti serve visto che solitamente si utilizza per strutture nidificate a più livelli tipo alberi. Tu qui hai due livelli e di tipo completamente diverso. Mi sembra piu sensata una tabella di mapping .

Inviato dal mio Nexus 5 utilizzando Tapatalk