Che cosa devo tenere in considerazione quando si progetta un'interfaccia utente attorno a una relazione 0..1: 1?

Question

Che cosa devo tenere in considerazione quando si progetta un'interfaccia utente attorno a una relazione 0..1: 1?

#1 da (1 voti)
#2 da (0 voti)

1

Sto progettando lo schema del database per una nuova funzionalità del prodotto. Nel mio attuale design ho alcuni dati opzionali correlati. Piuttosto che avere campi nullable ho una tabella separata con una relazione 0..1: 1 alla tabella principale. Ho scelto questo design perché le query sono più semplici * se i dati nulli non devono essere presi in considerazione.

Il responsabile del team mi ha fatto notare che complicherà l'associazione dei dati nell'interfaccia utente e suggerisco di utilizzare solo campi nullable. Mi chiedo quali complicazioni introdurrà l'approccio alla tabella opzionale?

La cosa ovvia che mi viene in mente è che i controlli sensibili ai dati non possono legarsi a un data set chiuso, quindi dovrò creare un record al volo quando l'utente tenta di compilare i dati opzionali o creare il registrare allo stesso tempo del record principale, annullando lo scopo di avere una tabella separata. C'è qualcos'altro di cui dovrei essere a conoscenza?

Chiarimento

* Più semplice, con cui mi riferisco alla quantità da capogiro delle regole e alle ambiguità relative il comportamento di null in diversi scenari di query nello standard SQL e il fatto che non ci sono due venditori che concordano su quale di queste regole per implementare .

database-design gui-design

posta Kenneth Cochran 16.08.2013 - 22:16

fonte

2 risposte

Leggi altre domande sui tag database-design gui-design

MyListActivity, MyCursorAdapter, MyViewHolder - classi nidificate o no? come ridurre i tempi di comunicazione nei team distribuiti [duplicato]

score 1 · Answer 1

Non penso che progettiate semplicemente nulla per quanto riguarda la gestione NULL. Per usare il tuo secondo tavolo avrai bisogno di un "LEFT OUTER JOIN" nella tua tabella principale che restituirà valori NULL se non ci sono righe corrispondenti nella seconda tabella. O dovrai fare la logica equivalente nel codice del tuo programma e avere due percorsi di codice separati; uno per "trovato una riga" e uno per "riga non trovata". Quindi quale sarebbe il guadagno netto?

Potrebbero esserci altri motivi per separare i dati in un'altra tabella ma ridurre la complessità della gestione NULL non è uno di questi. Il piccolo codice che si salva nel controllo dei valori NULL verrà superato di molto dalla complessità di mantenere una tabella separata.

score 0 · Answer 2

Supponendo che lo stai facendo in C #, che non specifichi, puoi impostare l'oggetto dati principale in questo modo:

public class MainObj
{
    public int ID { get; private set; }
    public string Name { get; set; }

    private SubdataObj _data;
    public int? OptionalID 
    { 
      get 
      { 
         if (_data == null) return null; 
         else return _data.OptionalID;
      }
      set
      {
         if (_data == null) _data = new SubdataObj();
         _data.OptionalID = value;
      }
    }
    class SubdataObj
    {
        public int OptionalID { get; set; }
    }
  }

Compila solo _data sul caricamento degli oggetti, se possibile, oppure lascialo nullo altrimenti. Tieni presente che OptionalID è un normale int , ma lo rendiamo nullable quando lo esponiamo. Facendolo in questo modo significa che non devi fare nulla di speciale per l'interfaccia utente, anche se ciò significa più lavoro durante la modifica della tabella di supporto di SubdataObj .