una - tablas sql server
¿Es bueno el diseño de una tabla de una columna? (15)
El único caso de uso que puedo concebir es una tabla de palabras tal vez para un juego de palabras. Accedes a la tabla solo para verificar que una cadena sea una palabra: selecciona palabras de 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 en una base de datos generalmente se colocan en una base de datos para aprovechar las relaciones entre los diversos 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ías tener una tabla con solo una columna.
¿Está bien tener una mesa con solo una 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 válidos de EE. UU., Pero no necesita almacenar los nombres de estado detallado.
- Una lista negra de correo electrónico.
Alguien mencionó agregar un campo clave. De la forma en que lo veo, esta única columna SERÍA la clave principal.
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 este es 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 simple lista de algún tipo. ¿Es para eso por lo que lo estás usando?
Habría casos raros en los que una tabla de columna única tiene sentido. Hice una base de datos donde la lista de códigos de idioma válidos era una tabla de columna única 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.
Los he usado en el pasado. Un cliente mío quería bloquear automáticamente a cualquiera que intentase registrar con un número de teléfono en esta gran lista, así que era solo una gran lista negra.
Mayormente lo he visto en tablas de tipo de búsqueda como la tabla de estado que describiste. Sin embargo, si hace esto, asegúrese de configurar la columna como la clave principal para forzar la exclusividad. Si no puede establecer este valor como único, entonces no debe usar una columna.
No hay problema, siempre que contenga valores únicos.
Sí, ciertamente es un buen diseño diseñar una mesa de manera que sea más eficiente. El "Diseño de RDBMS malo" generalmente se centra en la ineficiencia.
Sin embargo, he encontrado que la mayoría de los casos de diseño de columna individual podrían beneficiarse de una columna adicional. Por ejemplo, los códigos de estado generalmente pueden tener el nombre de estado completo 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.
Sí, eso está perfectamente bien. pero un campo de ID no podría dañarlo ¿verdad?
Sí, siempre que el campo sea la clave principal como dijiste que sería. La razón es porque 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.
Si existe una necesidad válida, entonces no veo un problema. Tal vez solo desee una lista de posibilidades para mostrar por algún motivo y desee poder cambiarla dinámicamente, pero no tiene necesidad de vincularla a otra tabla.
Todas mis tablas tienen al menos cuatro campos tecnológicos, clave primaria 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 hace prototipo de algo.
Un caso que encontré a veces es algo como esto:
Table countries_id , contiene solo una columna con ID numérico para cada país.
Table countries_description , contiene la columna con ID de país, una columna con ID de idioma y una columna con el nombre de país localizado.
Table company_factories , contiene información para cada fábrica de la empresa, incluido el país en el que se encuentra.
Por lo tanto, 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 solo una 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 de: Quassnoi
http://lh5.ggpht.com/_7ON9I_WO6GU/SikFHBtzcxI/AAAAAAAAA-4/6MrVUCHGoWU/s800/taules.png
En este esquema puedo definir una clave externa en la tabla company_factories que no requiere que incluya 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 .
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, pongo todos los datos mutables en las tablas siempre que sea posible.
Puedo pensar en dos usos de tablas de una sola columna OTMH:
1) El elemento de datos existe. A menudo se usa en listas desplegables. También se usa para pruebas simples de legitimidad.
P.ej. dos abreviaturas del estado de los EEUU; 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 cuales 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.
Yo diría en general, sí. No estoy seguro de por qué necesita una sola columna. Hay algunas excepciones a esto que he visto usar de manera efectiva. Depende de lo que estás tratando de lograr.
No son realmente buenos diseños cuando estás pensando 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 usadas con eficacia en el pasado.
En términos de relational algebra esta sería una relación unaria, que significa " esto existe "
Sí, está bien tener una tabla que defina esa relación: por ejemplo, para definir un dominio.
Los valores de dicha tabla deben ser claves naturales naturales, por supuesto.
En prime numbers viene a la mente una tabla de búsqueda de prime numbers .