El número máximo de columnas en una tabla ordinaria es 1024. El número máximo de columnas en una tabla ancha (dispersa) es 30 000. Las columnas dispersas generalmente se usan cuando tiene muchas columnas, pero la mayoría de ellas son NULL .

En cualquier caso, hay un límite de 8060 bytes por fila , por lo que las columnas dispersas no ayudarán.

A menudo, tener miles de columnas en una tabla indica que hay problemas con el diseño y la normalización de la base de datos.

Si está seguro de que necesita estos mil valores como columnas, no como filas en una tabla relacionada, entonces la única solución alternativa que se le ocurre es dividir la tabla verticalmente.

Por ejemplo, tiene una Table1 1 con ID de columna (que es la clave principal) y otras 1000 columnas. Table1 en Table1 y Table2 . Cada uno tendrá el mismo ID que una clave principal y 500 columnas cada uno. Las tablas se vincularían 1:1 mediante la restricción de clave externa.

Los tipos de datos que se usan y la densidad de cuántos datos en una fila son nulos determina la efectividad de las columnas dispersas. Si se completan todos los campos de una tabla, en realidad hay más gastos generales al almacenar esas filas y hará que alcance ese tamaño de página máximo más rápido. Si ese es el caso, no use columnas dispersas.

Vea cuántos tipos de datos puede convertir de estáticos a de longitud variable (varchar, nvarchar, varbinary). Esto podría comprarle algo de espacio adicional en la página, ya que los campos de longitud variable se pueden colocar en páginas de desbordamiento, pero conlleva una sobrecarga de 24 bytes para el puntero en la página de desbordamiento. Sospecho que estaba pensando que las columnas dispersas le permitirían almacenar 30 000 columnas... esta sería solo la circunstancia en la que tenía una tabla ancha donde la mayoría de las columnas son NULA.

MongoDB no será su respuesta... al menos no sin una gran cantidad de refactorización. No podrá aprovechar sus procedimientos almacenados existentes. Puede que sea la mejor opción para usted, pero hay muchas cosas a tener en cuenta al cambiar a MongoDB. Su capa de acceso a datos deberá reconstruirse a menos que simplemente esté conservando sus datos en la estructura relacional como documentos JSON :). Supongo que ese no es el caso.

Supongo que tiene mesas anchas y están densamente pobladas... en base a esa suposición, esta es mi recomendación.

Divida la tabla como sugirió Vladimir, pero cree una vista que una todas estas tablas para que parezca una sola tabla. Ahora tienes la misma estructura que tenías antes. A continuación, agregue un lugar de activación a la vista para actualizar las tablas. Esta es una forma de obtener lo que desea sin tener que realizar una refactorización importante de su código. Hay un código que debe agregar para el disparador, pero mi experiencia ha sido que es fácil de escribir y la mayoría de las veces no escribí el código sino que creé un script para generar el código para todas las vistas para las que tuve que hacer esto desde era repetitivo.