Estoy con el campamento Normalize.
Éstos son algunos consejos para ayudarle a empezar:
de inicio con un proceso para asignar algún identificador único arbitraria a cada "persona" . Llame a esto PersonId o algo así. Este identificador se llama una clave sustituta. El único propósito de una clave sustituta es garantiza una relación de 1 a 1 entre él y una persona real en el mundo real. Use la clave sustituta cuando asocie el valor de algún otro atributo a una "persona" en su base de datos.
A medida que desarrolla el diseño de su base de datos, puede encontrar las claves sustitutivas necesarias (o al menos útiles) para algunos otros atributos también.
Mire cada atributo que desea administrar. Haga la siguiente pregunta: ¿Alguna persona tiene solo un valor para este atributo?
Por ejemplo, cada persona tiene exactamente una "Fecha de nacimiento". Pero, ¿cómo pueden tener "pasatiempos"? Probablemente de cero a muchos. Los atributos de un solo valor (por ejemplo, fecha de nacimiento, altura, peso, etc.) son candidatos para ir a una tabla común con PersonId como la clave. El número de atributos en cada tabla no debería ser en este punto.
Atributos de múltiples valores como Hobby necesitan un tratamiento ligeramente diferente . Es posible que desee crear tablas separadas para cada atributo multivalor. Utilizando Hobbies como un ejemplo , puede crear la siguiente tabla PersonHobby(PersonId, Hobby). Una fila en esta tabla puede parecer algo así como: (123, "Stamp Collecting"). De esta forma, puede registrar tantas pasatiempos como sea necesario para cada persona, uno por fila. Haga lo mismo con "Interés", "Habilidad", etc.
Si hay un buen número de atributos de varios valores donde la combinación de PersonId + Hobby determinan nada más (es decir. Que no tienen nada interesante para registrar información sobre esta persona que realiza este "hobby" o "interés" o "Habilidad") puede agruparlos en una tabla de valor-atributo que tiene una estructura algo así como PersonAV(PersonId, AttributeName, Value). Aquí una fila podría ser parecida a: (123, "Hobby", "Stamp Collecting").
Si usted va esta ruta, también es una buena idea para sustituir la AttributeName en la tabla PersonAV de una clave sustituta y crear otra tabla para relacionar esta clave a su descripción. Algo como: Attribute(AttributeId, AttributeName). Una fila en esta tabla se parecería a (1, "Hobby") y una fila correspondiente PersonAV podría ser (123, 1, "Stamp Collecting"). Esto es comúnmente hecho para que si alguna vez necesita saber qué AttributeNames son válidos en su base de datos/aplicación tiene un lugar para buscarlos. Piense en cómo puede validar si el "Interés" es un valor válido para AttributeName o no; si no ha registrado a alguna persona que tenga ese AttributeName, entonces no hay registro de ese en su base de datos. ¿Cómo puede saber si debería existir o no? ¡Búscalo en la tabla Attribute!
Algunos atributos pueden tener relaciones múltiples y eso también influirá en cómo se normalizan las tablas. No lo hice vea cualquiera de estas dependencias en su ejemplo, así que considere lo siguiente: Supongamos que tenemos un almacén lleno de piezas, el PartId determina que es WeightClass, StockCount y ShipCost. Esto sugiere una tabla algo así como: Part(PartId, WeightClass, StockCount, ShipCost). Sin embargo, si existe una relación entre atributos no clave, entonces se deben tener en cuenta. Por ejemplo, suponga que WeightClass directamente determina ShipCost. Esto implica que WeightClass solo es suficiente para determinar ShipCost y ShipCost se debe tener en cuenta fuera de la tabla Part.
La normalización es un arte bastante sutil. Debe identificar las dependencias funcionales que existen entre todos los atributos en su modelo de datos para hacerlo correctamente. Solo crear las dependencias funcionales requiere un poco de reflexión y consideración, pero es fundamental para lograr el diseño adecuado de la base de datos.
Lo invito a tomarse el tiempo para normalizar el estudio un poco más antes de construir su base de datos. Pasar unos días aquí será más que rentable. Intente hacer algunas búsquedas de Google/Wikipedia para "Dependencia funcional", "Normalización" y "Diseño de la base de datos". Lea, estudie, aprenda y luego compárelo bien.
Las sugerencias que he hecho con respecto a la normalización del diseño de su base de datos son solo un indicio de la dirección que podría necesitar tomar. Sin tener una buena comprensión de todos los datos que está tratando de administrar en su aplicación, cualquier consejo dado aquí debe tomarse con un "grano de sal".
+1 para la normalización –
Los datos se usarán en un motor de búsqueda para encontrar coincidencias de perfiles. ¿Esto afecta lo que estoy haciendo? – Ash
si va a recuperar de un RDBMS, entonces normalice.Afectará lo que está haciendo de manera positiva – Randy