Comment contourner les types de champs entiers non signés non pris en charge dans MS SQL ?

Question

En essayant de faire en sorte qu'une application basée sur MySQL prenne en charge MS SQL, j'ai rencontré le problème suivant :

Je conserve l'auto_increment de MySQL sous forme de champs entiers non signés (de différentes tailles) afin d'utiliser toute la gamme, car je sais qu'il n'y aura jamais de valeurs négatives.MS SQL ne prend pas en charge l'attribut non signé sur tous les types entiers, je dois donc choisir entre abandonner la moitié de la plage de valeurs ou créer une solution de contournement.

Une approche très naïve consisterait à mettre du code dans le code d'abstraction de la base de données ou dans une procédure stockée qui convertit entre les valeurs négatives du côté base de données et les valeurs de la plus grande partie de la plage non signée.Cela gâcherait bien sûr le tri, et cela ne fonctionnerait pas non plus avec la fonction d'identification automatique (ou le serait-il d'une manière ou d'une autre ?).

Je ne peux pas penser à un bien solution de contournement pour le moment, y en a-t-il ?Ou suis-je simplement un fanatique et devrais-je simplement oublier la moitié de la gamme ?

Modifier:
@Mike Woodhouse :Ouais, je suppose que tu as raison.Il y a encore une voix dans ma tête qui me dit que je pourrais peut-être réduire la taille du champ si j'optimisais son utilisation.Mais s’il n’existe pas de moyen simple d’y parvenir, cela ne vaut probablement pas la peine de s’en inquiéter.

Answer 1

Quand le problème est-il susceptible de devenir un véritable problème ?

Compte tenu des taux de croissance actuels, dans combien de temps pensez-vous qu'un débordement d'entier signé se produira dans la version MS SQL ?

Soyez pessimiste.

Combien de temps pensez-vous que l’application durera ?

Pensez-vous toujours que la différence du facteur 2 est quelque chose dont vous devriez vous soucier ?

(Je n'ai aucune idée des réponses, mais je pense que nous devrions être sûrs que nous avons vraiment un problème avant de chercher plus dur une solution)

Answer 2

Je recommanderais d'utiliser le type de données BIGINT car cela va jusqu'à 9 223 372 036 854 775 807.

SQL Server ne prend pas en charge les valeurs signées et non signées.

Answer 3

Je dirais ceci..« Comment gérons-nous normalement les différences entre les composants ? »

Encapsuler ce qui varie..

Vous devez créer une couche d'abstraction au sein de votre couche d'accès aux données pour l'amener au point où elle s'en fiche que la base de données soit MySQL ou MS SQL.