4

特定の「レコードバージョン」へのINTを保持するデータベーステーブルの列を何と呼ぶか​​を理解しようとしています。私は現在「RecordOrder」を使用していますが、人々はhigher = newerと考えるので、それは好きではありませんが、私が使用している方法では、lower = newer（ "1"が現在のレコード、 "2"が現在のレコードです） 2番目に新しい、「3」古い、など）。「RecordVersion」を検討しましたが、同じ問題が発生するのではないかと思います。他に何か提案はありますか？「RecordAge」？

これを行っているのは、テーブルに挿入するときに、次のバージョンを確認する代わりに、書き込む前にその番号が盗まれるリスクを冒すのではなく、「RecordOrder」が0の挿入を挿入するだけだからです。 。テーブルAFTERINSERTには、そのキーのすべての「RecordOrder」番号を1つインクリメントするトリガーがあるため、挿入したばかりのレコードは「1」になり、他のすべてのレコードは1つ増えます。これにより、人の番号を取得できます。 MAX（RecordOrder）を取得して選択する代わりに、RecordOrder=1を選択して現在のレコードを選択します。

PS-私はまた、これがひどい考えである理由についての批判を受け入れており、代わりにこのインデックスを増やす必要があります。これにより、検索がはるかに簡単になりましたが、それが悪い考えである場合は、私に教えてください。

例として、データに関するいくつかの詳細：

次のデータベーステーブルがあります。

CREATE TABLE AmountDue (
    CustomerNumber INT,
    AmountDue      DECIMAL(14,2),
    RecordOrder    SMALLINT,
    RecordCreated  DATETIME
)

私のデータのサブセットは次のようになります。

CustomerNumber    Amountdue      RecordOrder                 RecordCreated
           100            0                1       2009-12-19 05:10:10.123
           100        10.05                2       2009-12-15 06:12:10.123
           100       100.00                3       2009-12-14 14:19:10.123
           101         5.00                1       2009-11-14 05:16:10.123

この例では、顧客100に対して3つの行があります。つまり、100ドル、次に10.05ドルの借金があり、現在は何も借りていません。もう少し明確にする必要がある場合はお知らせください。

アップデート：

「RecordOrder」列と「RecordCreated」列はユーザ​​ーが使用できません。これらは内部使用のためにのみ存在し、現在の顧客レコードを特定するのに役立ちます。また、日付を使用して同じように簡単に行うことができましたが、適切に注文された顧客履歴を返すために使用できました。RecordCreatedの日付だけで「レコードバージョン」をインクリメントするのと同じことを実行できると思いますが、これにより、RecordOrder = 1が現在のレコードであることがわかり、サブクエリを実行することに戻ります。最新のレコードを判別するためのDateTimeのMAXまたはMIN。

4

6 に答える 6

4

新しい現在のレコードを追加するときは、以前のすべてのバージョンを更新する必要があるため、「現在のバージョン=1」は悪い考えだと思います。また、古いバージョン番号を参照する他のテーブルやアプリケーションは正しくなくなります。そのように動作するメインフレームプログラムとインターフェイスするサービスを作成する必要があり、それは開発者の数十時間を無駄にする大きな頭痛の種でした。

私は通常、version_idフィールドを使用してバージョン管理を行います。フィールドは毎回インクリメントされます。次に、最新のレコードを検索するときにorder by version_id desc、クエリで最初の行のみを選択します。

編集： iandismeが指摘したデータウェアハウスタグは表示されませんでした。すべてのバージョンを選択しても機能しない場合は、各レコードの最新バージョンを別のテーブルに格納するだけの個別のテーブルを保持するシステムをいくつか見ました。したがって、新しいバージョンがRecordテーブルに追加されると、適切なRecordVersionレコードが更新されて、その新しいバージョンが保存されます。これは私が取り組んでいるものにとっては常にやり過ぎですが、データのウェアハウス全体には取り組んでいないので、それが良いか悪いかはわかりません。

于 2010-01-08T19:51:56.383 に答える
2

行のどのバージョンが最新であるかを示すために整数を使用する代わりに、現在の時刻のデフォルト値でTimeStampフィールドを使用する必要があると思います。

このように、誰がいつ行を追加しても、行の最新バージョンに関してあいまいさはありません。

関連するすべての行の番号をid+1に変更することは、複数の理由からお勧めできません。

  1. 変更する必要のないものを変更しています
    • ロックとブロックが増加します
    • 必要以上の処理能力とメモリを使用する
于 2010-01-08T20:05:17.653 に答える
1

RecordCreated日付を使用して本質的に同じことを達成できない理由は何ですか？

次のようなことをします：

select top 1 columna, columnb, etc. from table order by RecordCreated desc

最新のレコードが提供され、レコードの変更について心配する必要はありません。

レコードの番号変更アプローチでは、あらゆる種類の問題が発生する可能性があります（インデックスの競合、ロックのエスカレーションなど）。

ロックのエスカレーション： http： //msdn.microsoft.com/en-us/library/aa213033 （SQL.80）.aspx

インデックスの競合： http： //blogs.digineer.com/blogs/jasons/archive/2009/02/25/monitoring-index-contention-with-dmfs.aspx

データウェアハウジングに関して他の人が言及しているように、データセットの上にビューやスナップショットなどをいつでも配置して、希望する形式（最新のレコードのみなど）でデータを提供できます。明らかに、ビュー/スナップショットなどを知るのに十分な制約や要件はよくわかりません。あなたの状況では理にかなっています。

于 2010-01-08T19:52:24.217 に答える
1

タイムスタンプを使用するというRajMoreのアイデアが好きです。しかし、最新のレコードを検索するクエリは困難であり、処理量が多くなることを認識しています。
したがって、このアイデアを提案します。レコードの順序にはタイムスタンプ（とにかくあります）を使用しますが、最新のレコードを簡単に識別できるように1バイトのフィールドを保持します。
その場合、LatestRecord値が1である現在のレコードがあり、他のすべてのレコードはNULLです。このようにして、nullを無視してインデックスを作成できる可能性がありますか？
これにより、すべてのクエリが大幅に簡素化されます。

于 2010-01-08T20:31:16.353 に答える
0

あなたが話しているのはバージョンではなく年齢なので、RecordAgeと呼ぶことができます。しかし、あなたがやりたいと思われるのは特定の顧客の最新の注文を取得することだけなので、私はそれを完全に取り除きます。

これは、顧客番号と日付/時刻フィールドを使用して実現できます。これら2つの組み合わせを一意の制約にし、競合状態が発生するまれな機会にクライアントコードに再試行ロジックを配置すれば、問題は発生しないはずです。

レコードを挿入するときにトリガーを起動して多数のレコードを変更するという考えは、レコードが追加されるにつれてますます高価になるため、悪い考えです。

バージョン番号のような任意の列を導入する設計を非常に批判的に見てください。これは実際には派生属性であり（他の属性、この場合は顧客番号と日付によって異なります）、パフォーマンス上の理由からこれを行うことは問題ありませんが、特定の問題を軽減するために、結果を理解している場合にのみ行う必要があります。

トリガーのコストを自分で相殺するものとして、日付全体で小さな整数を使用した場合のパフォーマンスの向上はわかりませんが、すべてのデータベースの決定と同様に、推測しないでください。

于 2010-01-08T19:51:57.307 に答える
0

これで私が目にする問題は、データベースの処理時間の番号の付け直しに非常に多くの時間を浪費することです。また、recordOrderをユーザーに公開しているかどうかはわかりませんが、公開している場合は、その番号を使用して質問できるようにしたいと思うでしょう。また、継続的に変更することは、混乱と煩わしさの両方になります。そしてもちろん、あなたがすでに指摘した問題は、注文が将来の開発者が期待するものではない場合です。

IDフィールドを使用するだけで、番号付けが自動的に行われるのはなぜですか（そうすれば、挿入する前に番号を盗むことで問題が発生することはありません）。ID descと顧客番号で注文して1人のすべてのレコードを表示できる限り、顧客ごとに番号付けを繰り返すかどうかは本当に重要ですか？または、レコードの日付フィールドを使用して、レコードを注文することもできます。

于 2010-01-08T19:54:28.020 に答える