Progettazione di tabelle per la registrazione di round in una partita

Question

Progettazione di tabelle per la registrazione di round in una partita

#1 da (2 voti)

1

Sto lavorando al sito web per il gioco di bridge e sto lavorando alla progettazione della tabella per archiviare le offerte.

A proposito dell'offerta. 4 persone a un tavolo faranno offerte in senso orario fino a 3 giocatori, quindi potrebbero essere molte rotazioni di offerte con una delle quattro per iniziare l'offerta in questo modo:

North East South West
Pass  1H   Pass  1NT
Pass  3H   Pass  3NT
Pass  Pass Pass

North East South West
                 1C
1S    Pass 3S    Pass
4S    Pass Pass  Pass

Quindi ovviamente ho bisogno di salvare ogni offerta in sequenza, ma ho alcune opzioni su come progettarlo.

Potrebbe avere una tabella come questa e continuare ad aggiungere una voce per round necessaria: Round, NorthBid, EastBid, SouthBid, WestBid

Oppure: Numero di sequenza, chi, offerta

Potrebbero esserci altre alternative, ma vorrei avere qualche input sull'approccio migliore per progettare la struttura della tabella per dati come questo.

database-design

posta StefanE 15.04.2014 - 12:57

fonte

1 risposta

Leggi altre domande sui tag database-design

Il polimorfismo del sottotipo distingue tra comportamento ereditario o ereditare un'interfaccia? Il repository DDD può modificare l'entità nel DB senza un oggetto entità?

score 2 · Accepted Answer

Se questo è solo per la presentazione, allora il primo è probabilmente più facile da lavorare.

 +----------+
 | bids     |
 |----------|
 | game     |
 | round    |
 | north    |
 | south    |
 | east     |
 | west     |
 +----------+

E hai finito. Facile da inserire, facile da estrarre per la presentazione .

Tuttavia, questa tabella non è normalizzata e quindi alcune query a riguardo saranno più difficili.

Considera di porre la domanda sul tavolo "quando è un 3NT l'offerta accettata?" La domanda per questa domanda diventa piuttosto complicata al punto che qualcuno ti darà la caccia e dirà cose sgradevoli sulla struttura della tua tabella. Se questo è solo per la presentazione, le persone probabilmente non lo faranno ... ma per qualsiasi altro uso ... ug.

_{^{Stavo per provare a scrivere quella query per dimostrare il problema, ma poi è diventato più brutto di quanto volessi davvero provare a presentare qui ... e ho un bel po 'di tolleranza per le domande brutte. Seriamente, è brutto se vuoi porre questa domanda.}}

D'altra parte, se è una riga per offerta ...

 +----------+
 | bids     |
 |----------|
 | game     |
 | order    |
 | seat     |
 | bid      |
 +----------+

Bene, ora posso fare una query come:

select game
from
  bids NT, bids NT1, bids NT2, bids NT3
where
  NT.bid = '3NT'
  and NT1.order = NT.order +1 and NT1.bid = 'pass'
  and NT2.order = NT.order +2 and NT2.bid = 'pass'
  and NT3.order = NT.order +3 and NT3.bid = 'pass'
  and NT.game = NT1.game and NT.game = NT2.game and NT = NT3.game

E lo farebbe. Non è il più pulito (non ho fatto un bel join) ... ma funziona.

Potresti considerare di creare un'altra tabella che contiene l'ordine delle offerte (poiché è un elenco enumerabile) in modo che l'offerta stessa possa essere un numero e potresti fare confronti basati su numeri piuttosto che su stringhe ( foo.bid = bar.bid + 5 direbbe che l'offerta è stata aumentata al valore N + 1 nello stesso seme, ad esempio un'offerta se 2H è stata aumentata a 3H ).

Si riduce davvero a ciò che si vuole fare con i dati. Per la presentazione, un semplice schema demoralizzato funziona bene. Per l'analisi, hai bisogno di qualcos'altro che guardi le offerte come singole righe.