0

現在、在庫タイプのテーブルがあります（重要なフィールドのみを表示しています）：

Timestamp Account User  Symbol Locates 
---------+-------+---- +------+--------
 2012-...| ABC   | Joe | ZZZ  | 1000
---------+-------+---- +------+--------

ユーザーがロケート (共有) の数を調整する必要があるときはいつでも、新しいレコードをテーブルに投稿します。ユーザーが保有株数を調整するために、ほぼ同じデータを保存する必要があります。実際、異なる唯一のフィールドは、株式の調整のためLocatesに呼び出されるフィールドです。たとえば、次のようになります。Shares

Timestamp Account User  Symbol  Shares
---------+-------+---- +------+--------
 2012-...| ABC   | Joe | ZZZ  | 2000
---------+-------+---- +------+--------

問題は、検索用に 1 つと共有用に 1 つの 2 つのテーブルを使用する方がよいかどうか、または 1 つのテーブルを使用して列の名前を に変更し、トランザクション タイプを示す Enum 型のLocates列Sharesを追加する方がよいかどうかです ('LOCATES '、'位置'）。

現時点では、これに対するレポートの側面はありません。これは、ユーザーが行ったアプリケーション ストアの変更によって使用され、アプリケーションの再起動時に場所と共有を再構築するために使用されます。どちらのアプローチにも大きな利点があるとは思えないため、これは「ベスト プラクティスとは何か」というタイプの質問です。

アップデート

いくつかのコメントを読んだ後、このテーブルがどのように使用されているかを知らずに答えるのは難しいことに気付きました. うまくいけば、簡単な説明があります：

毎日の終わりに、データベースから取引データを一掃し、翌日にはデータが空になるようにします。この検索/共有データは、毎日引き継がれることはありません。

毎朝、アプリケーションが起動し、サード パーティによって毎日サーバーに公開されるフラット データ ファイルから、所有する共有と配置された共有を読み込みます (1 日の初めにデータベースから読み込まれるデータはありません)。取引日の間、ユーザーはサーバーにメッセージを送信することにより、株数および/またはロケートを調整できます。このメッセージは、サーバーのメモリ内の値を更新し、このテーブルにレコードを書き込み、正しい開始値を示します。(基本的に、フラット ファイルから読み込まれたものをオーバーライドします)。

日中にサーバーを再起動する必要がある場合 (まれに発生する可能性があります)、再起動時に、フラット ファイルからのデータがアプリケーションに再度読み込まれます。アプリケーションは、このテーブルのレコードも読み取り、アカウント/シンボルの組み合わせの最新のレコードを使用して、フラット データ ファイルから読み取った値をオーバーライドします。したがって、アプリケーションを再起動する必要がある場合、このテーブルは追加の日次データ ソースとして機能します。

4

1 に答える 1

1

3 番目のオプションとして、2 つのデータ列 (1 つはロケート用、もう 1 つは共有用) を使用する方法があります。

値が列挙型に依存する1つの汎用列を持つことは良い考えではないと思います。このような状況では、エラーが発生しやすくなります。特定の日のシェア調整の合計は? おっと、「ロケート」も含めました。

一部のデータベースは、計算列/計算列をサポートしています。このようなデータベースでは、行がロケートまたはシェア (またはその両方) のどちらであるかをインジケーター列で指定することもできます。

IsLocate as (case when locates is not null then 'Y' else 'N' end),
IsAdjustment as (case when shares is not null then 'Y' else 'N' end),
于 2012-08-09T21:59:13.650 に答える