Tabella abilità dedicata: controindicazioni? postato il 09/08/2010 14:22:43 nel forum programmazione, gdrcd e open source e modificato da kheper il 09/08/2010 15:16:16
Ricominciando a smanettare su un progetto di programmazione fatto a mano da me non-programmatrice, mi inizio a fare domande apparentemente idiote sulla progettazione della struttura del database.
Mettiamo che io voglia creare della abilità di scheda che hanno determinati effetti su diverse funzioni e variabili del portale/gioco.
Avevo pensato di creare un DB apposito per le abilità, contenente per ognuna i vari parametri che va a modificare/abilitare/toccare e poi una tabella di assegnazione dei valori legando l'id dell'abilità all'id del personaggio.
A senso logico mi tornerebbe "bene" per gestire quello che devo gestire con le abilità e soprattutto per integrare le varie abilità (che sono funzioni) pian piano senza dover per forza toccare la tabella della scheda personaggio ogni volta.
La domanda è per chi è vagamente più esperto di me: che controindicazioni ci sarebbero ad adottare una soluzione simile? Non so se appesantirebbe qualcosa, ad esempio, visto che andrei a richiamare dati da tre tabelle invece che da una...
Pagine → 1
09/08/2010 14:25:26
Immagino che tu intenda una tabella dedicata alle ablita', e non certo un database. In quel caso ti direi che e' l'unica soluzione plausibile. Lo so che Extreme ha le abilita' infilate dentro la tabella personaggio, ma non per nulla Extreme e' roba da buttare nel gabinetto e basta.
09/08/2010 14:44:11
Quello a cui stai pensando è il classico esempio di relazione molti-a-molti. Hai due entità, il personaggio e la skill, ognuna con la propria tabella e ovviamente con la propria chiave. Pensi: quante skill può avere un personaggio? Zero, una, più di una? La risposta in questo caso è: più di una. Analogo discorso all'inverso. Una skill a quanti personaggi può appartenere? Zero, uno, più di uno? Anche in questo caso la risposta è: più di uno. Ergo hai una relazione che collega due entità in maniera molti-a-molti. L'unico modo per mappare una relazione molti a molti in sql è quello di riempire una tabella intermedia contenente le chiavi di entrambe le tabelle; ogni riga di questa tabella sarà formata da elementi diversi, e sarà effettivamente la tabella che mapperà il rapporto skill/personaggio.
09/08/2010 14:57:05
Sì, Fab... parlo di tabelle (mea culpa, non imparerò mai che le tabelle son tabelle ed i database son database... per me sono tutti database). Non so come funziona Extreme, sto cominciando adesso a smanettare con gli OS per vedere che soluzioni adottano, ma sto già "montandomi in testa" la struttura di ciò che vorrei raggiungere/avere.
Esammente vino_veritas: è quello che voglio fare (ma che in quanto niubba non avrei saputo spiegare meglio).
Praticamente quello che vorrei (esemplificandolo al massimo) è:
TAB1
ID
Nome
Cognome
Indirizzo
TAB2
ID
Abilita
Prerequisito
Massimale
Minimale
TAB3
ID
ID_Tab1
ID_Tab2
La domanda è: che problemi può causare, se può causarne? Non so se farebbe lavorare troppo il db...
09/08/2010 15:06:23
puoi tagliare la tab3 e mettere in tab2 un refTab1_ID.
Non ci sono controindicazioni per una join tra due tabelle così piccole.
09/08/2010 15:20:06
Mah,come ho fatto io.
Tab Skills_Generali
ID
NomeSkill
DescrizoneSkill
IDRazza (che sarà un requisito solo x chi ha quell'id di razza)
IDClasse (analogo di sopra)
etc etc etc
Tab Skills_Personaggi
ID
IDSkillPadre ( che sarebbe l'id della skill che si trova in Skills_Generali)
NomePossessore ( nome del personaggio che l'ha imparata)
Ovviamente + la fai elaborata e + diventano belle..
Io ci ho inserito forza,difesa...etc etc,livello skill...imparabile x ki ha un determinato lvl e così via^_^..insomma un po di ingegno e riesce tutto :-D
09/08/2010 15:26:54
Puoi tagliar via il campo ID dalla tabella 3; quella tabella, così com'è, sarà necessariamente formata da tuple l'una diversa dall'altra.
09/08/2010 23:30:07
Gracias a todos.
(Veritas: l'ID nella TAB3 pensavo di lasciarla per poi magari usarla nei log... di chi ha messo cosa a chi... ma sto concettualizzando adesso il tutto, quindi magari quando ho finito scopro che era inutile.)
Discussione seguita da
Pagine → 1
Rispondi alla Discussione Aggiungi ai Preferiti Inoltra Discussione Forum Programmazione, GDRCD e Open Source Elenco Forum
Il gestore di Age of Crystals ha risposto alla recensione di moak