¿Cuántos campos son "demasiados" en una tabla?

Question

Tengo un compañero de trabajo que está planificando una base de datos para una nueva aplicación que tendrá varias tablas con más de 30 campos cada una. ¿Es esto excesivo? Tal vez no soy lo suficientemente profesional como para entender.

Editar: Además, muchos de los campos son tipo de opción (como en un formulario de solicitud, le gustaría que su widget sea amarillo o verde, tiene un campo para 'color' con una enumeración) . Es bastante probable que estos se agreguen o eliminen con el tiempo. Realmente no he hecho el diseño de la base de datos y trato de evitarlo, así que tal vez estoy siendo completamente estúpido, pero seguramente hay una mejor manera de hacerlo.

Answer 1

no hay límite arbitrario; suficiente para hacer el trabajo es una buena regla general

si tiene un mejor diseño db, sugieren que

si desea una retroalimentación más detallada, publicar el esquema

Answer 2

Por supuesto, la respuesta estándar es depende. Una tabla con tantos campos en realidad podría tener mucho sentido en algunas situaciones.

Piense en los datos que almacenará allí. ¿Es probable que muchos de estos campos sean NULL? ¿Cuál es la probabilidad de que estos campos cambien (p. Ej .: se agregan más)?

Si solo ciertos campos se aplican a ciertos objetos, quizás piense en poner esos campos en otra tabla. De forma alternativa, almacene solo los campos básicos comunes en una tabla y la información adicional en otra tabla, una fila por campo. Como I suggested para a different question (which might be helpful to you):

 
refs (id, title, refType) 
-- title of the reference, and what type of reference it is 

fieldDef (id, fieldName, refType, dataType) 
-- name of the field, which reference types it applies to, and 
-- what type of data is stored in these fields (ISDN number, date, etc) 

fields (refId, fieldId, value) 
-- where you actually add data to the references. 

Tenga en cuenta que esto era downvoted, y probablemente con razón. Esta es una opción, no necesariamente la mejor opción, pero sigue siendo un método viable. Sin embargo, la mejor respuesta en la pregunta a la que me he vinculado es la mejor solución.

---

edición: ya que dices que será la celebración de cosas como la configuración por usuario (por ejemplo: el color Reproductor), yo realmente recomiendo el método descrito anteriormente (con las tres tablas). Lo más probable es que la mayoría de las personas dejen las cosas en forma predeterminada, por lo que tendrás almacenada una pila de información inútil. Lea mi respuesta en la otra pregunta porque otros lectores han señalado las deficiencias de este método.

Answer 3

El número de campos generalmente no es un problema, pero desea asegurarse de que su base de datos esté correctamente noralizada. Third normal form es un buen comienzo.

Answer 4

Si tiene que preguntar, "¿Hay demasiados campos en esta tabla?" Entonces probablemente haya.

Answer 5

Un signo revelador es justo lo que ha dicho. Él tiene campos que en teoría deberían dividirse en una tabla diferente. Otro regalo es la presencia de muchos campos opcionales.

Yo diría que un curso de diseño de bases de datos está en orden para su DB "Experto". Y sugeriría que también lo repases ... solo puede ayudarte a crecer en tu carrera :)

Answer 6

Las tablas de la base de datos pueden tener legítimamente 30 o más campos en ellas. Lo que debe observar es la normalización de los datos y si esa normalización tiene algún sentido.Por lo general, también cambiará en el futuro. Pero, quieres intentar minimizar eso.

Por ejemplo, si tiene una tabla que tiene direcciones, ¿incluye los campos de ciudad, estado y código postal en esa tabla? ¿O solo incluye un campo que "apunta" a un registro en una tabla separada para esos valores? La tabla separada contendría combinaciones únicas de ciudad, estado y código postal. El efecto de dividir los datos en dos tablas es una reducción en la cantidad de datos almacenados (más probable pero no absoluto) pero un poco de complejidad añadida cuando se ejecutan consultas en la base de datos. Ahora, tiene que lidiar con 2 tablas en lugar de solo una. Pero, en el lado positivo, es mucho más limpio y mucho más pequeño (probable).

La verdadera respuesta es que está bien dejar los datos de zip de la ciudad-estado en la tabla de direcciones en las circunstancias correctas. O bien, es posible que desee "normalizarlo". Ambos están bien.

Busque un buen administrador de bases de datos y alquilelas a corto plazo para revisar el plan, si está en el presupuesto. Pagará en el largo plazo.

Answer 7

Treinta campos no son demasiados, solo tiene que asegurarse de que sus datos estén normalizados correctamente (para lo cual hay muchas guías en la web).

Según su edición en la que especifica que muchas columnas serán campos de tipo de opción que pueden agregarse o eliminarse a lo largo del tiempo, le sugiero que la siguiente es una mejor idea.

BaseTable: 
    Id 
    NonOptionFields 
OptionTable: 
    Id 
    OptionName 
    OptionValue 

Luego puede vincular todas sus opciones al registro base. Esto significa que no tendrá que agregar y eliminar columnas a las tablas todo el tiempo de forma normalizada para lograr lo que desea.

Answer 8

El signo más obvio que una tabla requiere la normalización que he visto son los campos que terminan en enteros: CouponCode1, CouponCode2, CouponCode3 ... entiendes el punto. Sin embargo, habrá excepciones a la regla como siempre.

Answer 9

guía de la guerrilla a la normalización por defecto:

1. Una tabla debe tener una clave principal y como máximo otra columna.
2. Rompe la regla número 1 solo las veces que sea necesario.

Answer 10

No hay ninguna restricción en el número de campos en la teoría de la base de datos. Una tabla puede limitarse a una clave principal (incluso si esta clave primaria está compuesta por 2 campos), lo que significa que Apocalisp's answer no es muy claro. En el opuesto, se puede hacer una tabla a partir de miles de campos, siempre que se respete normal form rules.

Cuando los grupos de campos están obviamente infrautilizados en una tabla, puede ser inteligente dividir este grupo de campos en otra tabla con una relación 0-1 entre la tabla principal y la tabla "sub".

Por razones de seguridad, a menudo también se propuso (hace mucho tiempo: ¿creo que fue mi primer libro de bases de datos relacionadas, publicado por primera vez en 197?) Dividir las informaciones confidenciales en otra tabla con el mismo 0-1 relación entre principal y secundario. Entonces fue posible restringir fácilmente el acceso del usuario a la tabla "sub". Tal configuración ahora se puede administrar fácilmente a través de vistas.

Answer 11

El término "demasiados" es relativo ... No debe dividir una tabla solo por el simple hecho de reducir el número de campos, especialmente si en cada consulta va a tener que volver a unirlos juntos porque son esencialmente relaciones uno-a-uno. Si los campos se pueden dividir en un objeto lógico separado, entonces tendría sentido.Por ejemplo, en lugar de almacenar campos de direcciones en una tabla de clientes, podrían moverse a una tabla de direcciones separada. Este es un ejemplo crudo, pero ilustra mi punto.

Answer 12

OLTP

Desde mi experiencia de diseño de bases de datos, hay muy pocas tablas de una base de datos OLTP normalizado que contienen un increíblemente gran número de columnas.

IMO 30 columnas es demasiadas.

Para mí, no más del 10% de mis tablas OLTP tienen un gran número (> 10) de columnas.

OLAP

Ahora bien, si usted va a hacer una estructura/informes dimensionales, algunas personas pueden considerar una mesa 30 de la columna a ser estrecha.