Progettare correttamente un DB | Progettazione di DataBase Relazionali

Dopo aver letto diversi testi su MySQL e PHP ho iniziato il progetto di una applicazione PHP e database MySQL. Sto cercando di strutturare al meglio il database per evitare successivi problemi nella gestione del DB ed è per questo motivo che chiedo il conforto degli utenti esperti di questa comunità. Il progetto riguarda la creazione di un tool che consenta ad un gruppo di sviluppatori 3D/2D/LUA di tenere traccia dei modelli/tasks che sono ad una determinata data in corso di sviluppo da parte degli stessi, aggiornando il livello di sviluppo di ciascun modello/task fino al loro completamento. Scrivo di modelli e task in quanto le attività di sviluppo non riguardano solo modelli 3D e le loro texture ma anche solo file grafici 2D e codice in LUA per definizione di fisica e modelli di danneggiamento/modelli di volo degli oggetti. I modelli potranno essere pilotabili ma anche solo oggetti mossi da AI (in questo caso non necessiteranno di modellazione degli interni; questi target avranno pertanto solo necessità di 3D e 2D esterno e codice LUA per modello di danneggiamento. Gli sviluppatori potranno aggiornare i task a loro assegnati anche uploadando nel DB le immagini che riterrano opportune per mostrare al resto del team lo stadio di sviluppo del loro lavoro. Il tool consentirà di aggiungere modelli anche se i lavori necessari non sono stati assegnati a nessun modellatore, pertanto andranno a costituire una sorta di Suggestions Box per lo sviluppatore che intende dare una occhiata al tool per verificare quali modelli sono necessari per la simulazione, quali sono in fase di sviluppo da altri modellatori e quali necessitano l’avvio della modellazione. Detto questo ritengo che le entità coinvolte nel DB dovrebbero essere: - Modello - Immagini

Le tabelle che penso sia necessario creare dovrebbero essere: - Lista modelli - Immagini - Attività

Nella tabella Lista modelli avrei i seguenti campi: - TaskID (Primary key) - ModelDescription - Note - ModelStatus (Not assigned/In progress/Completed) - RegisterDate - LastAccessTime

Nella tabella Immagini inserirei: - ImgID (Primary Key) - TaskID (Key) - ImageData - ImageType - Note

Nella tabella Attività infine: - ActivityID (Primary Key) - TaskID (key) - 3DExternal (da valorizzare con il nome dello sviluppatore che si assegna il lavoro) - 2DExternal (come sopra) - 3DInternal (come sopra) - 2DInternal (come sopra) - Code (come sopra) - 3DExt_perc (percentuale di completamento del lavoro) - 2DExt_perc (come sopra) - 3DInt_perc (come sopra) - 2Dint_perc (come sopra) - cod_perc (come sopra)

Può funzionare o può essere migliorata? Ringrazio per ogni contributo

Ciao user:”vespa”,

Benvenuto su MySQL Italia, scusa se la risposta non è arrivata velocemente ma, è periodo di ferie un pò per tutti, anche per noi dello staff.

Rigurado alla tua domanda avrei un pò di considerazioni da fare assieme a te.

Per prima cosa un consiglio, i modellatori, interni o esterni che siano, secondo me devono essere inseriti in un’altra tabella, chiamata appunto modellatori (magari una tabella anagrafica), distinguendo quelli esterni e quelli interni con un semplice flag.

Cosi facendo nella tabella Attività metterai solo gli ID dei modellatori e non il nome intero. Mi rendo conto che è un pò più faticoso, perchè l’applicazione cresce di dimensione ma questo piccolo effort iniziale ti potrà consentire in futuro di fare meno fatica per estendere l’applicazione.

Un’altra riflessione che ti invito a fare è sulla tabella Immagini, per molti motivi – che se vuoi possiamo approfondire -, in applicazioni come questa, è conveniente non utilizzare il DB come sistema per la memorizzazione dei file. Il campo ImageData lo sostituirei con un campo ImageName che dovrà contenere solo il nome dell’immagine, l’immagine vera è propia dovrebbe essere salvata su filesystem in una percorso configurato a partire dai file di configurazione dell’applicazione.

Un ultima considerazione, un pò più generalista. L’applicazione che stai sviluppando è molto simile ad un sistema di Ticket Management, ovvero un’applicazione che gestisce il tracciamento di attività attraverso la scrittura di ticket (in questo caso i ticket sono quelli che tu chiami Attività). Ovviamente la logica di business della tua applicazione ti impone dei campi e delle tabelle particolari, ma il concetto non è molto differente. Ti invito se lo ritieni opportuno a fare un giro sulle migliaia di applicazioni Open Source che trovi in giro sulla rete, che si occupano di questa tematica, magari prima di mettere mano al codice, ti viene in mente qualcos’altro o magari deciderai di personalizzarne qualcuna, senza partire da zero.

Per qualsiasi cosa non esitare a postare ancora.

Saluti user:”algweb”

Algweb, ti ringrazio per la risposta, i consigli ed il benvenuto; in questa fase di apprendistato di PHP/MySQl mi è indispensabile il confronto con chi ne sa più di me e questo forum in italiano si è rilevato una importantissima risorsa. Nessun problema per il ritardo, è un periodo particolare…lo so.

Detto questo: - implementerò sicuramente la modifica per il nome dei modellatori sostituendola con gli ID. Devo precisare che non ho previsto tabelle con anagrafiche per gli sviluppatori in quanto l’applicazione si integra con il database di phpBB e pertanto le persone autorizzate al login nella mia applicazione saranno gli utenti/sviluppatori già registrati sul forum del nostro sito e che avrò preventivamente aggregato ad un gruppo specifico ed abilitato all’accesso ad aree riservate del forum e all’applicazione in corso di sviluppo. - ero e sono molto combattuto sulla modalità di gestione delle immagini. Sono sicuramente interessato a capire i vantaggi dell’uso di filesystem anzichè DB per memorizzare le immagini. - in effetti avevo provato a cercare in rete applicazioni di Ticket Management, qualcosa avevo anche trovato (ora non ricordo esattamente cos), poi però, la particolarità delle richieste del mio team e la curiosità e la voglia di sperimentare direttamente e scrivere tutto il codice per imparare meglio PHP e MySQL mi ha spinto a partire con il progetto da zero. Difatti ho già completato una prima versione del Tool (che ho chiamato CDT, Cooperative Development Tool) che attualmente risponde alle necessità richieste dagli sviluppatori del nostro progetto. L’applicazione però si basa su una struttura di DB che ho messo in piedi senza alcuna competenza ed ora, con il crescere delle attività e del suo uso, il DB sta mostrando i suoi limiti. Da qui la voglia di ristrutturarlo prima che il vecchio diventi ingestibile e riuscendo facilmente, al momento, a effettuare un backup di tutti i dati del vecchio DB nella eventuale nuova struttura.

Grazie per ogni contributo e feedback.

Ciao user:”Vespa”,

per quanto riguarda la tabella degli utenti, non avevo capito che stavi facendo un integrazione a qualcosa di esistente, quale phpBB.

Fare un’applicazione con le proprie mani, è più complicato ma oltre ad offrire moltissimi vantaggi da anche tanta soddisfazione, apprezzo molto e condivido la tua scelta, questo sito per esempio è stato sviluppato interamente da noi dello staff, nonostante fossimo tutti fautori delle soluzioni Open Source le esigenze e gli obiettivi erano diversi, quindi ci siamo fatti tutto da zero.

Relativamente al discorso di mettere o meno le immagini nel DB le considerazioni da fare sono veramente tante e non tutte riguardanti le performance dell’applicazione, la scalabilità di un applicazione con 200milioni di avatar in un db ad esempio.

Sarebbe infatti poco completo parlare di ottimizzazioni sulla parte applicativa senza parlare di ottimizzazioni sulla parte sistemistica e su quella di networking. In fondo sono tutti anelli della stessa catena.

Per scegliere se memorizzare i file su DB o su filesystem possiamo iniziare con il porci questa domanda:

Ma la cache di MySQL dov’è memorizzata? E’ memorizzata su filesystem o su DB

Beh la risposta è che le query in cache di MySQL sono memorizzate su filesystem, quindi MySQL, quando può, cerca di evitare di interrogare se stesso.

Se googli un pò troverai un sacco di regole, spesso un pò troppo empiriche, secondo cui ad esempio se in una directory memorizzi fino a 100 immagini/file il filesystem è più veloce.

Personalmente non sono molto convinto della validità e delle quantità di queste regole, mi sembra strano poter essere così precisi senza conoscere ad esempio: tipo di filesystem, sistema operativo, tipo di Raid utilizzato, driver del controller, tipo di dispositivo di storage etc.

Però il punto è che la cache di qualsiasi tipo, anche quella generata dalle applicazioni come ad esempio alcuni CMS è su filesystem.

Un altra considerazione potrebbe venirti dal fatto che, in una applicazione WEB, i temp di attesa sono determinati in misura sempre maggiore dal traffico di rete che dalla velocità di elaborazione, a questo punto bisogna domandarsi, ma il mio DB è sulla stessa macchina dove viene eseguita l’applicazione o è su un altro host?

Se posso vorrei darti un altro suggerimento, quando mi trovo di fronte a questi dubbi, spesso amletici, mi chiedo ma come hanno fatto i giganti del WEB ad affrontare questa problematica?

Nel tuo caso, come avrà fatto Facebook? Se volessimo per assurdo considerare solo gli avatar, saranno circa 200milioni di immagini ?

Che ne pensi ?

Saluti user:”algweb”

P.S. Grazie a te di partecipare al sito e al forum e grazie di considerarci una importantissima risorsa.

In effetti le considerazioni proposte sono condivisibilissime e…sinceramente…non mi ero proprio soffermato su questi aspetti…rivedrò la tabella delle immagini per memorizzare il solo path del file che sarà uploadatto su filesystem.

Per il resto, le tabelle ritieni sia correttamente strutturate?

Grazie ancora.

Ciao user:”Vespa”,

Relativamente alle immagini, il mio consiglio è quello di salvare nel DB solo il nome dell’immagine e di parametrizzare il path (o in un file di conf o in una tabella di conf) in modo da poter cambiare velocemente il path, in un momento successivo, magari in fase di manutenzione.

Immagina infatti che se tra qualche tempo ti interesserà mostrare qualche anteprima – thumbnail – delle immagini, converrà salvarle o in directory differenti archiviate per dimensioni o con prefissi e/o suffissi al nome del file.

Fai attenzione però che questa che ti ho suggerito io è la soluzione più semplice, immagina infatti cosa succederebbe se si tenta di fare l’upload di un immagine che ha lo stesso nome di un immagine già presente :)

Per il resto penso che tu abbia ben schematizzato il problema, l’unica curiosità che mi viene da chiedere è:

I modelli hanno un nome ?

Le altre cose da suggerire in questa fase di sviluppo non penso siano determinanti.

Avrei però da chiederti: ma per i modelli sono previste delle versioni, ad esempio 1.0 , 1.1 etc ?

Qualora questa cosa fosse necessaria, come la gestiresti? solo con la descrizione o hai previsto altro ?

Infine nella tabella Attività non memorizzi nessuna data? Come identifichi e quantifichi il tempo di lavoro di ciascuna attività?

Forse è vero alcune di queste feature, come ad esempio quest’ultima, sono superflue, ma in fase di sviluppo implementarle ti costa molto meno rispetto a estendere, in una fase successiva, l’applicazione.

Comunque scusami se mi dilungo troppo, mi sembra di aver capito che ti interessa confrontarti e quindi sto cercando di non darti al volo quelle che penso siano le soluzioni migliori, ma ci stiamo ragionando insieme, così che tu possa fare esperienza più velocemente. Poi il confronto fa crescere entrambi, quindi devo ringraziarti perchè me ne stai dando l’opportunità.

Saluti user:”algweb”

Ultima modifica 11 Luglio, 2010 01:16 di g2d

algweb, nessuna scusa per carità…le tue osservazioni e suggerimenti sono proprio ciò di cui ho bisogno per riuscire a vedere situazioni che altrimenti mi sfuggirebbero completamente.

In merito alle immagini: pensavo digestire eventuali conflitti di nomi di file con un controllo in PHP.

In merito ai modelli (io li definirei come task in quanto nelle attività potrebbe rientrare anche solo lo sviluppo di codie di programmazione LUA per interattività della UI utente….estendendo in tal modo l’uso del tool che sto sviluppando) in effetti esiste un nome/descrizione. Anche in questo caso dovrei prevedere a livello di PHP un controllo su nomi/descrizioni già presenti.

Interessante l’aspetto versione. E’ sicuramente possibile che un modello compeltato venga aggiornato a nuovi standard. E’ il caso di prevedere un campo nella tabella per la versione? Anche se volendomi riferire a task più che a modelli la cosa potrebbe essere non rilevante. Nel senso…una volta che un task è stato completato (anche se l’oggetto del task è un modello), se voglio aggiornare il modello riaprirò un nuovo task…sebbene con lo stesso nome di un precedente lavoro; in questo senso potrei prevedere un controllo sui nomi dei task/modelli solo nella fase in cui un task risulti in progress piuttosto che completato.

Ottimo anche il suggerimento della tempistica. Nella tabella Attività aggiungo anche un campo latestupdate con il time dell’accesso per aggiornamento dei dati o assegnazione ad uno sviluppatore.

Ottimo…adoro il brainstorming :)

Un altro aspetto che al momento non riesco a capire come gestire: volendo prevedere nella tabella Lista Modelli un campo Stato con valori: Non assegnato, In progress e Completato…dovrei tenere conto del fatto che, per i vari Task possono sussistere diverse attività da completare per essere considerati completati.

Volgio dire che ci sono alcuni Task/modelli che saranno pilotaibli da utenti e pertanto necessiteranno di 3D interno (cockpit) olte che esterno. Occorrerà completare tali attività prima che un modellatore dichiari un task/modello completato. Diverso invece per un task/modello che riguardi un oggetto che sarà usato ad esempio solo come target: in questo caso sarà necessario completare solo 3D/2D esterno e codice di fisica per essere considerato completato. Suggerimenti? :D

Ciao user:”Vespa”,

Fa attenzione, sarebbe infatti un peccato non permettere l’upload di immagini con lo stesso nome appartenenti a modelli differenti, per far questo puoi ricorrere a molte soluzioni applicative.

Beh io direi che, Modelli e Task sono concetti differenti non la stessa cosa, per noi comuni mortali il nome – che è semplicemente qualcosa di mnemonico – è d’obbligo ma per le macchine è importante – per ovvie ragioni – che anche i modelli abbiano un identificativo, un ID.

La scelta di permettere o meno che due modelli abbiano lo stesso nome, sta a te e ai requisiti del progetto.

Per quanto riguarda invece il discorso del versionamento, sviluppare un sistema funzionante e affidabile, che versioni è sicuramente un impresa alquanto ardua. Per il codice sorgente ne esistono molti, come ad esempio:

• SVN http://it.wikipedia.org/wiki/Subversion
• CSV http://it.wikipedia.org/wiki/Concurrent_Versions_System
• GIT http://it.wikipedia.org/wiki/Git_(software)

ma ti assicuro che ne esistono molti altri.

Sono stati tutti pensati per il codice sorgente, ma con la maggior parte di questi software puoi versionare qualsiasi file, io ad esempio ho visto versionare di tutto con SVN.

Nel tuo caso mi concentrerei sul versionare i modelli il cui stato è Completed; non avrebbe infatti senso versionare le Attività, devi conservarti dei dati che abbiano una propria consistenza.

Per far questo potresti pensare al concetto di rilascio – Release -, ogni qual volta un modello diventa completed diventa rilascio, devi decidere tu in base alle reali esigenze, attuali e future.

L’ultima considerazione è relativa alla tabella Modelli.

Se ho ben capito il workflow delle operazioni e quindi degli stati varia in base al tipo di modello che sia esso 3D, 2D o altro. In questo caso ti trovi ad affrontare il problema che nello studio delle basi dati viene detto Generalizzazione/Specializzazione (Questo è un termine utilizzato nel mondo accademico nell’ambito della ristrutturazione dei modelli ER)

Tutti i modelli che tipicamente hanno alcune caratteristiche in comune (es. id, nome, descrizione, note, stato, tipo etc), ma in base al tipo di modello ci sono dei diversi stati.

In questo caso ti conviene schematizzare bene la situazione e capire quanti sono i tipi di modello quali sono le diverse combinazioni, nell’ipotesi più probabile converrà parametrizzare di più (stati, tipi etc) sempre allo stesso modo o in un file o in tabella.

Veramente tanti aspetti su cui riflettere !!

Per focalizzarsi sugli aspetti più importanti e definire la struttura tabelle:

- in luogo della tabella Attività, in considerazione del fatto che i modelli, a seconda del loro uso (pilotabili o no) richiedono diverse attività per essere considerati completi, potrei prevedere una tabella Attività_1 con i campi descritti nel primo post (includendo 3D/2D interno) ed una tabella Attività_2 per modelli non pilotabili. Può funzionare?.....A me pare una duplicazione non necessaria.

In merito al versionamento il nostro team usa già SVN quale sitema di controllo di versione ma per i modelli già completati. Con il mio tool si andrebbe a coprire un’altra ncessità: sapere chi sta facendo che cosa e soprattutto cosa la roadmap del progetto prevede debba essere fatto per arrivare al rilascio della prima release del gioco.

Mamma mia….mi si sta confondendo la mente…scusa algweb ma sono un novizio in questo campo e mi è difficile tracciare una linea definitiva per capire la struttura ottimale del DB in questione.

Ultima modifica 11 Luglio, 2010 01:16 di Vespa