T-SQL Database Relationships PK FK ¿El mismo nombre?

Question

Escenario

Tengo 3 tablas de base de datos. Uno es para imágenes y los otros dos son personas & amp; Lugares Ya que cada persona puede tener muchas imágenes y cada lugar puede tener muchas imágenes, quiero tener una relación de UNO A MUCHOS entre personas e imágenes, así como lugares e imágenes.

Pregunta

¿La clave externa debe llamarse con el mismo nombre que la clave principal? ¿O es posible para mí llamar a la clave externa en la tabla de imágenes algo genérico, por ejemplo " PKTableID " ;. De esta manera solo necesito una tabla de imágenes.

Ayuda muy apreciada.

Saludos,

EDITAR:

La razón para querer tener una sola tabla de imágenes, es porque cada imagen solo se refiere a otra tabla. Además de esto, utilicé el ejemplo aquí de dos tablas, la base de datos que usaré tendrá 20 tablas, así que quería saber si todavía era posible usar una MESA DE IMAGEN INDIVIDUAL PARA 20 RELACIONES ÚNICAS ?

Answer 1

EDIT

Si una imagen solo es propiedad de una de las veinte tablas, este diseño podría funcionar:

People (PersonId, Name)
Places (PlaceId, Name)
Dogs (DogId, Breed)
Doors (DoorId, Height, Width)
Images (ImageId, ImageBinary, OwnerId, OwnerTable)

Donde OwnerTable es el nombre o el código de la tabla a la que pertenece OwnerId.

Esto le ahorraría 20 FK en la tabla de imágenes, o 20 tablas de asociación. Luego, en las combinaciones, debe especificar OwnerTable, dependiendo de la tabla a la que se está uniendo.

Necesitaría usar tipos convertibles para los identificadores (por ejemplo, TINYINT, SMALLINT e INT), y preferiblemente un tipo para todos (por ejemplo, INT), y tendría que administrar la integridad referencial a través de activadores u otros. código.

/ EDIT

Necesitas 5 tablas, no 3:

People (PersonId, Name)
Places (PlaceId, Name)
Images (ImageId, ImageBinary)
ImagesPeople (ImageId, PersonId)
ImagesPlaces (ImageId, PlaceId)

Puedes llamar a los campos como quieras. People.Id, ImagesPeople.PersonId, etc.

Pero lo que no puedes hacer es algo como esto:

People (PersonId, Name)
Places (PlaceId, Name)
Images (ImageId, ImageBinary, PlaceOrPersonId)

Bueno, puedes, pero la base de datos no te ayudará a imponer la relación ni a decirte a qué tabla pertenece el FK. ¿Cómo sabrías? Hay trucos curiosos, como escalonar los incrementos de ID, agregar una columna de tipo a las imágenes o usar GUID.

Alternativamente:

Things (ThingId PK, Type)
People (ThingId PK/FK, Name, Age)
Places (ThingId PK/FK, Name, LatLon)
Images (ImageId PK, ImageBinary, ThingId FK)

También puedes hacer que las Imágenes sean " Cosa " ;. A veces ves diseños como este. Le da integridad referencial, pero no la exclusividad de tipo. Podría tener el mismo ThingId en Personas, Lugares e Imágenes, y la base de datos no le importaría. Tendrías que codificar esa regla tú mismo.

Edición: a sugerencia de Cylon Cat, escenario 4:

People (PersonId, Name)
Places (PlaceId, Name)
PeopleImages (PeopleImageId, ImageBinary)
PlaceImages (PlaceImageId, ImageBinary)

Aquí, las imágenes son propiedad exclusiva de una persona o lugar. Similar a la versión 2, pero con claves foráneas declaradas. Puede tener algunos beneficios de rendimiento en comparación con el diseño de la tabla 5, ya que se requieren menos combinaciones. Pierdes " Imagen " como una entidad distinta, reemplazada por " PeopleImage " y " PlaceImage " ;.

Answer 2

Como Peter señaló, realmente necesita una relación de muchos a muchos, a menos que desee restringir sus imágenes a imágenes con una sola persona, además, un buen índice de lugares reflejará la naturaleza jerárquica de los nombres de lugares (Montmartre, París, Francia = tres nombres posibles para un lugar).

Ahora, técnicamente, puede llamar a sus índices y tablas cualquier cosa que no sea una palabra reservada y que aún no se haya utilizado, X, Y, Z12345 y WOBBLY son todos nombres válidos para un índice.

Sin embargo, en la práctica es mejor seguir una convención de nomenclatura que apunte a qué se está almacenando y para qué. Por lo tanto, las tablas PEOPLE_X_IMAGES y PLACES_X_IMAGES serían una buena idea en su caso. Realmente no necesitas nada sobre personas o lugares en la tabla de imágenes reales. Del mismo modo, no necesita nada sobre las imágenes en las tablas de PERSONAS y LUGARES.

Answer 3

Puedes agregar teóricamente dos claves externas a la tabla de imágenes, una para Personas y una para Lugares. A continuación, puede permitir nulos y unirse a las columnas adecuadas al ejecutar una consulta. Sin embargo, esto no es una gran solución porque, ¿cómo se ve esta tabla cuando tienes 14 tablas que necesitan unirse?

Si no vas a usar GUID, entonces te digo que lo configures de muchos a muchos por el bien del siguiente tipo que tiene que entenderlo.

Answer 4

Puedes usar una tabla pero necesitarías veinte campos diferentes para las relaciones. Si configura una relación de clave externa, entonces todos los datos deben estar relacionados con la tabla principal, no puede almacenar dos relaciones de clave externa en una tabla. Así que debes configurar una columna para cada fk que quieras tener.

Answer 5

¿Qué tal

Person (PersonId PK, Name, ImageId FK)
Image (ImageId PK, Name)
Place (PlaceId PK, Name, ImageId FK)