1

私は、古いものとは別のデータベース (スキーマの大幅な変更) を使用するソフトウェアの新しいリリースが出てくる状況にいます。新しいシステムと古いシステムの両方が稼働する期間がかなり長くなり、2 つのデータベース間で一意の ID が生成されるようにする必要があります (データベース A に行は必要ありません)。データベースの行と同じ ID を持つ B)。データベースは Sybase です。

私が思いついた可能な解決策：

  1. 非常に大きな数値をサポートするデータ型を使用し、オーバーフローしないことを期待して、それぞれに範囲を割り当てます。
  2. 一方のデータベースには負の値を使用し、もう一方のデータベースには正の値を使用します。
  3. データベースを識別する追加の列を追加し、それと現在の ID の組み合わせを使用してキーとして機能します。
  4. 泣く。

他に何ができますか？2 つのデータベースを連携させるための、より洗練されたソリューションはありますか? 問題があれば、2 つのデータベースは同じサーバー上にあると思います。

4

7 に答える 7

6

GUID またはグローバルに一意の ID は、この種の場合に便利な主キーになる可能性があります。Sybase はそれらをサポートしていると思います。

編集: データベース全体がすでに整数の主キーに基づいている場合、GUID への切り替えはあまり実用的ではない可能性があります。

于 2009-05-01T14:37:03.000 に答える
5

私はこれが数回起こるのを見てきました。私が関わったものでは、古いものに十分な大きさの ID スペースを割り当てただけでした (それはしばらく運用されていたので、使用したキーの数を知っていたので、あと何個のキーを使用したかを計算できました)。指定された「ライフスパン」が必要です）、その上で新しいデータベースの「ID SEQUENCE」を開始しました。

「レガシー」アプリに変更を加える必要があるという理由だけで、他のトリックのいずれにも反対することをお勧めします。これはリスクであり、取る必要はないと思います.

于 2009-05-01T14:38:19.207 に答える
3

あなたの場合、uniqueidentifier (GUID) をデータ型として使用することを検討します。システム関数newid()を使用して作成すると、これらは一意であると見なされます。

CREATE TABLE customer (
   cust_key UNIQUEIDENTIFIER NOT NULL
            DEFAULT NEWID( ),
   rep_key VARCHAR(5),
   PRIMARY KEY(cust_key))
于 2009-05-01T14:39:25.320 に答える
2

古いデータベースをマージする前に、古いデータベースが到達するよりも大きい # を使用して、新しいデータベースを事前にシードします。

過去にこれを行ったことがありますが、レコードの量がかなり少なかったので、最初のレコード番号として 200,000 で新しいデータベースを開始しました。そして、その時が来たら、古い記録をすべて新しいシステムに移行しました。

完璧にうまくいきました！

于 2009-05-01T14:37:11.253 に答える
2

GUID は、このような状況向けに設計されています。

于 2009-05-01T14:37:11.940 に答える
2

各データベースで同様の数の新しいアイテムを作成する場合は、一方のデータベースで偶数の ID を試し、もう一方のデータベースで奇数の IDを試すことができます。

于 2009-05-01T14:39:50.747 に答える
1

UNIQUEIDENTIFIER データ型を使用します。私はそれが MS SQL Server で動作することを知っており、Google で見る限り、Sybase はそれをサポートしています。

http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbrfen9/00000099.htm

于 2009-05-01T14:39:33.243 に答える