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

"Don´t look for a happy ending. It´s not an American story. It´s an Irish one."
(The Devil´s own)

quota

Pagine → 1

vino_veritas

SCRIVI

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.

Exclusive Villa GdR ↗
Las Vegas, azzardo, vizi, soldi, intrighi... Più le sue luci sono scintillanti, più le sue ombre sono oscure. La città che non dorme mai, vi aspetta.

quota

kheper

SCRIVI

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

"Don´t look for a happy ending. It´s not an American story. It´s an Irish one."
(The Devil´s own)

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.

Sursum Corda

quota

nodd

SCRIVI

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

Sponsorizzati con noi! ↗
Sponsorizza il tuo gioco su GDR-online! Trova nuovi giocatori fra i migliaia di appassionati che ogni giorno visitano il portale!

quota

vino_veritas

SCRIVI

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.

CRSED: F.O.A.D. ↗
Brutale sparatutto MMO in cui vince l'ultimo giocatore che resta in vita! Il giocatore sarà accompagnato da armi realistiche e magie!

quota

kheper

SCRIVI

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

"Don´t look for a happy ending. It´s not an American story. It´s an Irish one."
(The Devil´s own)

quota

Discussione seguita da › kheper

Pagine → 1

Rispondi alla Discussione Segui Discussione Inoltra Discussione Forum Programmazione, GDRCD, Open Source, Hosting Elenco Forum