mysql - tool - workbench español
¿Qué es mejor, muchas mesas pequeñas o una gran mesa? (9)
A menos que cada persona tenga el mismo número de pasatiempos (es decir, todos tienen 2 pasatiempos en la lista), se debe normalizar.
Los campos que siempre son de 1 a 1 con la persona deben estar en la misma tabla. Edad por ejemplo. Ninguna persona tendrá dos edades diferentes.
Tengo una base de datos que almacenará perfiles de personas. Estas personas tienen alrededor de 50 campos posibles.
Algunas son cosas comunes como, nombre, apellido, correo electrónico, número de teléfono.
Otros son cosas como hobbies, habilidades, intereses
Algunos son altura, peso, color de piel.
Cada uno de estos grupos es utilizado por el sistema en diferentes momentos. En términos de poder negociar a través de la base de datos, preferiría tener 7 tablas cada una de aproximadamente 8 campos. ¿Cuál es la mejor práctica para hacer?
EDITAR: los datos se usarán en un motor de búsqueda para encontrar coincidencias de perfil. ¿Esto afecta lo que estoy haciendo?
Es difícil de decir y se basa en lo que requiere la aplicación. Yo diría que analicemos la normalización de la base de datos, ya que le mostrará cómo normalizar la base de datos y en eso debería arrojar luz sobre lo que le gustaría separar en sus propias tablas, etc.
Estoy con el campamento Normalize.
Aquí hay algunos consejos para comenzar:
Comience con un proceso para asignar algún identificador único arbitrario a cada "persona". Llámalo PersonId o algo así. Este identificador se llama clave sustituta. El único propósito de una clave sustituta es garantizar una relación de 1 a 1 entre ella 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 desarrolle el diseño de su base de datos, es posible que necesite claves sustitutivas necesarias (o al menos útiles) para otros atributos.
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. La cantidad de atributos en cada tabla no debe ser motivo de preocupación en este punto.
Los atributos valorados múltiples como Hobby necesitan un tratamiento ligeramente diferente. Es posible que desee crear tablas separadas para cada atributo multivalor. Usando Hobbies como ejemplo, puede crear la siguiente tabla PersonHobby(PersonId, Hobby) . Una fila en esta tabla puede verse más o menos así: (123, "Stamp Collecting") . De esta forma, puede registrar tantos 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 PersonId + Hobby la combinación de PersonId + Hobby no determina nada más (es decir, no tiene nada interesante que registrar sobre esta persona que hace este "Hobby" o "Interés" o "Habilidad") podría agruparlos en una tabla de Valor-Atributo que tenga una estructura algo así como PersonAV(PersonId, AttributeName, Value) . Aquí una fila podría verse así: (123, "Hobby", "Stamp Collecting") .
Si sigue esta ruta, también es una buena idea sustituir el nombre de AttributeName en la tabla PersonAV por una clave sustituta y crear otra tabla para relacionar esta clave con su descripción. Algo como: Attribute(AttributeId, AttributeName) . Una fila en esta tabla se vería como (1, "Hobby") y una fila PersonAV correspondiente podría ser (123, 1, "Stamp Collecting") . Esto se hace comúnmente 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 "Interest" es un valor válido para AttributeName o no; si no ha grabado a una persona que tenga AttributeName entonces no hay ningún registro de ese AttributeName en su base de datos, ¿cómo sabe si debería existir? ¿o no? ¡Búscalo en la tabla de Attribute !
Algunos atributos pueden tener relaciones múltiples y eso también influirá en cómo se normalizan las tablas. No vi ninguna de estas dependencias en su ejemplo, así que tenga en cuenta lo siguiente: Supongamos que tenemos un almacén lleno de piezas, PartId determina su WeightClass , StockCount y ShipCost . Esto sugiere una tabla algo así como: Part(PartId, WeightClass, StockCount, ShipCost) . Sin embargo, si existe una relación entre los atributos que no son clave, entonces deben ser eliminados. Por ejemplo, suponga que WeightClass determina directamente el ShipCost . Esto implica que solo WeightClass es suficiente para determinar ShipCost y ShipCost 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.
Te animo a que te tomes un tiempo para estudiar la normalización un poco más antes de construir tu 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".
No hay una organización de bases de datos que sea 100% correcta, solo hay una que sea lo suficientemente buena para sus propósitos. Si no prevé sobrepasar las capacidades de un solo buen servidor de base de datos en el futuro, entonces normalice los datos y utilice muchas restricciones como claves externas, eliminaciones en cascada y eso hará que su base de datos sea un placer trabajar con ella. Por otro lado, si observa las bases de datos de muchas aplicaciones que tienen miles de millones de solicitudes, encontrará que renuncian a muchas de estas sutilezas en nombre del rendimiento y la escalabilidad.
No hay una respuesta correcta a esta pregunta porque depende en gran medida de cuándo y cómo va a utilizar sus datos, con qué frecuencia cambiará y cuál será el volumen de uso en la base de datos.
Lo que personalmente haría sería organizar sus datos en entidades lógicas y crear tablas basadas en esas entidades. Esto es al menos donde comenzaría.
OMI, es más importante preocuparse por la calidad de los datos almacenados que la cantidad de tablas que necesita.
Por ejemplo, ¿necesita hacer un seguimiento de los cambios? Si John tenía 5''2 "en enero de 2007 y 5''11" en octubre de 2010, ¿quieres saber? Si es así, deberá separar a la persona de la altura en dos tablas.
¿Qué hay de los pasatiempos? ¿Se les permite tener solo 3 pasatiempos? ¿Pueden tener más / menos? ¿Es esto algo que le gustaría consultar en el futuro? Si es así, necesitas una tabla separada.
Debe leer sobre el diseño y la normalización de la base de datos (hay varios hilos excelentes en este sitio).
https://.com/questions/tagged/normalization
Por lo que has descrito, ciertamente dividiría eso en múltiples tablas. Sin embargo, no me dividiría en un número arbitrario de columnas, sino que trataré de pensar en colecciones lógicas de columnas que constituyan una entidad o que coincidan con los patrones de acceso que utilizará para acceder a los datos.
Yo recomendaría algunas tablas. Sobre la normalización es difícil de administrar y terminaría escribiendo consultas complejas que terminan con un rendimiento lento.
Normalice solo cuando sea absolutamente necesario y piense en términos lógicos. Con la información limitada que proporcionó anteriormente, iría por tres tablas:
Tabla 1: Detalles personales Tabla 2: Actividades Tabla 3: Varios
Existen otras técnicas para acelerar el rendimiento, como la agrupación, etc., que puede usar según sus necesidades.
muchas tablas pequeñas, es decir, la normalización es la mejor aquí. proporciona flexibilidad, reduce la redundancia y una mejor organización de la base de datos.