Sanity Check: ¿Flota como clave principal?

Question

Estoy trabajando con una antigua base de datos sql server 2000, mezclando parte de su información con una nueva aplicación que estoy construyendo. Noté que algunas de las claves principales en varias de las tablas son flotantes en lugar de cualquier tipo de entradas. No son claves foráneas y son únicas. No puedo pensar en ninguna razón por la que alguien quiera hacer flotantes sus identificadores de clave primaria únicos, pero de ningún modo soy un experto en SQL. Así que supongo que lo que estoy preguntando es si quien diseñó esta base de datos bastante extensa sabe algo que yo no?

Answer 1

Actualmente estoy trabajando con un paquete de contadores bastante grande donde CADA una de 350+ tablas tiene una clave principal de FLOAT (53). Todos los valores reales son enteros y el sistema comprueba estrictamente que sí lo son (hay funciones especiales que hacen todo el trabajo de incremento).

Me sorprendió este diseño, pero puedo entender por qué fue elegido y darle algunos créditos. Por un lado, el sistema es lo suficientemente grande como para tener mil millones de registros en algunas tablas. Por otro lado, esas claves primarias deben ser fácilmente legibles desde aplicaciones externas como Excel o VB6, en cuyo caso realmente no desea convertirlas en BIGINT.

Por lo tanto, el flotador está bien.

Answer 2

¿Es un formato NUMÉRICO (x, y) y una IDENTIDAD? Si es así, podría ser una actualización de una versión anterior de SQL Server. La IDENTIDAD de vuelta en el día solo podría ser un formato NUMÉRICO, no el INT común que usamos hoy.

De lo contrario, no hay forma de saber si un flotador es adecuado como clave principal, depende de su dominio. Es un poco más difícil de comparar (IEEE INT es más eficiente que float) y la mayoría de la gente usa cantidades monótonamente crecientes (IDENTIDAD), por lo que los enteros son a menudo lo que la gente realmente quiere.

ya que parece que usted está almacenando enteros:

Para responder a la pregunta original de manera más directa: Si usted está almacenando enteros, utilice el tipo de datos entero. Es más eficiente almacenar y comparar.

Answer 3

Los flotadores tienen una propiedad interesante: siempre es posible insertar un valor entre otros dos, excepto en el caso patológico donde se agoten los bits. Tiene la desventaja de que los problemas de representación pueden impedirle hacer referencia a una fila por la clave; es difícil hacer que dos valores de punto flotante sean iguales entre sí.

Answer 4

Trabajé con alguien que usa carrozas como PK en bases de datos de SQL Server. Estaba preocupado por quedarse sin números para los identificadores si se quedaba con las INT. (32 bit en SQL Server.) Simplemente miró el rango de flotación y no pensó en el hecho, no importa que para números más grandes, el lugar de las unidades no se mantenga en el número, debido a la precisión limitada. Entonces su código para tomar MAX (PK) + 1.0 devolvería en algún momento un número igual a MAX (PK). No está bien. Finalmente lo convencí de que no usara float para claves primarias sustitutas para futuras bases de datos. Se retiró antes de arreglar el DB en el que estaba trabajando.

Para responder a su pregunta, "Entonces, supongo que lo que estoy preguntando es si quien diseñó esta base de datos bastante extensa sabe algo que yo no sé". Lo más probable es ¡NO! Al menos no con respecto a la elección de tipos de datos.

Answer 5

He estado trabajando con la base de datos Cerner Millenium durante algunos años (bajo las cubiertas usa Oracle). Inicialmente, me sorprendió mucho ver que usaba flotadores para ID en las tablas. Luego encontré una ID en nuestra base de datos> 2^32 y una consulta que escribí dio los resultados incorrectos porque la había lanzado incorrectamente a una INT. Me di cuenta por qué lo hicieron.No encuentro ninguno de los argumentos anteriores contra el uso de flotadores persuasivos en el mundo real, donde para las claves solo necesitas números "algo mayores" que 2^32 y el valor de la identificación es siempre de la forma #### ##. 0. (Nadie está hablando de una identificación del formulario ######. ######.) Sin embargo, ahora que estamos importando estos datos en un almacén de SQL Server, y bigint está disponible, vamos a ir con bigint en lugar de flotar.

Answer 6

FYI-- hay otra manera de ver esto:

Yo trabajo en el control de procesos en tiempo real y, como tal, la mayoría de mis entradas de fila están basados ​​en el tiempo y se generan automáticamente a altas tasas de no -Máquinas de ASCII. el tiempo, es por eso que mis usuarios suelen buscar y muchos de mis "usuarios" son en realidad máquinas. Por lo tanto, claves primarias basadas en UTC.