如何解决MS SQL中不受支持的无符号整数字段类型？ [英] How to work around unsupported unsigned integer field types in MS SQL?

问题描述

试图使基于MySQL的应用程序支持MS SQL，我遇到了以下问题：

Trying to make a MySQL-based application support MS SQL, I ran into the following issue:

我将MySQL的auto_increment保留为无符号整数字段（各种大小）为了充分利用范围，我知道永远不会出现负值。 MS SQL并非在所有整数类型上都支持unsigned属性，因此我必须在放弃一半的值范围或创建一些解决方法之间进行选择。

I keep MySQL's auto_increment as unsigned integer fields (of various sizes) in order to make use of the full range, as I know there will never be negative values. MS SQL does not support the unsigned attribute on all integer types, so I have to choose between ditching half the value range or creating some workaround.

一种非常幼稚的方法是将一些代码放入数据库抽象代码或存储过程中，以在db侧的负值与无符号范围较大部分的值之间进行转换。当然，这会弄乱排序，也不能使用自动ID功能（或以某种方式？）。

One very naive approach would be to put some code in the database abstraction code or in a stored procedure that converts between negative values on the db side and values from the larger portion of the unsigned range. This would mess up sorting of course, and also it would not work with the auto-id feature (or would it some way?).

我想不起来一种 good 解决方法，现在有吗？还是我只是发狂，应该忘掉一半范围？

I can't think of a good workaround right now, is there any? Or am I just being fanatic and should simply forget about half the range?

编辑：

@Mike Woodhouse：是的，我想你是对的。我的脑海里仍然有声音说，如果我优化该领域的利用，也许可以缩小该领域的规模。但是，如果没有简便的方法可以这样做，那就不用担心了。

推荐答案

问题可能会成为一个真正的问题？

When is the problem likely to become a real issue?

鉴于当前的增长率，您预计多久后才能在MS SQL版本中发生有符号整数溢出？

Given current growth rates, how soon do you expect signed integer overflow to happen in the MS SQL version?

要悲观。

您希望应用程序生存多长时间？

How long do you expect the application to live?

您是否仍然认为2差的因素是您应该担心的事情？

Do you still think the factor of 2 difference is something you should worry about?

（我不知道答案是什么，但我认为我们应该确定在寻找更难的解决方案之前我们确实有问题）

(I have no idea what the answers are, but I think we should be sure that we really have a problem before searching any harder for a solution)

这篇关于如何解决MS SQL中不受支持的无符号整数字段类型？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！