Diseño de base de datos con respecto a entradas dinámicas: ¿una fila o varias filas?

Question

He intentado diseñar un esquema de base de datos para un proyecto paralelo, pero no he podido producir nada con lo que me sienta cómodo. Estoy usando ASP.Net con LINQ para mi acceso a datos:

Voy a permitir que los usuarios especifiquen hasta 10 '' artículos '' cada uno con 2 propiedades numéricas y 1 propiedad referencial, el nombre del elemento.

Si tuviera que poner esta entrada en 1 fila, sería fácilmente igual a más de 30 columnas (mínimo), p. item_1_name (ref) item_1_weight item_1_volume item_2_name ... etc ...

Y no puedo simplemente convertir estas columnas en tablas de referencia, ya que cada propiedad puede variar esencialmente de 1 a 400+.

También pensé que si un usuario solo decide poner 1 elemento en su entrada, el método por el cual creo el objeto para esos datos será estático, ya que con LINQ tendría que verificar si las propiedades y demás son NULL y trabajar en consecuencia. Además, si alguna vez quisiera aumentar la cantidad de elementos permitidos en una entrada, sería un dolor de cabeza trabajar con ellos.

La otra opción que he pensado es simplemente crear una fila para cada elemento y vincularlo con una identificación de entrada. Esencialmente, nunca tendría entradas nulas, pero mi tabla crecería astronómicamente profunda pero no muy ancha, ya que solo habría unas 5 columnas impares.

¿Hay algo que estoy pasando por alto en mi diseño / hay una forma mucho mejor y eficiente de hacer esto?

EDITAR: cuando digo que crecerá astronómicamente, lo digo en este sentido: un usuario puede crear una entrada, y cada entrada probablemente tendrá un grupo de elementos. Entonces, digamos que hacen 1 entrada al día al sitio, podrían tener 3 grupos de artículos, con el número máximo de artículos (10), lo que equivaldría a 30 artículos para esa única entrada. Haga una entrada todos los días durante una semana a ese ritmo y podría tener 210 filas para ese único usuario.

Answer 1

Recomiendo el último diseño que menciona, cree una tabla dependiente con cinco columnas:

CREATE TABLE Items (
  user_id               INTEGER NOT NULL,
  item_id               INTEGER NOT NULL DEFAULT 1,
  numeric_property1     INTEGER,
  numeric_property2     INTEGER,
  referential_property  INTEGER,
  PRIMARY KEY (user_id, item_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
                        ON DELETE CASCADE,
  FOREIGN KEY (item_id) REFERENCES num_items(item_id),
  FOREIGN KEY (referential_property) REFERENCES some_other_table(some_column)
);

Muestro una tabla num_items arriba, que contiene los números del 1 al 10 si desea restringir a los usuarios a 10 elementos como máximo:

CREATE TABLE num_items (item_id INTEGER NOT NULL );
INSERT INTO num_items (item_id) 
  VALUES (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);

Las ventajas de este diseño es que es fácil COUNT () cuántos elementos tiene un usuario determinado, es fácil calcular cosas como MIN () y MAX () para una propiedad determinada, puede aplicar una clave foránea para la propiedad referencial, etc.

Algunas bases de datos tienen una función para declarar la segunda parte de una clave primaria compuesta ( item_id en este caso) como incremento automático, por lo que si especifica el valor para entity_id pero omita item_id , obtiene automáticamente el siguiente valor no utilizado (pero no llena los vacíos si elimina uno). No especificas qué marca de base de datos estás usando, así que te dejo que descubras esta característica.

editar: Como Tony Andrews dice en su respuesta, el número de filas no es un problema. No indica qué marca de base de datos tiene la intención de usar, pero a menos que elija un producto especialmente débil como MS Access, puede confiar en la base de datos para procesar millones de filas fácilmente. Si elige bien los índices y escribe consultas que usan esos índices, la eficiencia no debería ser un problema.

Answer 2

use una sola tabla de elementos:

userId, itemIndex, isReference, numericValue, referenceValue

de esta manera el valor de item_3_name para el usuario 999 se traduce en

999,3, verdadero, nulo, valor

Tendrá que imponer ciertas restricciones usted mismo, por ejemplo. la cantidad máxima de elementos por usuario, etc.

Answer 3

El diseño adecuado de la base de datos sería almacenar cada usuario / elemento en una fila separada. Será mucho más fácil trabajar con él y eliminará la restricción arbitraria de 10 elementos. No diría que crecerá `` astronómicamente profundo '', habrá alrededor de 10 x (no. De usuarios) filas.