Tabella abilità dedicata: controindicazioni?

Tabella abilità dedicata: controindicazioni? postato il 09/08/2010 14:22:43 nel forum programmazione, gdrcd, open source, hosting 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...

---

quota

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.

quota

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...

---

quota

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.

---

quota

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

quota

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.

quota

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.)

---

quota

Server Minecraft

Lista dei server di Minecraft in italiano!

Comunicazione e GdR

Tesi di Laurea in sociologia del Dott. Cataldo Scatamacchia sui giochi di ruolo tra fantasia e realtà

Undead

Intervista al gestore del play by chat sui Vampiri Undead! Entra nell'oscurita!

Hikaru No Tohei

La folle intervista ai gestori di Hikaru No Tohei Le Luci di Tohei! Da rider... ehm... leggere tutta d'un fiato!