0

私の会社では最近、次のロジックを使用していくつかのデータベース フィールドの割り当てを実行する既存のプログラムの修正に取り組んでいます。

db-buffer1.field1 = if db-buffer1.field1 <> db-buffer2.field2
                        then db-buffer2.field2
                        else db-buffer1.field1

ここでの元のプログラマーの意図について 100% 確信があるわけではありません。新しいフィールドを割り当てるかどうかを決定する前に、フィールド値が異なるかどうかを比較して、値を理解するのを手伝ってくれる人はいますか?

比較が「偽」であり、最終的に代入する場合db-buffer1.field1 = db-buffer1.field1、データベースへの書き込み操作を回避できますか?

ASSIGNまた、この例は、同様の代入/比較ロジックを実行する複数のフィールドを含むより大きなステートメントの一部であることにも注意してください。この追加コードの価値に影響はありますか? ASSIGN(つまり、DB 書き込みを回避するために、ステートメント内のすべての比較が成功する必要がありますか?)

4

3 に答える 3

0

assign ステートメントの残りの部分を確認することに非常に興味がありますが、この場合は値を追加せず、余分な命令を追加するだけなので、if ロジックも削除します。テリーが上で述べたように

 ASSIGN db-buffer1.field1 = db-buffer2.field2.
于 2013-07-29T09:30:23.950 に答える
0

式の右側の「IF 関数」は、C または Javascript の「三項演算子」(「?:」構造) によく似ています。

ASSIGN の一部である部分にのみ影響します。それらを使用してコードを記述するときは、明確にするために常に括弧で囲みます。そのようです：

assign
  a = ( if x = y then b else c )
  z = 2
.

WRITE が発生するかどうかは、残りのコードに大きく依存します。

このスニペットだけで判断すると、(少なくとも論理的に) 何かを書くことになります。db-buffer.field1 はそれに関係なく割り当てられた値を取得します。右側の IF ロジックは、フィールド 1 かフィールド 2 かを選択するだけです。field1 = field1 に要約される場合、いくつかの下位レイヤーが存在しない書き込みを最適化することを望むかもしれません。あなたのプログレス バージョンは投稿されていませんが、v9 以上であれば最適化されている可能性があります。(v9 より前はそうではありませんでした。)

アプリケーションレベルで本当に「書き込みを回避」したい場合は、次のようにコーディングする必要があります。

if field1 <> field2 then
  assign
    field1 = field2
  .

このフォームは IF 関数を使用せず、通常の IF ... THEN ステートメントです。はるかに明確で、下位レベルの最適化に依存しません。もちろん、示されているスニペットはより大きな ASSIGN の一部であると言われています。しかし、それは考える価値があるでしょう。

于 2013-07-25T20:09:24.527 に答える