43ページのクエリを維持することは可能ですか？ [閉まっている]

StackOverflow https://stackoverflow.com/questions/800620

  •  03-07-2019
  •  | 
  •  

質問

SQLコンパイラーは壊れるといつも思っていましたが、明らかにネッシングはほとんど無限になります。このコードはすぐに破棄されるのでしょうか、それともこのような機能が機能するという希望が少しありますか？

このクエリは実際には私に属しているわけではないため、投稿できません...ただし、これ：

[SELECT /*+ NOPARALLEL bypass_recursive_check */ 
SP_ALIAS_190, 
((CASE SP_ALIAS_191
WHEN 1
THEN 'PROVIDER::ALL_PROV::'
WHEN 0]
役に立ちましたか？

解決

クエリがツール（またはコード）によって生成される場合、比較的簡単に維持できます（クエリ生成コードが実際に適切に作成され、維持可能であるという意味で）

他のヒント

明らかに、Sharepoint DALから出てくるSQLを見たことはありません。

最近、これに似た問題に遭遇し、いくつかのことを検討して決定しました。

  • これは、メンテナンスとリライトにどれくらいの時間がかかりますか
  • これはどれほど重要ですか？ <！> quot; it works <！> quot;という事実には、解明するのが難しいかもしれない論理がたくさんあるかもしれません。即時書き換えの値を超えています。

そしてもちろん、最近作成されたものを書き直さなければならない理由を説明するリスクについて、経営陣が決定しなければならなかったものがありました。

最後に（私にとって）、find + replaceは私の友人でした。

WITH ステートメント。 たくさんのコメントをたくさん追加してください。

管理可能な部分に分割すると、はるかに良いチャンスが得られます。

それがネストの割り当てを含む場合、私はノーと言うでしょう。

どの言語のコードでも、コードの書き直しに注意する必要があります。より効率的または理解しやすくするためです。

経験に基づいて、不適切に作成されたSQLをサイズを4倍から5倍、パフォーマンスを何倍にも縮小することができました。

それが悪いと思う場合は、インダストリアルロジックのサンプルビデオをご覧ください：技術的債務。絶対に自動生成されません。

たとえばC＃で43ページの機能を維持することは可能ですか？答えは明らかです;）。これは想像できません。もし私があなただったら、もっと小さな部分に分けます。

2つのこと：

  • このSQLを読む必要があるのはマシンだけですか？
  • 基礎となるスキーマにこだわっていますか？

43ページのクエリがあり、最初の2つの質問に「はい」と答えた場合、SharePoint開発へようこそ

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top