DISEÑO DE BASE DE DATOS - La clave principal para COUNTRY, int moneda o varchar

Question

• Por mi tabla de país, que utiliza el código país como la clave principal "AU, Estados Unidos, Reino Unido, Francia", etc

• Para mi tabla de monedas, que utiliza el código de moneda como la clave principal "AUD, GBP, USD", etc

Creo que lo que hice está bien, pero otro desarrollador quiere que cambie todas las claves principales para un int , porque el código de país, el código de moneda podría cambiar alguna vez en el en verdad dijo él. Simplemente no lo sabemos, bueno, en este caso, él tiene razón, su camino es el más seguro para tomar.

¿Debo cambiar las claves principales a un int para estar seguro en lugar de lamentarlo? ¿No puedo quedarme?

Answer 1

Utilizaría los códigos ISO con columnas char.

Si un país alguna vez se divide, obtendría nuevos códigos ISO (por ejemplo, SC, WL, EN) pero UK seguiría siendo válido para datos históricos.

Pasa lo mismo con la moneda. Una transacción en 2000 sería en la moneda en ese momento: francos franceses, marcos alemanes, Bélgica Plátano pero no euros.

Answer 2

Sí, cambiar a una clave entera sería una buena idea antes de que sea demasiado tarde.

E.g. ¿Qué pasa si Gran Bretaña se une a la zona euro?

Answer 3

Yo diría que el "nacimiento de una nación" o la desaparición de una moneda es, sobre todo, una ocurrencia bastante rara, que no es probable que suceda varias veces al año, todos los años.

Por lo tanto, a este respecto, creo que debería ser correcto utilizar los códigos de país y moneda definidos por ISO para su clave principal.

Sí, si algo le sucede a la zona euro, o si otro país se divide en dos, es posible que tenga que hacer algunas tareas de limpieza manual, pero también tendría que hacer esto con INT. En un caso como este, yo diría que una clave sustituta artificial (como la INT) realmente solo agrega sobrecarga y realmente no ayuda a mantener las cosas más fáciles/más explícitas.

Desde esos códigos son realmente corto, y por lo general la misma longitud, yo sin embargo recomendamos el uso de un CHAR(3) o CHAR(5) - sin sentido en el uso VARCHAR para una cadena tan poco tiempo, y también, VARCHAR como campos de longitud variable se comportan bastante de manera diferente (y no "mejor" en términos de rendimiento) que campos de longitud fija como INT o CHAR

Answer 4

Siempre y cuando las claves foráneas que hacen referencia a estas claves principales se declaren con ON UPDATE CASCADE, ¿quién se preocupa si estos códigos cambian?

Hay una ventaja adicional al consultar cualquiera de las tablas de referencia: si todo lo que necesita es el código de país/moneda, no es necesario unirse a estas tablas, ya tiene el código incluido en estas tablas.

---

Y si usted decide pasar a una madre sustituta INT, se recomienda colocar una restricción única en estas columnas todavía - que son una verdadera clave para estas tablas.

Answer 5

No es una práctica práctica usar algo como clave principal que cambie. Supongamos que el valor ha cambiado y luego debe actualizar todos los registros secundarios. Si lo hace, podría bloquear su base de datos durante horas o incluso días. Esta es la razón por la que el entero FK con el índice único en la clave natural es una mejor práctica para la información que es volátil.

Answer 6

Desde un punto de vista lógico, agregar un sustituto significa columnas adicionales, restricciones de clave adicionales y una lógica más compleja para consultar y manipular los datos. Eso es una cosa a considerar.

Desde un punto de vista físico, en SQL Server una tecla INTEGER ocupará más del doble de espacio que un CHAR (2) o CHAR (3). Eso significa que sus tablas e índices de referencia se hacen más grandes. También hace que cualquier actualización de esos valores de clave foránea sea mucho más costosa. No conozco sus datos, pero parece bastante posible que los datos de referencia en esas columnas de clave externa se puedan actualizar con mucha más frecuencia que los valores de código de país y código de moneda en la tabla padre. Por el contrario, los códigos ISO para la moneda y el país casi nunca cambian, por lo que probablemente sea muy poco de lo que preocuparse. Al cambiar a las teclas INTEGER puede aumentar el costo de actualizar esos valores de clave foránea.

Si está considerando un cambio como la optimización del rendimiento, le sugiero que evalúe con mucho cuidado si las teclas INTEGER harán que las actualizaciones de esos valores sean más costosas o menos costosas. Sugiero que ignores a las personas que dicen "siempre haz X". Dogma no es de ayuda en el diseño de la base de datos. Evalúe cuál será el impacto real en la práctica y tome su decisión en consecuencia.

Answer 7

Creo que su sistema se volverá obsoleto diez veces antes que el estándar ISO sobre el código de país y moneda.

Así que realmente no veo ningún beneficio para usar 01010101 01010011 o 21843 en lugar de "EE. UU.".

Answer 8

me gustaría utilizar los identificadores de INT como clave en lugar de los códigos ISO y que explique por qué:

Organización que trabajaba, utiliza "propia moneda" (LBP) - por ejemplo, cuando un usuario realiza alguna transacción, recibe una cierta cantidad de LBP como una bonificación. Además, puede cambiar esos LBP a USD, EUR, etc. y viceversa, pagar los servicios con LBP, etc. Además, no encontré la moneda BTC (Bitcoin) en el estándar ISO.

Sí, estas no son monedas oficiales, pero es más flexible desde el punto de vista del sistema y de los usuarios para tenerlas como monedas pero no como un producto adicional que el usuario puede comprar y vender.

Organización que trabajé para no utilizar INTS como clave principal, usan códigos ISO como identificadores (más esas monedas adicionales).

Oficialmente, LBP es el estándar ISO para libra libanesa, por lo que no podrán agregar libra libanesa al sistema sin problemas.

Si identifica sus monedas por código, y en el futuro alguna moneda nueva se registrará como estándar ISO (por ejemplo, LBE o BTC), estas monedas entrarán en conflicto con "sus" monedas.

Alguien mencionó aquí que tener una clave int adicional para las monedas es un índice adicional. Pero perdón, ¿es un problema para 300 registros (recuento aproximado de monedas)?Además, si usa INTs como clave principal para monedas, tiene un beneficio adicional: imagine una tabla con transacciones de 1M que contiene montos y monedas, y que es más eficiente: ¿INTS o CHARS?

Así que me gustaría INTs.