¿Cómo implementaría una "tabla" muy amplia?

Question

Digamos que está modelando una entidad que tiene muchos atributos (más de 2400), mucho mayor que el límite físico en un motor de base de datos dado (por ejemplo, ~ 1000 SQL Server). Sin saber nada sobre la importancia relativa de estos puntos de datos (cuáles son los más utilizados/calientes) además de las claves de dominio/candidato, ¿cómo lo implementaría?

A) EAV. (boo ... Herramientas nativas relacionales lanzadas por la ventana.)

B) Siga recto. La primera tabla tiene una clave principal y 1000 columnas, hasta el límite. La siguiente tabla es 1000, ajena a la primera. La última tabla es los 400 restantes, también con clave externa.

C) Raya uniformemente en las tablas ceil(n/limit). Cada tabla tiene un número par de columnas, la clave externa para la primera tabla. 800, 800, 800.

D) Otra cosa ...

Y por qué?

Editar: Esta es más una pregunta filosófica/genérica, no vinculada a ningún límite o motor específico.

Editar^2: Como muchos han señalado, los datos probablemente no se normalizaron. Por lo general, las limitaciones comerciales en el momento hicieron que la investigación profunda sea imposible.

Answer 1

Mi solución: investigar más. Específicamente, establezca si la tabla está realmente normalizada (en 2400 columnas esto parece altamente improbable).

Si no, reestructurar hasta que esté completamente normalizado (momento en el que no es probable que sean menos de 1000 columnas por tabla).

Si ya está plenamente normalizado, establecer (en lo posible) frecuencias aproximadas de población para cada atributo. Coloque los atributos que ocurren más comúnmente en la tabla "home" para la entidad, use 2 o 3 tablas adicionales para los atributos menos frecuentes. (Trate de hacer que la frecuencia de aparición de los criterios para determinar qué campos deben ir en las tablas.)

considerar sólo EAV de atributos muy baja densidad de población (preferentemente, no en todos).

Answer 2

Sin tener muchos conocimientos en esta área, creo que una entidad con tantos atributos realmente necesita un rediseño. Con eso me refiero a dividir lo grande en partes más pequeñas que están lógicamente conectadas.

Answer 3

rotaría las columnas y las haría filas. En lugar de tener una columna que contenga el nombre del atributo como una cadena (nvarchar), podría tenerla como fkey para volver a una tabla de búsqueda que contiene una lista de todos los atributos posibles.

giratorio que de esta manera se quiere decir:

• no tienen masas de tablas para registrar los detalles de un solo elemento
• no tienen tablas anchas masivamente
• Sólo puede almacenar la información que necesita debido a la rotación (si no desea almacenar un atributo en particular, simplemente no tiene esa fila)

Answer 4

Usaría una tabla de atributos de uno a muchos con una clave externa a la entidad.

Ej

entidades: ID,

attrs: Identificación, ENTITY_ID, attr_name, valor

AÑADIDO

O como Butler Lampson diría, "todos los problemas en Ciencias de la Computación pueden resolverse por otro nivel de direccionamiento indirecto "

Answer 5

1. Me gustaría ver mucho más detalladamente el modelo de datos . ¿Es la tercera forma normal de ? ¿Hay grupos de atributos que deban agruparse lógicamente en en sus propias tablas?

2. asumiendo que es normalizada y la entidad verdaderamente tiene atributos 2400+, que no estaría tan rápida a abuchear un EAV model. En mi humilde opinión, es la mejor solución más flexible para la situación que ha descrito. Le brinda soporte integrado para datos dispersos y le brinda una buena velocidad de búsqueda ya que los valores para cualquier atributo dado se pueden encontrar en un solo índice.

Answer 6

El elemento clave para mí es esta pieza:

Sin saber nada acerca de la importancia relativa de estos puntos de datos (cuáles son calientes/utilizado más a menudo)

Si tiene una idea de qué campos son más importantes, colocaría esos campos más importantes en la tabla "nativa" y dejaría que una estructura EAV maneje el resto.

Lo que pasa es que, sin esta información, en realidad estás disparando a ciegas. Ya sea que tenga 2400 campos o solo 24, debe tener algún tipo de idea acerca del significado (y por lo tanto de la importancia relativa, o al menos de agrupaciones lógicas) de sus datos.

Answer 7

Uso Sparse Columns para un máximo de 30000 columnas. La gran ventaja sobre EAV o XML es que puede usar Filtered Indexes junto con columnas dispersas, para búsquedas muy eficientes sobre atributos comunes.

Answer 8

Me gustaría utilizar el enfoque vertical (aumentar el número de filas) en lugar de horizontal (aumentar el número de columnas).

Puede probar este enfoque como

Tabla - Identificación, nombre_propiedad - valor_propiedad.

La ventaja con el enfoque es decir, sin necesidad de modificar/crear una tabla cuando se introduce la nueva propiedad/columna.