1

MySQL ベースのアプリケーションで MS SQL をサポートしようとしたところ、次の問題に遭遇しました。

負の値が存在しないことがわかっているため、全範囲を利用するために、MySQL の auto_increment を (さまざまなサイズの) 符号なし整数フィールドとして保持します。MS SQL は、すべての整数型で unsigned 属性をサポートしているわけではないため、値の範囲の半分を捨てるか、回避策を作成するかを選択する必要があります。

非常に単純なアプローチの 1 つは、データベースの抽象化コードまたはストアド プロシージャにコードを配置して、db 側の負の値と符号なし範囲のより大きな部分の値を変換することです。もちろん、これは並べ替えを混乱させます。また、auto-id 機能では機能しません (または何らかの方法で機能しますか?)。

今のところ良い回避策が思い浮かびませんが、何かありますか? それとも、私はただ狂信的で、範囲の約半分を忘れるべきですか?

編集：
@Mike Woodhouse：ええ、あなたは正しいと思います。頭の中で、フィールドの使用率を最適化すれば、フィールドのサイズを縮小できるのではないかという声がまだ残っています。しかし、これを行う簡単な方法がない場合は、おそらく心配する価値はありません。

4

3 に答える 3

1

問題が実際の問題になる可能性があるのはいつですか。

現在の成長率を考えると、MS SQLバージョンで符号付き整数のオーバーフローが発生するのはどのくらいの期間になると思いますか？

悲観的になりなさい。

アプリケーションはどのくらいの期間存続すると思いますか？

あなたはまだ2つの違いの要因があなたが心配すべきものだと思いますか？

（答えが何であるかはわかりませんが、解決策をさらに探す前に、本当に問題があることを確認する必要があると思います）

于 2008-08-27T09:39:12.323 に答える
1

これは最大 9,223,372,036,854,775,807 になるため、BIGINT データ型を使用することをお勧めします。

SQL Server は、符号付きおよび符号なしの値をサポートしていません。

于 2008-09-03T06:49:20.977 に答える
0

私はこう言います..「通常、コンポーネント間の違いをどのように処理しますか?」

変化するものをカプセル化..

データベースが MySQL であるか MS SQL であるかを気にしないようにするには、データ アクセス レイヤー内に抽象化レイヤーを作成する必要があります。

于 2008-08-27T08:00:20.563 に答える