È una buona idea avere una riga di database che rappresenta un valore sconosciuto all'interno di un sistema [chiuso]

Question

È una buona idea avere una riga di database che rappresenta un valore sconosciuto all'interno di un sistema [chiuso]

#1 da (2 voti)
#2 da (-1 voti)

4

Abbiamo due sistemi, il Sistema A importa un elenco di eventi sportivi dal sistema B, vuole solo importare gli eventi per i quali forniremo dati in tempo reale, il filtro utilizzato per nascondere gli eventi per i quali non stiamo fornendo dati è se all'evento è assegnato un arbitro.

Il problema è che non sappiamo chi sarà l'arbitro per determinati eventi, ma sappiamo che ce ne sarà uno quindi qualcuno ha creato un arbitro con il nome TBC e lo ha assegnato ad un gruppo di eventi in modo che lo facciano importati.

Ora c'è una richiesta per poter assegnare in massa questo arbitro TBC a più eventi per salvare il nostro staff operativo dal dover assegnare manualmente l'arbitro per ogni evento uno per uno.

Questa mi sembra una pessima idea, non mi piace l'idea di un arbitro chiamato TBC in primo luogo, ma non riesco davvero a spiegarne il motivo, sembra solo un anti-modello per me.

Qualcuno può aiutarmi e spiegare se è una cattiva idea o no e perché?

anti-patterns data-structures patterns-and-practices web-services data

posta user1450877 14.01.2015 - 17:55

fonte

2 risposte

Leggi altre domande sui tag anti-patterns data-structures patterns-and-practices web-services data

Design periodico sistema di notifica batch Questo pseudocodice di Wikipedia per l'attraversamento generico di alberi in ordine è corretto?

score 2 · Answer 1

Supponiamo che ci sia una tabella EVENT e una tabella REFEREE , e che la prima abbia un PK (referee_id) che si riferisce al PK di REFEREE (referee_id).

Quindi un arbitro "TBC" (non una persona reale), viene inserito nella tabella ARBITRO, quindi qualsiasi evento che non ha assegnato un arbitro al momento dell'inserimento può essere assegnato almeno al codice di quell'arbitro immaginario.

Questa idea di non mi sembra molto buona , a parte il fatto di lasciare semplicemente l'FK nel suo stato null:

Poiché gli FK devono accettare null, c'è sempre la possibilità di avere eventi con "TBC" e altri con nulla (null). Ciò significa che il codice deve gestire entrambe le situazioni ovunque. Ad esempio un rapporto che elenca tutti gli eventi senza arbitri dovrebbe considerare entrambi i casi.

La mia raccomandazione è:

Crea una vista che mostra il letterale "TBC" ogni volta che non c'è un arbitro assegnato, come questo:

create view v_events as
select
    e.event_name,
    e.event_date,
    nvl(r.referee_name,'TBC') as referee_name
from
    event e left join referee r (on e.referee_id = r.referee_id);

Nel caso in cui l'arbitro non sia il proprio tavolo ma solo una colonna di testo in EVENT:

create view v_events as
select
    e.event_name,
    e.event_date,
    nvl(e.referee_name,'TBC') as referee_name
from
    event e;

Nota: NVL è una funzione Oracle, sostitutiva con una funzione equivalente nel tuo RDBMS, come COALESCE in Postgres.

Tutti i codici selezionano quella vista al posto della tabella reale. In questo modo tutti penseranno che c'è un arbitro "TBC" assegnato per impostazione predefinita.

score -1 · Answer 2

Sembra che ci siano troppe regole di business che si basano sull'esistenza di un arbitro: chi è il ref, e anche se questo evento viene trasmesso o meno. Per tutti gli eventi in streaming / non-refere, il campo è nullo. Sarebbe difficile guardare il tuo database e prendere questa decisione.

Non so quanta parte della struttura dei dati potresti cambiare, ma questo ID di holding per un arbitro TBD dovrà essere indirizzato anche in altre query.

Idealmente, dovrebbe esserci una sorta di tabella:

EventReferee

EventID
RefereeID
- possono essere inseriti molti altri dati che in genere possono anche essere nulli nella tabella degli eventi: data di assegnazione, ecc.

In questo modo, dovresti avere un record in questa tabella per designare quelli che non forniscono un feed dal vivo / avere un arbitro, ma potrebbe comunque avere o meno un ID arbitro assegnato.

Una query per chi ha ancora bisogno di un arbitro assegnato è molto semplice controllando per null.
Una query per gli eventi che hanno un arbitro avrà questo record relativo all'evento. Una query per gli eventi che uno streaming non avrà un record nella tabella EventReferee.