Diseño de tabla para SQL

Question

espero que me pueda ayudar aquí; tengo una pregunta sobre el diseño de una tabla SQL. Sé cómo escribir en una base de datos y realizar consultas usando C#, pero nunca tuve que diseñar una. Así que pensé que le daría una oportunidad a nuestro interés.

Supongamos que tengo una tabla llamada family_surname. Dentro de esa tabla, podría haber x cantidad de miembros de la familia, por ejemplo, de 2 a 22 personas. ¿Cómo puedo hacer referencia a family_members contra family_surname?

por lo que tendría apellido de la familia Smith, Jones, Brown, Taylor, etc.

Y entonces Smith puede tener 5 miembros, a donde me gustaría grabar edad, altura, peso , lo que sea. Jones puede tener 8 miembros, podría variar de una familia a otra.

No quiero realmente 'apellido' enumerado 8 veces para cada miembro - idealmente la fila de apellido haría referencia (o de alguna manera señalaría) una fila correspondiente en otra tabla. ¡Y ahí es donde estoy teniendo problemas!

Espero que tenga sentido; como digo, estoy interesado, pero me gustaría saber cómo hacer esto con dos tablas.

De todos modos, gracias por su ayuda, lo agradezco.

EDIT Gracias a todos los que han comentado, sin duda, algunos datos útiles que agradezco. Estoy leyendo e investigando algunos bits y fragmentos SQL, y hasta ahora es bastante bueno. ¡Gracias de nuevo, muchachos!

Answer 1

Lo que está preguntando es una pregunta acerca de la normalización. La tabla se vería así:

Create table surname (
    SurnameID int, 
    Surname varchar(255) 
) 

Las otras tablas harían referencia al apellido utilizando el I'd. Además, es probable que desee que el sobrenombre sea único, una clave principal y aumente automáticamente. Esos son temas más avanzados.

Dicho esto, no estoy seguro de que el apellido sea un gran candidato para dividirse así. Una razón para normalizar los datos es mantener la integridad relacional. En este caso, significa que cuando cambia "Smith" a "Jones", todos los Smith cambian a la vez. No creo que esto sea una preocupación en tu caso.

Answer 2

Si la respuesta anterior sobre el aprendizaje sobre la normalización de bases de datos es probablemente exacta pero para empezar ....

Romper el nombre de la persona (nombre y apellido) es probablemente un poco mucho. A menos que suponga que todos los que se llaman "jones" están TODOS relacionados. Piense en cada tabla como una entidad/objeto y trate de conectarlos a los "objetos" del mundo real tanto como sea posible. Dado que una persona necesita tanto el nombre como el apellido (mínimo) para identificarlos de manera única, no se deben normalizar de esa manera.

En el escenario que ha pintado, debe tener una tabla Persons que tenga PersonId, FirstName, LastName. Y si es necesario, una tabla separada para almacenar otra información. Sin embargo, dado que la persona solo puede tener una altura, peso, edad, etc., estos deben almacenarse en la tabla Personas.

Por lo tanto, realmente solo necesita una tabla aquí. A menos que comiences a ingresar números de teléfono, direcciones, etc.

Answer 3

La descomposición se puede realizar de la siguiente

1. CREATE APELLIDOS TABLA (INT de identificación, APELLIDOS VARCHAR2 (200))
2. CREATE detalles de la tabla (INT ID, FOREIGN KEY (SURNAME_ID) Referencias APELLIDOS (ID) , PARAM1, PARAM2 .....)

Un esbozo de la descomposición es

obtener la lista de atributos (APELLIDOS, PARAM1, PARAM2, ....). Sobre la base de la lista de atributos las siguientes teclas se pueden deducir: 1. (apellido) 2. (PARAM1, PARAM2 ...) Se crea una tabla separada para cada juego de llaves

Answer 4

I Dont realmente quiere 'apellido' enumerado 8 veces para cada miembro

¿Por qué? ¿Ha evaluado en cantidades realistas de datos y ha determinado que en realidad es un problema?

A menos planea tener datos adicionales específicos para el apellido (e independientes de las personas que tienen ese apellido), no hay nada malo sobre el apellido no estar en su propia tabla. No estás rompiendo ninguna forma normal.

De hecho, lo que se propone puede ser una muy mala idea, por las razones siguientes:

• En primer lugar, se necesitaría un JOIN sólo para averiguar el apellido de la persona - malo para el rendimiento.
• Esto complica (y ralentiza) la inserción/modificación/eliminación de personas.
  • Al insertar una nueva persona, debe buscar en la tabla de apellidos para decidir si puede "reutilizar" la existente o insertar la nueva.
  • La modificación (por ejemplo, cuando una esposa toma el apellido del marido) es una combinación de eliminación (ver a continuación) e inserción.
  • ¿Puede existir un apellido sin que ninguna persona lo tenga? Si no, no hay una buena integridad declarativa para hacer cumplir esto. En el mejor de los casos, necesitarías escribir algunos factores desencadenantes.
• Puede que no termine ahorrando mucho espacio después de todo - la tabla adicional tendrá sus propios gastos generales de almacenamiento (como el índice "debajo" de la clave principal) que pueden "comer" gran parte del almacenamiento anticipado .