2011-11-15 9 views
0

アカウント(表)最善の方法は、一つのテーブル

+----+----------+----------+-------+ 
| id | account# | supplier | RepID | 
+----+----------+----------+-------+ 
| 1 | 123xyz | Boston |  2 | 
| 2 | 245xyz | Chicago |  2 | 
| 3 | 425xyz | Chicago |  3 | 
+----+----------+----------+-------+ 

ペイアウト(表)

+----+----------+----------+-------------+--------+ 
| id | account# | supplier | datecreated | Amount | 
+----+----------+----------+-------------+--------+ 
| 5 | 245xyz | Chicago | 01-15-2009 | 25  | 
| 6 | 123xyz | Boston | 10-15-2011 | 50  | 
| 7 | 123xyz | Boston | 10-15-2011 | -50 | 
| 8 | 123xyz | Boston | 10-15-2011 | 50  | 
| 9 | 425xyz | Chicago | 10-15-2011 | 100 | 
+----+----------+----------+-------------+--------+ 

私はaccountsテーブルを持っていると私は、配当テーブルを持っているから* *の重複を含む2つのテーブルに参加します。ペイアウトテーブルは海外から来ており、私たちはそれを支配していません。このため、レコードIDフィールドに基づいて2つのテーブルに参加できないという問題があります。これは、解決できない1つの問題です。したがって、Account#、SupplierID(2列目と3列目)に基づいて参加します。これは多分多くの関係を(おそらく)作り出すという問題を引き起こす。しかし、私たちのレコードはアクティブな場合にフィルタリングを行い、ペイアウトが作成されたときにはペイアウトテーブルに2番目のフィルタを使用します。ペイアウトは月単位で作成されます。私の見解では、この2つの問題

  1. クエリが完了するまでにかなりの時間を要する(非効率的かもしれない)
  2. は削除すべきではありません削除される一定の重複がありますがあります。例は配当表のレコード6と8です。ここで何が起こったのか、私たちは顧客を得て、顧客はそれを取り消し、彼は彼を戻しました。この場合、+50、-50、+ 50。再度、すべての値が有効であり、監査の目的でレポートに表示する必要があります。現時点では+50が1つしか表示されず、もう1つが失われます。報告書には、しばらくの間に来るいくつかの他の問題があります。

ここにクエリがあります。それはグループを使用して重複を削除します。私は、パフォーマンスの優れた事前照会をしたいと思います。また、PayOutテーブルのレコードは、レポートの月に表示されている限り複製されないことを考慮に入れています。ここで

は、私たちの現在のクエリ

/* Supplied to Store Procedure */ 
----------------------------------- 
@RepID // the person for whome payout is calculated 
@Month // of payment date 
@year // year of payment date 
----------------------------------- 
select distinct 
A.col1, 
A.col2, 
... 
A.col10, 
B.col2, 
B.Col2, 
B.Amount /* this is the important column, portion of which goes to Rep */ 
from records A 
JOIN payout B 
on A.Supplier = B.Supplier AND A.Account# = B.Account# 
where datepart(mm, B.datecreated) = @Month /* parameter to stored procedure */ 
    and datepart(yyyy, B.datecreated) = @Year 
    and A.[rep ID] = @RepID /* parameter to SP */ 
group by 
col1,col2,col3,....col10 
order by customerName 

このクエリが最適ですか? CROSS APPLYまたはWHERE EXISTを使用して改善することができます。これにより、重複した問題を削除するだけでなく、処理が高速になります。

このクエリは、担当者の支払いを得るために使用されます。したがって、すべてのレコードは、それが割り当てられたフィールドをrepidしています。理想的には、Select WHERE Existクエリを使用したいと思います。

+0

選択したフィールドに実際のフィールドを表示できますか?どのフィールドがどのテーブルから取得されるかを知ることは重要です。 – JNK

+1

そして、あなたは実際に何をしたいですか?あなたはあなたに「重複」問題があると言いますが、_more_行(7&8)を望んでいるようです。現在の/望ましい結果セットを持つことは役に立ちます。 –

+0

重複が削除されました。彼らは削除されますが、そこにいるはずです。私は実際のクエリを投稿できないのではないかと心配しています。私のクエリは実際のクエリを除いて実際のものと非常に似ていますが、MAX(col1 case statement)が使用されていますが、私はそれが不自然であることがわかりました。そしてそれは10のグループ・ステートメントを使用することにつながります。私はこれは健全なクエリを改善/修正する方法は、専門家の意見が欲しい。 –

答えて

0

あなたが欲しいものを正確に理解するのは難しいです。ある場所では、重複を「欲しい」と言いますが、重複を削除するためにグループを使用していると言います。だから最初の考えは "グループを取り除くだけではどうですか?"しかし、私はあなたが自分自身を考えているほどスマートであると信じなければならないので、それは理由のためにそこにいなければならないと思います。

私はあなたが実際のクエリを投稿することができれば、ここで誰かがかなり簡単にあなたを助けることができると思いますが、あなたが言うので、あなたは、私はちょうど問題を解決するにはあなたにいくつかの方向性を与えることをしようとすることはできません...

代わりに1つのステートメントですべてを実行しようとすると、一時テーブルまたはビューを使用して分割します。あなたが望んでいない重複を取り除いて、最初にやったものを残してそれらを一時テーブルに入れ、テーブルを一緒に結合してそれを使って作業する方法について考えるのは簡単かもしれません。

+0

前のプログラマーはgroup byとdistinctを使用して重複を削除しました。質問に記載されているように、重複している必要があることがわかりました。 CROSS APPLYを使用してクエリを書き換えました。私はまだトラブルシューティングを行い、その結果をオリジナルと比較しています。私はそれが実際のクエリを投稿するのが一般的な習慣であるとは思っていませんし、もし私がそれで多くのものを変更することができます。私はそれを動作させることができない場合、私はよくそれを投稿する可能性があります。質問の私の他の部分は、このクエリサウンドです。それはパフォーマンスの改善とより良く書けますか? –

+0

音が良いかどうかは、やや主観的な質問です。私のアプローチは、トップレベルのクエリで悪いデータを補正する式を持たないようにすることです。つまり、データをフィルタリング/変換して最初にどのようにしていたのか、そのデータを照会するというクエリやビューを持つことができます。 –

関連する問題