database - learning - ¿Cuántos campos son "demasiados" en una tabla?
normalization forms in dbms (12)
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 del tipo de opciones (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.
El signo más obvio que una tabla requiere 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.
La cantidad de campos generalmente no es un problema, pero desea asegurarse de que su base de datos esté correctamente noralizada. La tercera forma normal es un buen comienzo.
Las tablas de 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 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.
Encuentre un buen administrador de base de datos y alquile a corto plazo para revisar el plan, si está en el presupuesto. Pagará en el largo plazo.
Si tiene que preguntar, "¿Hay demasiados campos en esta tabla?" Entonces probablemente haya.
Treinta campos no son demasiados; solo tiene que asegurarse de que sus datos estén debidamente normalizados (para lo cual hay muchas guías en la web).
Según su edición, donde 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
Entonces puedes vincular todas tus 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.
Un signo revelador es justo lo que dijiste. É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 yo sugeriría que también lo repases ... solo puede ayudarte a crecer en tu carrera :)
no hay límite arbitrario; suficiente para hacer el trabajo es una buena regla de oro
si tienes un mejor diseño de db, sugiéralo
si quieres comentarios más detallados, publica el esquema
La guía de la guerrilla para la normalización por defecto:
- Una tabla debe tener una clave principal y como máximo otra columna.
- Rompe la regla número 1 tan a menudo como se requiera.
El término "demasiados" es relativo ... No debe dividir una tabla solo para reducir el número de campos, especialmente si en cada consulta tendrá que volver a unirlos 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.
OLTP
Desde mi experiencia en el diseño de bases de datos, hay muy pocas tablas en una base de datos OLTP normalizada que contienen una cantidad increíblemente grande de columnas.
Las columnas IMO 30 son demasiadas.
Para mí, no más del 10% de mis tablas OLTP tienen un gran número (> 10) de columnas.
OLAP
Ahora, si va a hacer una estructura dimensional / de informes, algunas personas pueden considerar que una tabla de 30 columnas es estrecha.
No hay 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 la respuesta de Apocalisp no es muy clara. En el opuesto, se puede hacer una tabla a partir de miles de campos, siempre que se respeten las reglas de forma normales .
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 interrelacionadas, publicado por primera vez en 197?) Dividir las informaciones confidenciales en otra tabla con la misma relación 0-1 entre principal y sub. 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.
Por supuesto, la respuesta estándar es que 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 sugerí para una pregunta diferente (que podría ser útil para usted) :
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 fue downvoted , y probablemente con una buena 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.
Editar: ya que dices que contendrá cosas como la configuración por usuario (por ejemplo, el color del widget), en realidad recomendaría 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.