número máximo de campos en una tabla

[gdb7]

Mi consulta es la siguiente, ¿cuantos campos puede llegar a tener una tabla en una base de MySQL? ¿todos los que quiera? ¿es recomendable tener por ejemplo una tabla con 60 campos?
En mi caso una tabla tendría aproximadamente 60 campos del tipo varchar(255)

espero sugerencias

Saludos y Gracias!

[TolaWare]

No se cual es el límite, pero dudo que encuentres una entidad del mundo real, o virtual que tenga tantos atributos. En todo caso si lo encuentras tendrías que reveer el diseño porque algo está mal.

Te cuento que he hecho algunas aplicaciones muy grandes (digamos unas 400 clases en total y 6 capas) y la tabla que más atributo tenía era una clase de seguridad que contenía 25 atributos.

A lo que voy es que si el diseño de la BD está bien hecho, no creo que tengas más de 20 atributos por tabla.

[Carxl]

Hola gdb7, sí, efectivamente me parece exagerado una tabla de 60 atributos, o por lo menos nunca me he pasdo de los 18 campos y una de 60???????!! ??. No creo!

Saludos!

[abulon]

Estoy de acuerdo.....Imaginate que hagas consultas y tu ancho de ancho de banda es muy pequeño... ....seria desesperante ..saludos

[Edypu]

No hay limite para la creacion de campos, pero recuerden las bases de datos tienen que estar normalizadas.

El tipo de dato para las asignaciones de datos es muy importante.

Un saludo.

[El-Duque]

Pues siento decirles que si hay límites, cuanto como máximo no lo sé, he llegado a este post buscando la respuesta, porque necesito 141 campos y no puedo tener tantos, menos mal que en la construcción de la BD me quedé en los 110 y no llegué hasta los 141, así que el límite está por debajo de los 110 campos.

Con respecto al trabajo que estoy haciendo, pues os picará la curiosidad de que necesita tanto, es una intranet para una cadena hotelera.

Nunca aceptéis un trabajo de esta índole sino vais a ganar un pellizco gordo.

[ToFuS]

No se, pero para que una tabla tengo 141...

Hay algo del diseño que deberias de mirar, SEGURO que se puede escalonar en varias tablas.

Un saludo.

[El-Duque]

No claro que se puede rediseñar, basta con dividirlo en varias tablas y relacionarlas por un ID.

[Edypu]

Tu BD con 110 campos no cumple las formas normales

Iniciado por El-Duque

No claro que se puede rediseñar, basta con dividirlo en varias tablas y relacionarlas por un ID.

tu mismo lo dices.

dale un vistaso a http://www.wikilearning.com/diseno_d...-wkc-21129.htm en especial el punto 4 normalización.

un saludo.

[cala932]

Hola, estuve leyendo los post, y si en cuanto al diseño de la estructura de la BD la normalizacion es una de las cosas mas importantes a tener en cuenta, no solo para el diseño presente sino para futuro, ya que si tienes todas las tablas bien normalizadas en caso de crecimiento de la misma base o de las tablas, te sera muy facil hacerlo e incluso te ahorrara codigo y simplicidad en operaciones ABM. Con respecto a lo que comentabas gdb7

En mi caso una tabla tendría aproximadamente 60 campos del tipo varchar(255)

Todos los campos varchar (60) de 255 caracteres me parece que convendria revisarlo, si quieres puedes comentar un poco acerca de tu base de datos y quizas entre todos podamos darte recomendaciones etc, es una sugerencia. Saludos

[pepeverastegui]

pues temo decirles que hay veces uqe no se pueden normalizar por mas que uno les busque, yo tengo una tabla con 101 campos, trabajo para un ingenio azucarero y el problema es que como se manejan diferentes lineas de credito entonces debe de haber un campo para cada linea sobre el importe a cobrar y el aplicado y asu ves cada linea diferente para descuentos de terceros, y como debe de conocerce el importe individual no se puede juntar los descuentos en un solo campo

[gnzsoloyo]

No, pero por tu descripción, esa misma tabla se puede descomponer en diferentes relaciones, dependiendo del análisis del sistema, lo qu epodría dar lugar a una enorme nosrmalización que mejorase la performance global.
Por otro lado, si lo que quieres es discutir las posibilidades de eso, deberías abrir un post propio nuevo y no resucitar muertos. El inicial tiene ya casi cuatro años y los moderadores suelen cancelar los temas cuando los resucitas...

[hecturt]

Yo creo que es relativamente facil llegar a tener una tabla con muchos campos.
Por ejemplo, si quiero hacer pongamos por caso una guia de restaurantes. Cada restaurante tendrá:
-Nombre
-Pais
-Ciudad
-Dirección
-Nº
-Zona
-Telefono
-Web
-Mail
-Tipo de retaurante
-Tipo de cocina
-Horario
-Formas de pago
-Precio medio
-Puntuación

Con estos campos ya llevo 15. Si quiero añadir caracteristicas para clasificarlos:

-Terraza
-Para celíacos
-Comida para llevar
-Con vistas
- etc... Facilmente llegaria a 20 o 25 características.

Con todo esto es facil llegar a duplicar el nº de campos si queremos afinar más.
He mirado maneras de normalizar el tema, pero la verdad es que no se me ocurre la manera de hacerlo.

[pepeverastegui]

Pues no se la verdad cuantos campos soporte al final una tabla de mysql, pero algo si les digo mas de 100 si los soporta y tambien soporta mas de 500'000 registros, que yo ya tengo eso.

Aunque al final opte por crear 3 tablas apartir de una de 110 campos, para que no se hiciera tan extensa y las relacione por medio de una clave. Mi problema estuvo en el desarrollo de un sistema para pago a cañeros, y como son muchos los descuentos que se manejan por eso mismo se extienden los numeros de campos.

[gnzsoloyo]

y como son muchos los descuentos que se manejan por eso mismo se extienden los numeros de campos.

Muchos descuentos aplicados a sueldos y jornales no implican muchos campos en la tabla pagos, sino tablas adicionales donde se modelen esos adicionales y/o descuentos asignados. Y eso más bien suena a relación N:M entre una entidad y una posible entidad con subcategorías.
Me parece que estás planteando mal el modelo.

[pepeverastegui]

pues a lo mejor, si pero fue lo que mejor se me ocurrio, el sistema de pagos y gerenacion de textos para interfactura, en fin el programa al 100% que no es cosa facil, lo hice en 4 dias. Ahora estoy pensando en rediseñar y acomodar mejor las funciones.

El problema aqui es que se maneja 2 campos por descuento, 1 para capital a descontar y el otro para el interes, ahora aqui el problema es que hay personas que cuentan con los primeros 20 descuentos, y otroas que nada mas cuentan con los ultimos 15 o asi. Tambien pense en ves de hacer 100 campos mejor hacer una tabla detalle donde cada registro indica un descuento diferente, pero se me iba a extender un mundo de registros.

[gnzsoloyo]

Tambien pense en ves de hacer 100 campos mejor hacer una tabla detalle donde cada registro indica un descuento diferente, pero se me iba a extender un mundo de registros.

Si, pero no solo es la forma correcta de hacerlo, sino que estás perdiendo la perspectiva de que es muchísimo más simple para realizar cálculos tener pocas columnas que tener que nombrar una a una todas ellas. A fin de cuentas, no vas a hacer ese cálculo en forma manual, pero sí vas a tener que escribir la consulta base de ese modo.
Te estás perdiendo en minucias. Ya existen modelos de bases de datos que operan en este tipo de casos y lo que te conviene es analizarlos para saber aprovecharlos. Yendo por el camio de "ahorrar" tablas o registros lo único que lograrás es hacer un sistema complicado de mantener y más complicado de modificar si se necesita.
Trata de acercarte más a los modelos ya probados. No por que sí se hacen así.

Library of Free Data Models from DatabaseAnswers.org