Je travaille avec une ancienne base de données SQL Server 2000, en mélangeant certaines des informations avec une nouvelle application que je consomme. J'ai remarqué que certaines des clés principales de plusieurs tables sont des flotteurs plutôt que de tout type d'INT. Ils ne sont pas des clés étrangères et sont toutes uniques. Je ne peux penser à aucune raison que quiconque voudrait faire des flotteurs de clé primaire uniques, mais je ne suis pas un expert SQL par aucun moyen. Donc, je suppose que ce que je demande, c'est que quiconque a conçu cette base de données assez étendue savoir quelque chose que je ne fais pas?
6 Réponses :
est-ce un format numérique (x, y) et une identité? Si tel est le cas, cela pourrait être une mise à niveau d'une ancienne version de SQL Server. L'identité de retour dans l'ensemble du jour ne pourrait être qu'un format numérique, pas le commun Int que nous utilisons aujourd'hui.
Sinon, il n'ya aucun moyen de dire si un flotteur convient comme clé primaire - cela dépend de votre domaine. C'est un peu plus difficile à comparer (IEEE INT est plus efficace que le flotteur) et la plupart des gens utilisent des nombres monotoniquement croissants (identité), donc les entiers sont souvent ce que les gens veulent vraiment.
Comme on dirait que vous stockez des intentes:
Pour répondre à la question initiale plus directement: Si vous stockez des Ints, utilisez le type de données entier. Il est plus efficace de stocker et de comparer.
En fait, les PKS auraient toujours pu être des INT, mais depuis que les Bigints n'existaient pas, les gens ont utilisé des numériques
Ah ok. Je sais que Sybase SQL Server - il y a toujours - uniquement des numériques soutenus et je pensais que SQL Server's Server a hérité de cette restriction.
Je crois qu'ils ont utilisé SQL Server 2000 depuis le début, bien que je ne suis pas sûr à 100%. Je vais vérifier cependant.
Coinkily MySQL était techniquement plus rapide à la comparaison des flotteurs que les INT (ce qui n'est plus le cas, je m'empresse d'ajouter) de sorte que certains fans d'optimisation prématurée sont probablement responsables. Nous avons une production de production comme celle-ci ici, et cela m'a amené à chercher quand je suis tombé sur une table avec flotteur en tant que PK.
Les floats ont une propriété intéressante: il est toujours possible d'insérer une valeur entre deux autres, à l'exception du cas pathologique où vous manquez de bits. Il présente l'inconvénient que des problèmes de représentation peuvent vous empêcher de faire référence à une ligne par la clé; Il est difficile de faire deux valeurs de points flottants égales les unes aux autres.
En principe, si vous voulez ces propriétés, je pense que vous pouvez toujours ajouter une colonne indexée contenant le flotteur, en plus de la clé primaire INT.
C'était ma première pensée, mais je ne peux trouver aucun comme ça, ils sont tous séquentiels 3.0, 4.0, 5.0, etc. C'était peut-être une sorte d'épreuve future, même si je ne suis pas tout à fait sûr, pourquoi, car ils semblent simplement être des identifiants. Merci pour votre contribution.
Il ne semble pas que ceci est la bonne réponse pour le cas spécifique du questionneur ... Mais vous êtes éliminé de toute façon pour avoir une réponse intéressante et éventuelle pour la prochaine personne de rechercher cette question.
J'ai travaillé avec quelqu'un qui a utilisé des flotteurs en tant que PKS dans les bases de données SQL Server. Il était inquiet de manquer de chiffres pour des identifiants s'il était coincé sur INTS. (32 bits sur SQL Server.) Il vient de regarder la gamme de float et n'a pas pensé à ce que cela ne soit rien à dire que pour des chiffres plus importants que la place n'est pas détenue dans le nombre, en raison de la précision limitée. Donc, son code pour prendre max (PK) + 1,0 serait à un moment donné, retourner un chiffre égal à max (pk). Pas bon. Je l'ai enfin convaincu de ne pas utiliser de flotteur pour les clés principales de substitution pour les futures bases de données. Il a quitté avant de fixer la DB qu'il travaillait.
Pour répondre à votre question, "Je suppose donc que ce que je demande, c'est que quiconque a conçu cette base de données assez étendue savoir quelque chose que je ne le fais pas?" Très probablement
Le numéro où vous commencez à courir dans le problème pk + 1.0 = pk est 9007199254740992. À 1000000 Nouveau PK par seconde, il vous faudra 285 ans pour rencontrer ce numéro. Je ne pense pas que ce soit un point mérite d'être inquiétant. D'autre part, à seulement 100 par seconde, vous pouvez manquer de pièce dans une INT signée en moins d'un an.
Je travaille actuellement avec un forfait comptable assez important où chacune des 350 tables a une clé primaire de Float (53). Toutes les valeurs réelles sont des entiers et le système vérifie strictement qu'ils sont effectivement (il existe des fonctions spéciales qui font tous les travaux d'incrémentation).
Je me suis demandé à cette conception, mais je peux comprendre pourquoi il a été choisi et lui donner des crédits. D'une part, le système est assez grand pour avoir un milliard d'enregistrements dans certaines tables. D'autre part, ces touches principales doivent être facilement lisibles à partir d'applications externes telles que Excel ou VB6, auquel cas vous ne voulez pas vraiment les faire de Bigint.
Par conséquent, le flotteur est bien.
C'est intéressant, pouvez-vous expliquer ce que vous entendez par facilement lisible? Voulez-vous dire plus facile pour les applications externes de les lire ou lisibles à l'homme? Merci pour la réponse.
Non, je veux dire que ces systèmes avec lesquels les gens écrivent leurs propres applications d'assistance autour de la grande chose, peuvent facilement être capables de faire face aux entiers de 64 bits. Il n'y a pas de type de données dans VB6 de Nativement SUPPOR A Bigint, vous auriez à jouer avec le double (comme Excel suggère automatiquement) ou une variante-décimale (comme le fait ADO). Et c'est au moins quelque chose! Je peux facilement imaginer un système externe qui ne sera pas capable de consommer des grossications du tout.
J'ai travaillé avec la base de données CERNER MILLENIUM pendant quelques années (sous les couvertures qu'il utilise Oracle). Au départ, j'ai été très surpris de voir qu'il utilisait des flotteurs pour les identifiants sur des tables. Ensuite, j'ai rencontré un identifiant dans notre base de données> 2 ^ 32 Et une requête que j'ai écrite a donné les mauvais résultats parce que je l'avais mal apporté à un INT, j'ai compris pourquoi ils l'ont fait. Je ne trouve aucun des arguments ci-dessus contre l'utilisation de floats persuasif dans le monde réel, où, pour les clés, il suffit de nécessiter des chiffres que "un peu plus grand" que 2 ^ 32 et la valeur de l'identifiant est toujours de la forme #### ## 0. (Personne ne parle d'un identifiant de la forme ######. ###### avec Bigint au lieu de flotter.
FYI-- Il y a une autre façon de regarder ceci:
Je travaille dans le contrôle de processus en temps réel et en tant que tel, la plupart de mes entrées de ligne sont basées sur le temps et sont générées automatiquement à des tarifs élevés par des machines non-ASCII. Time - c'est ce que mes utilisateurs recherchent généralement et beaucoup de mes «utilisateurs» sont en réalité des machines elles-mêmes. Par conséquent, les clés primaires basées sur l'UTC.
Je crois que votre instinct est 100% correct ici; Les flotteurs font de mauvaises touches.