¿Es una tabla de una columna un buen diseño? [cerrado]

111

¿Está bien tener una tabla con una sola columna? Sé que no es técnicamente ilegal, pero ¿se considera un diseño deficiente?

EDITAR:

Aquí están algunos ejemplos:

  • Tiene una tabla con los 50 códigos de estado de EE. UU. Válidos, pero no es necesario que almacene los nombres de estado detallados.
  • Una lista negra de correo electrónico.

Alguien mencionó agregar un campo clave. A mi modo de ver, esta única columna SERÍA la clave principal.

Aheho
fuente
Tengo problemas para imaginar un caso de uso para una tabla con una sola columna. ¿Puede dar un ejemplo?
Paul Morie
¡pero al menos no cree un índice para ello!
Sathya
3
Los códigos de estado de EE. UU. Son un ejemplo clásico de definir un dominio
Quassnoi
3
He visto una tabla de base de datos utilizada para contener un valor de bloqueo para una aplicación antes
Russ Cam
Mi uso para este patrón fue crear conjuntos de datos. Cada registro de la tabla principal tiene un campo SET. Los registros con el mismo SET están conectados. ¿Cómo se insertan varios registros con el mismo SET? 'INSERT INTO sets VALUES ()' y luego use el último ID de inserción como su SET ID para adjuntar a los registros. Por otra parte, tal vez podría haber usado UUID, pero algo se siente mal en eso.
William Entriken

Respuestas:

87

Sí, ciertamente es un buen diseño diseñar una mesa de tal manera que sea más eficiente. El "mal diseño de RDBMS" generalmente se centra en la ineficiencia.

Sin embargo, he descubierto que la mayoría de los casos de diseño de una sola columna podrían beneficiarse de una columna adicional. Por ejemplo, los códigos de estado normalmente pueden tener el nombre completo del estado escrito en una segunda columna. O una lista negra puede tener notas asociadas. Pero, si su diseño realmente no necesita esa información, entonces está perfectamente bien tener una sola columna.

Erik Funkenbusch
fuente
168

En términos de relational algebraesto sería una relación unaria, que significa " esta cosa existe "

Sí, está bien tener una tabla que defina dicha relación: por ejemplo, para definir un dominio.

Por supuesto, los valores de dicha tabla deberían ser claves primarias naturales.

Lo prime numbersprimero que me viene a la mente es una tabla de búsqueda de .

Quassnoi
fuente
3
+1: la tabla es un conjunto de valores que resultan ser tipos primitivos de su RDBMS.
S.Lott
4
+1 por proporcionar una respuesta basada en la teoría relacional.
lubos hasko
Aquí hay un buen ejemplo de un esquema que tiene una tabla de 1 columna que no es una clave natural, la tabla Thread en un sistema de mensajería ... stackoverflow.com/a/6542556/45767
JeremyWeir
29

Los he usado en el pasado. Un cliente mío quería bloquear automáticamente a cualquiera que intentara registrarse con un número de teléfono en esta gran lista que tenía, por lo que era solo una gran lista negra.

Spencer Ruport
fuente
19

Si existe una necesidad válida, no veo ningún problema. Tal vez solo desee mostrar una lista de posibilidades por alguna razón y desee poder cambiarla dinámicamente, pero no necesita vincularla a otra tabla.

Kevin
fuente
+1 - En pocas palabras, esta es la respuesta correcta en mi libro
Mark Brittingham
+1 para una respuesta clara y concisa.
Matthew Jones
3
¿Por qué no se puede vincular una tabla de una columna a otra tabla?
Aheho
2
Por qué no? Tome la tabla de códigos de estado como ejemplo. ¿Por qué no usaría eso como una restricción de clave foriegn contra otra tabla con campos de dirección?
Aheho
1
Ese es un gran ejemplo de una época en la que sería una buena idea.
Kevin
11

Un caso que encontré a veces es algo como esto:

La tabla countries_id , contiene solo una columna con ID numérico para cada país.

La tabla countries_description contiene la columna con el ID del país, una columna con el ID del idioma y una columna con el nombre del país localizado.

La tabla company_factories , contiene información para cada fábrica de la empresa, incluyendo el país en el que se encuentra.

Entonces, para mantener la coherencia de los datos y los datos independientes del idioma en las tablas, la base de datos usa este esquema con tablas con una sola columna para permitir claves externas sin dependencias de idioma.

En este caso, creo que la existencia de tablas de una columna está justificada.

Editado en respuesta al comentario por: Quassnoi


(fuente: ggpht.com )

En este esquema, puedo definir una clave externa en la tabla company_factories que no me obliga a incluir la columna Language en la tabla, pero si no tengo la tabla countries_id, debo incluir la columna Language en la tabla para definir la clave externa .

Doliveras
fuente
2
¿Por qué tener countries_id? Para insertar un país, debe conocer su nombre en al menos un idioma, y ​​esto dará como resultado que aparezca un country_id en countries_description. Un country_id sin la entrada countries_description no tiene sentido. "Sr. Barack Obama, presidente de COALESCE (14243, country_name) VALOR NULO DEVUELTO, se reunió hoy con Dmitry Medvedev, presidente de Россия"
Quassnoi
4
@Doliveras: OK, ya veo, +1. Sin embargo, prefiero usar ISO 3166-1 para coutry_code. A diferencia de la identificación numérica, un código de país de 3 letras da una idea de qué país se menciona a casi todas las personas en el mundo que pueden leer el alfabeto latino.
Quassnoi
Aquí hay otra forma que he implementado para acomodar las traducciones de lenguaje natural en la misma tabla. Por supuesto, muchos campos son anulables como resultado, pero puede descargar la integridad de los datos a activadores personalizados. CREATE TABLE "DBA" "myLocalisedTable" ( "entrada_id" INTEGER NOT NULL DEFAULT AutoIncrement, "master_entry_id" INTEGER NULL, "master_entry_label" VARCHAR (200) NULL, "LANGUAGE_ID" INTEGER NULL, (300) NULL "localised_entry_label" VARCHAR.
Vincent Buck
7

Habría casos raros en los que una tabla de una sola columna tiene sentido. Hice una base de datos en la que la lista de códigos de idioma válidos era una tabla de una sola columna utilizada como clave externa. No tenía sentido tener una clave diferente, ya que el código en sí era la clave. Y no había una descripción fija, ya que las descripciones del código de idioma variarían según el idioma para algunos contextos.

En general, cualquier caso en el que necesite una lista autorizada de valores que no tengan ningún atributo adicional es un buen candidato para una tabla de una columna.

Jeremy Bourque
fuente
5

Utilizo tablas de una sola columna todo el tiempo, dependiendo, por supuesto, de si el diseño de la aplicación ya usa una base de datos. Una vez que he soportado la sobrecarga de diseño de establecer una conexión de base de datos, coloco todos los datos mutables en tablas siempre que sea posible.

Puedo pensar en dos usos de tablas de una sola columna OTMH:

1) El elemento de datos existe. Se utiliza a menudo en listas desplegables. También se utiliza para pruebas sencillas de legitimidad.

P.ej. abreviaturas de estados de EE. UU. de dos letras; Códigos postales a los que enviamos; palabras legales en Scrabble; etc.

2) Atributo binario disperso, es decir, en una tabla grande, un atributo binario que será verdadero solo para unos pocos registros. En lugar de agregar una nueva columna booleana, podría crear una tabla separada que contenga las claves de los registros para los que el atributo es verdadero.

P.ej. empleados que tienen una enfermedad terminal; bancos con un año de 360 ​​días (la mayoría usa 365); etc.

-Alabama.

AI Breveleri
fuente
4

No hay problema siempre que contenga valores únicos.

Agnel Kurian
fuente
4

Sobre todo, he visto esto en tablas de tipo de búsqueda, como la tabla de estado que describió. Sin embargo, si hace esto, asegúrese de establecer la columna como clave principal para forzar la unicidad. Si no puede establecer este valor como único, no debería utilizar una columna.

HLGEM
fuente
Si bien el uso de una sola columna aquí probablemente esté bien, tenga en cuenta que también puede configurar restricciones de unicidad en otras columnas.
Stealth Rabbi
2

Yo diría, en general, que sí. No estoy seguro de por qué necesita solo una columna. Hay algunas excepciones a esto que he visto que se usan de manera efectiva. Depende de lo que intente lograr.

No son realmente un buen diseño cuando se piensa en el esquema de la base de datos, pero en realidad solo deberían usarse como tablas de utilidad.

He visto tablas de números que se utilizan con eficacia en el pasado.

Brendan Enrick
fuente
1

El propósito de una base de datos es relacionar piezas de información entre sí. ¿Cómo puede hacer eso cuando no hay datos con los que relacionarse?

Tal vez se trate de algún tipo de tabla de compilación (es decir, nombre + apellido + fecha de nacimiento), aunque todavía no estoy seguro de por qué querría hacer eso.

EDITAR: Podría ver el uso de este tipo de tabla para una lista simple de algún tipo. ¿Para eso lo estás usando?

Matthew Jones
fuente
9
No, el propósito principal de una base de datos es almacenar información.
Spencer Ruport
Pero una hoja de cálculo puede almacenar información. ¿Y cómo es útil la información si es solo un montón de números y letras inconexos sin correlación entre ellos?
Matthew Jones
La información puede ser útil porque la aplicación que usa la base de datos la necesita y no es un conjunto fijo. Es decir, la base de datos es simplemente el lugar más conveniente para colocar la información que utilizará una aplicación de base de datos, ya sea relacional o de otro tipo. Estoy bastante seguro de que estarás de acuerdo en que no estamos creando aplicaciones para demostrar nuestra pureza con respecto al ideal relacional. En cambio, creamos aplicaciones para que sean útiles.
Mark Brittingham
@Mark - Eso es lo que quise decir con una lista simple. Supongo que no me expliqué muy bien.
Matthew Jones
1
@SR: no, el propósito principal de una base de datos es recuperar información. Como las filas de interés a menudo dependen de otros datos, creo que el comentario original de MJ se mantiene.
CurtainDog
1

Sí, siempre que el campo sea la clave principal, como dijiste. La razón es que si inserta datos duplicados, esas filas serán de solo lectura. Si intenta eliminar una de las filas que están duplicadas. no funcionará porque el servidor no sabrá qué fila eliminar.

Eric
fuente
2
Eso es ridículo. Una operación de eliminación sin una clave principal o restricción eliminará todas las filas coincidentes, no las ignorará.
Erik Funkenbusch
1
Por "no funciona", podría significar "no funciona como se esperaba", que cubre la condición "he borrado una fila pero ambas se han ido".
GWLlosa
O, si intenta eliminar un registro en SSMS desde la vista "Abrir tabla", en realidad mostrará un cuadro de diálogo que indica que el registro no se puede identificar de forma única y luego no hacer nada ...
Michael Fredrickson
-1

El único caso de uso que puedo concebir es una tabla de palabras, quizás para un juego de palabras. Accede a la tabla solo para verificar que una cadena es una palabra: seleccione la palabra de las palabras donde palabra =?. Pero hay estructuras de datos mucho mejores para mantener una lista de palabras que una base de datos relacional .

De lo contrario, los datos de una base de datos generalmente se colocan en una base de datos para aprovechar las relaciones entre varios atributos de los datos. Si sus datos no tienen atributos más allá de su valor, ¿cómo se desarrollará esta relación?

Entonces, aunque no es ilegal, en general probablemente no debería tener una tabla con una sola columna.

jmucchiello
fuente
Similar a esta es la tabla de números que es muy útil para dejar de hacer bucles.
u07ch
-1

Todas mis tablas tienen al menos cuatro campos de tecnología, clave principal de serie, marcas de tiempo de creación y modificación y booleano de eliminación suave. En cualquier lista negra, también querrá saber quién agregó la entrada. Entonces, para mí, la respuesta es no, una tabla con una sola columna no tendría sentido excepto cuando se crea un prototipo de algo.


fuente
1
Parece que está mezclando una tabla de datos con una tabla de transacciones. En mi opinión, deberían ser dos cosas distintas.
Josh Noe
-2

Sí, eso está perfectamente bien. pero un campo de identificación no podría dañarlo, ¿verdad?

Eric
fuente
7
De hecho, puede. Cuando tiene una lista definitiva de valores válidos, lo último que desea es un campo de ID porque implica que los valores no son únicos. Si 'LightBlue' es una clave, entonces no querrás que alguien piense que 'LightBlue' con id 1 podría ser diferente de 'LightBlue' con id 4.
Jeremy Bourque
¿Quién dice que la identificación tiene que ser identidad? ¿O parte de la clave?
Eric
3
Podría ser una clave sintética y el campo original podría tener una restricción única.
Mark Canlas