Clave sustituta como clave externa sobre claves compuestas

Question

Me doy cuenta de que puede haber preguntas similares, pero no pude encontrar una que estuviera lo suficientemente cerca como guía.

Dada esta especificación,

Site
---------------------------
SiteID      int    identity
Name        varchar(50)

Series
---------------------
SiteID      int
SeriesCode  varchar(6)
...
--SeriesCode will be unique for every unique SiteID

Episode
----------------------
SiteID      int
SeriesCode  varchar(6)
EpisodeCode varchar(10)
...

mi diseño / implementación propuesto es

Site
----------------------------
SiteID      int     identity
Name        varchar(50)


Series
-------------------------------------------
SeriesID    int     identity, surrogate key
SiteID      int         natural key
SeriesCode  varchar(6)  natural key
UNIQUE(SiteID, SeriesCode)
...

Episode
-------------------------------------------
EpisodeID   int     identity, surrogate key
SeriesID    int     foreign key
EpisodeCode varchar(6)  natural key
...

¿Hay algo malo con esto? ¿Está bien tener el sustituto de ID de serie como una clave externa * aquí? No estoy seguro si me estoy perdiendo algún problema obvio que pueda surgir. ¿O sería mejor usar claves compuestas naturales (SiteID + SeriesCode / SiteID + EpisodeCode)? En esencia, eso desacoplaría la tabla Episodio de la tabla Serie y eso no me sienta bien.

Vale la pena agregar que SeriesCode se ve como 'ABCD-1' y EpisodeCode como 'ABCD-1NMO9' en los datos de entrada sin procesar que llenarán estas tablas, así que supongo que eso podría cambiarse.

*: " virtual " clave externa, dado que los superiores lo decidieron anteriormente, no deberíamos usar reales claves externas

Answer 1

Sí, todo se ve bien. El único punto (menor) que podría señalar es que, a menos que tenga otra cuarta tabla secundaria colgando de Episode, probablemente no necesite EpisodeId, ya que Episode.EpisodeCode es una clave natural de atributo único suficiente para identificar y ubicar filas en Episode. No es perjudicial dejarlo allí, por supuesto, pero como regla general agrego claves sustitutas para que actúen como objetivos para los FK en las tablas secundarias, e intento agregar una clave narrativa a cada tabla para identificar y controlar filas de datos redundantes ... Entonces, si una tabla no tiene otra tabla con un FK que haga referencia a ella (y nunca la tendré), a veces no me molesto en incluir una clave sustituta.

Answer 2

¿Qué es un " virtual " ¿clave externa? ¿Los superiores decidieron no usar restricciones de clave externa? En ese caso, no está utilizando claves foráneas en absoluto. Solo finges hacerlo.

¿Y es Episode la mejor opción para una entidad? ¿No significa realmente Show o Podcast o algo así, y simplemente siempre forma parte de una serie en este momento? Si es así, ¿cambiará eso en el futuro? ¿Eventualmente se abusará de Episode para abarcar Show fuera de una serie? En ese caso, vincular Episodio al Sitio a través de la Serie podría volverse para atormentarte.

Dado todo eso, y suponiendo que usted como gruñido probablemente no pueda cambiar nada de eso: si fuera usted, me sentiría más seguro usando teclas naturales siempre que sea posible. En ausencia de restricciones de clave externa, facilita el reconocimiento de datos incorrectos, y si tiene que recurrir a algún truco SeriesCode = 'EMPTY' más adelante, eso también es más fácil con las claves naturales.

Answer 3

Mi sugerencia:

Use natural / business como clave principal siempre que sea posible excepto en las siguientes 3 situaciones:

1. La clave natural / comercial es desconocida en el momento de la inserción
2. La clave natural / empresarial es no buena (no es única, es probable que cambie con frecuencia)
3. La clave natural / empresarial está compuesta de más de 3 columnas y la tabla tendrá tablas secundarias

En las situaciones 1 y 2, se requiere una clave sustituta .

En la situación 3, se recomienda encarecidamente una clave sustituta .