Un tavolo a una colonna è un buon design? [chiuso]

Va bene avere una tabella con una sola colonna? So che non è tecnicamente illegale, ma è considerato un design scadente?

MODIFICARE:

Ecco alcuni esempi:

• Hai una tabella con i 50 codici di stato degli Stati Uniti validi, ma non è necessario memorizzare i nomi di stato dettagliati.
• Una lista nera di e-mail.

Qualcuno ha menzionato l'aggiunta di un campo chiave. Per come la vedo io, questa singola colonna SAREBBE la chiave primaria.

Sì, è certamente un buon design progettare un tavolo in modo da renderlo più efficiente. Il "cattivo design RDBMS" è solitamente incentrato sull'inefficienza.

Tuttavia, ho riscontrato che la maggior parte dei casi di progettazione a colonna singola potrebbe trarre vantaggio da una colonna aggiuntiva. Ad esempio, i codici di stato possono in genere avere il nome completo dello stato enunciato in una seconda colonna. Oppure una lista nera può avere note associate. Ma se il tuo progetto non ha davvero bisogno di queste informazioni, allora è perfettamente ok avere la singola colonna.

In termini di relational algebraquesto sarebbe una relazione unaria, che significa " questa cosa esiste "

Sì, va bene avere una tabella che definisca tale relazione: ad esempio, per definire un dominio.

I valori di tale tabella dovrebbero essere naturalmente chiavi primarie naturali.

Una tabella di ricerca di prime numbersè ciò che mi viene in mente per primo.

Li ho usati in passato. Un mio cliente voleva bloccare automaticamente chiunque cercasse di registrarsi con un numero di telefono in questa grande lista che aveva, quindi era solo una grande lista nera.

Se ce n'è una valida necessità, non vedo alcun problema. Forse vuoi solo un elenco di possibilità da visualizzare per qualche motivo e vuoi essere in grado di cambiarlo dinamicamente, ma non hai bisogno di collegarlo a un'altra tabella.

Un caso che ho trovato a volte è qualcosa del genere:

La tabella countries_id , contiene solo una colonna con ID numerico per ogni paese.

La tabella countries_description , contiene la colonna con l'ID del paese, una colonna con l'ID della lingua e una colonna con il nome del paese localizzato.

La tabella company_factories , contiene le informazioni per ciascuna fabbrica dell'azienda, incluso il paese in cui si trova.

Quindi, per mantenere la coerenza dei dati e i dati indipendenti dalla lingua nelle tabelle, il database utilizza questo schema con tabelle con una sola colonna per consentire chiavi esterne senza dipendenze dalla lingua.

In questo caso penso che l'esistenza di una tabella di colonna sia giustificata.

Modificato in risposta al commento di: Quassnoi

_{(fonte: ggpht.com )}

In questo schema posso definire una chiave esterna nella tabella company_factories che non mi richiede di includere la colonna Language nella tabella, ma se non ho la tabella countries_id, devo includere la colonna Language sulla tabella per definire la chiave esterna .

Ci sarebbero rari casi in cui una tabella a colonna singola ha senso. Ho creato un database in cui l'elenco dei codici di lingua validi era una tabella a colonna singola utilizzata come chiave esterna. Non aveva senso avere una chiave diversa, poiché la chiave era il codice stesso. E non c'era una descrizione fissa poiché le descrizioni del codice della lingua variavano in base alla lingua per alcuni contesti.

In generale, ogni caso in cui è necessario un elenco autorevole di valori che non hanno attributi aggiuntivi è un buon candidato per una tabella a una colonna.

Uso sempre tabelle a colonna singola, a seconda, ovviamente, se il design dell'app utilizza già un database. Dopo aver sopportato il sovraccarico di progettazione di stabilire una connessione al database, ho inserito tutti i dati modificabili in tabelle, ove possibile.

Posso pensare a due usi delle tabelle a colonna singola OTMH:

1) L'elemento dati esiste. Spesso utilizzato negli elenchi a discesa. Utilizzato anche per semplici test di legittimità.

Per esempio. abbreviazioni di stato USA di due lettere; Codici di avviamento postale a cui spediamo; parole legali in Scrabble; eccetera.

2) Attributo binario sparse, cioè, in una grande tabella, un attributo binario che sarà vero solo per pochissimi record. Invece di aggiungere una nuova colonna booleana, potrei creare una tabella separata contenente le chiavi dei record per i quali l'attributo è vero.

Per esempio. dipendenti che hanno una malattia terminale; banche con un anno di 360 giorni (la maggior parte utilizza 365 giorni); eccetera.

-Al.

Nessun problema fintanto che contiene valori univoci.

Per lo più l'ho visto nelle tabelle dei tipi di ricerca come la tabella degli stati che hai descritto. Tuttavia, se lo fai, assicurati di impostare la colonna come chiave primaria per forzare l'univocità. Se non puoi impostare questo valore come unico, non dovresti utilizzare una colonna.

In generale, direi di sì. Non sono sicuro del motivo per cui hai bisogno di una sola colonna. Ci sono alcune eccezioni a questo che ho visto utilizzate in modo efficace. Dipende da cosa stai cercando di ottenere.

Non sono davvero un buon design quando si pensa allo schema del database, ma dovrebbero essere usati solo come tabelle di utilità.

Ho visto tabelle numeriche utilizzate in modo efficace in passato.

Lo scopo di un database è mettere in relazione parti di informazioni tra loro. Come puoi farlo quando non ci sono dati a cui fare riferimento?

Forse questa è una sorta di tabella di compilazione (ad esempio FirstName + LastName + Birthdate), anche se non sono ancora sicuro del motivo per cui dovresti farlo.

EDIT: ho potuto vedere l'utilizzo di questo tipo di tabella per un semplice elenco di qualche tipo. È per questo che lo stai usando?

Sì, purché il campo sia la chiave primaria come hai detto che sarebbe stata. Il motivo è perché se inserisci dati duplicati, quelle righe saranno di sola lettura. Se provi a eliminare una delle righe duplicate. non funzionerà perché il server non saprà quale riga eliminare.

L'unico caso d'uso che riesco a concepire è una tabella di parole forse per un gioco di parole. Si accede alla tabella solo per verificare che una stringa sia una parola: selezionare la parola dalle parole dove parola =?. Ma ci sono strutture di dati di gran lunga migliori per contenere un elenco di parole rispetto a un database relazionale .

In caso contrario, i dati in un database vengono solitamente inseriti in un database per sfruttare le relazioni tra i vari attributi dei dati. Se i tuoi dati non hanno attributi oltre al loro valore, come verranno sviluppate queste relazioni?

Quindi, sebbene non sia illegale, in generale probabilmente non dovresti avere una tabella con una sola colonna.

Tutte le mie tabelle hanno almeno quattro campi tecnologici, chiave primaria seriale, timestamp di creazione e modifica e booleano di eliminazione soft. In qualsiasi lista nera, vorrai anche sapere chi ha aggiunto la voce. Quindi per me, la risposta è no, una tabella con una sola colonna non avrebbe senso tranne quando si prototipa qualcosa.

Sì, va benissimo. ma un campo ID non potrebbe danneggiarlo, giusto?