タグ付けされた質問 「reporting」

私は従業員の時間記録についていくつかのレポートを作成しようとしています。 この質問に特化した2つの表があります。従業員はMembersテーブルに一覧表示され、毎日、彼らが実行した作業の時間エントリを入力し、Time_Entryテーブルに保存されます。 SQL Fiddleでの設定例：http ://sqlfiddle.com/#!3/ e3806/7 私は行くよ最終結果は番組表であるALLMembers列リストで、その後は他の列に照会した日のために彼らの合計時間が表示されます。 問題はTime_Entry、特定のメンバーのテーブルに行がない場合、そのメンバーの行があることです。私はいくつかの異なる結合タイプ（左、右、内部、外部、完全外部など）を試しましたが、（SQL Fiddleの最後の例に基づいて）希望どおりの結果が得られないようです。 /*** Desired End Result ***/ Member_ID | COUNTTime_Entry | TIMEENTRYDATE | SUMHOURS_ACTUAL | SUMHOURS_BILL ADavis | 0 | 11-10-2013 | 0 | 0 BTronton | 0 | 11-10-2013 | 0 | 0 CJones | 0 | 11-10-2013 | 0 | 0 …

12 sql-server  sql-server-2008  join  group-by  reporting 

私は小規模な（従業員数50人まで）SaaS企業のSQL開発者（DBAまたはアーキテクトではありません）です。私は次の方法を理解する必要があります。 100以上のOLTPデータベースから運用レポートをオフロード これらのレポートを複数のクライアントデータベースのデータに対して実行できるようにする 将来的に分析ベースのソリューションを提供するように当社を位置づける トランザクションレプリケーション（特に多対1 /中央サブスクライバーモデル）、SQLサービスブローカー、ログ配布、変更追跡（CT）、および変更データキャプチャ（CDC）などのさまざまなテクノロジに関する記事をいくつか読んだことがあります。これは企業専用です）、どの経路が最適かはわかりません。 統合に関する専門知識をお持ちの方が、私たちと同様の設定に出会い、成功への道筋を示したり、役立つリソースに案内したりできることを願っています。 コストの制約により、このソリューションはSQL Server Standard Edition内で機能する必要があります。また、このソリューションは、小規模な組織内でサポート/維持するために合理的でなければなりません。 基本構成： 現在、100を超える個別のクライアントデータベースがあり、ほとんどがデータセンターのSQLサーバーに展開されていますが、一部はリモートアクセス可能なデータセンター内のクライアントサーバーに展開されています。これらはすべてSQL Server 2008 R2データベースですが、近日中にSQL 2016にアップグレードする予定です。 データベースプロジェクトとdacpacsを使用して、統合されるすべてのクライアントデータベースでスキーマが同じになるようにします。ただし、すべてのクライアントに同時に新しいバージョンへのアップグレードを強制するわけではないため、アップグレード間でスキーマが異なる場合があります。ソリューションは、クライアントAがソフトウェアバージョン1.0にあり、クライアントBがバージョン1.1にある場合に中断しないように十分に柔軟でなければなりません。 運用レポートは現在、各クライアントのOLTPデータベースから直接実行されます。これをオフロードしない場合、アプリケーションのパフォーマンスに与える影響を懸念しています。 高レベルの要件： 私たちのクライアントは、病院の無菌処理部門（SPD）で、これまでに処理したもの、在庫がある場所などに関する最新のレポートが必要です。SPDは、週末と休日を含め、24時間体制で在庫を処理します。この取り組みの主な目的の1つは運用レポートをより適切にサポートすることであるため、クライアントのニーズに対応し続けるために、データをできる限りリアルタイムに近づけることを望んでいます。 現在、実際には同じ病院システムの一部である個別のデータベースにいくつかのSPDがあります。これらのクライアントは、システム内のすべてのSPDに対してレポートを作成する機能を求めています。 戦略的に言えば、社内の分析イニシアチブをサポートするために、すべてのクライアントのデータを簡単に集約できる機能が必要です。収集した運用データをデータマート/倉庫のソースとして使用できることが期待されます。 これまでの考え： トランザクションレプリケーションは、最も「リアルタイム」なソリューションを提供するようです。この応答が特に役立つことがわかりましたが、スキーマの違いが生じる可能性があるため、SQL Serverの多対1レプリケーションが機能しないことを懸念しています。 クエリがアクティブな間はログを復元できないので、ログ配布は理想的に聞こえません。ログを復元できるようにするには、全員を追い出す必要があります。そうしないと、データが古くなります。この方法が複数のデータベースからのデータを一元化するために使用できるかどうかは不明です。出荷される各ログは、それが由来する個々のデータベースに関するもののみであるためです。 SQLサービスブローカーを使用する場合、キューが処理するメッセージの数に対応できなかった場合、レイテンシは予測できない場合があります。 CTは、各テーブル行のバージョンのみを識別します。レイテンシは、データを取得して中央リポジトリに挿入するために、各データベースに対してSSISパッケージのようなものをどれだけ速く処理できるかに依存します。 各データベースを個別にレプリケートすることを検討する必要があり、その後、ある種のデータ仮想化手法を使用して、さまざまなレプリケートされたソースからのデータを組み合わせる必要があるでしょうか。 あなたが提供したいアドバイスや指示があれば、大歓迎です。

10 sql-server  replication  reporting  integration 

多くのタイムゾーンのデータに対するレポートをサポートするデータウェアハウスの設計を最適化しようとしています。たとえば、アクティビティを1日の時間でグループ化して表示する必要がある、1か月分のアクティビティ（数百万行）のレポートがあるとします。そしてもちろんその日の時間は与えられたタイムゾーンの「ローカル」時間でなければなりません。 UTCと1つの現地時間をサポートしたときにうまく機能するデザインがありました。UTCおよび現地時間の日付と時刻のディメンションの標準設計、ファクトテーブルのID。ただし、100以上のタイムゾーンのレポートをサポートする必要がある場合、そのアプローチは拡張されないようです。 ファクトテーブルは非常に広くなります。また、レポートの特定の実行でグループ化に使用する日付と時刻のIDを指定するSQLの構文の問題を解決する必要があります。おそらく非常に大きなCASEステートメントでしょうか？ カバーしているUTC時間範囲ごとにすべてのデータを取得し、それをプレゼンテーションレイヤーに戻してローカルに変換してそこで集計するといういくつかの提案を見てきましたが、SSRSを使用した限られたテストでは、非常に遅くなることが示唆されています。 私はこの主題についてもいくつかの本を調べましたが、それらはすべて、UTCがあり、ディスプレイで変換するか、UTCと1つのローカルがあると言っているようです。任意の考えや提案をいただければ幸いです。 注：この質問は「データマート/倉庫でのタイムゾーンの処理」に似ていますが、その質問についてはコメントできません。 更新： Aaronが重要な更新を行い、サンプルコードと図を投稿した後、私はAaronの回答を選択しました。彼の回答に対する私の以前のコメントは、回答の元の編集を参照しているため、あまり意味がありません。必要に応じて戻ってきてこれをもう一度更新しようとします

10 sql-server  database-design  data-warehouse  reporting  timezone 

さまざまな種類の活動をサイトに関連付けるアプリケーションを継承しました。アクティビティタイプはおよそ100種類あり、それぞれに3〜10個のフィールドの異なるセットがあります。ただし、すべてのアクティビティには、少なくとも1つの日付フィールド（日付、開始日、終了日、予定された開始日などの任意の組み合わせ）と、1つの担当者フィールドがあります。他のすべてのフィールドは大きく異なり、開始日フィールドは必ずしも「開始日」と呼ばれるわけではありません。 アクティビティタイプごとに1つのサブタイプテーブルを作成すると、スキーマが100の異なるサブタイプテーブルになり、扱いにくいので扱いにくくなります。この問題の現在の解決策は、アクティビティ値をキーと値のペアとして保存することです。これは、ポイントを理解するために、現在のシステムを大幅に簡略化したスキーマです。 各アクティビティには複数のActivityFieldsがあります。各サイトには複数のアクティビティがあり、SiteActivityDataテーブルには各SiteActivityのKVPが格納されます。 これにより、（Webベースの）アプリケーションのコーディングが非常に簡単になります。必要なのは、特定のアクティビティのSiteActivityDataのレコードをループし、各行のラベルと入力コントロールをフォームに追加することだけです。しかし、多くの問題があります： 整合性は悪いです。アクティビティタイプに属さないフィールドをSiteActivityDataに配置することは可能です。DataValueはvarcharフィールドであるため、数値と日付を常にキャストする必要があります。 このデータのレポートとアドホッククエリは難しく、エラーが発生しやすく、低速です。たとえば、指定された範囲内の終了日を持つ特定のタイプのすべてのアクティビティのリストを取得するには、ピボットとvarcharを日付にキャストする必要があります。レポートの執筆者たちはこのスキーマを憎んでおり、私は彼らを責めません。 だから私が探しているのは、レポートが簡単になるような方法で、共通のフィールドがほとんどない多数のアクティビティを保存する方法です。これまでに思いついたのは、XMLを使用して疑似非SQL形式でアクティビティデータを格納することです。 Activityテーブルには、各アクティビティのXSDが含まれるため、ActivityFieldテーブルは不要になります。SiteActivityにはキーと値のXMLが含まれるため、サイトの各アクティビティは1行に表示されます。 アクティビティは次のようになります（ただし、完全に具体化していません）。 <SomeActivityType> <SomeDateField type="StartDate">2000-01-01</SomeDateField> <AnotherDateField type="EndDate">2011-01-01</AnotherDateField> <EmployeeId type="ResponsiblePerson">1234</EmployeeId> <SomeTextField>blah blah</SomeTextField> ... 利点： XSDはXMLを検証し、データベースレベルで数値フィールドに文字列を入力するなどのエラーをキャッチします。これは、すべてをvarcharに格納していた古いスキーマでは不可能でした。 Webフォームの構築に使用されるKVPのレコードセットは、 select ... from ActivityXML.nodes('/SomeActivityType/*') as T(r) XMLのxpathサブクエリを使用して、ピボットを使用せずに、開始日、終了日などの列を持つ結果セットを作成できます。 select ActivityXML.value('.[@type=StartDate]', 'datetime') as StartDate, ActivityXML.value('.[@type=EndDate]', 'datetime') as EndDate from SiteActivity where... これは良い考えのように思えますか？このように多数の異なるプロパティセットを格納する他の方法は考えられません。既存のスキーマを保持し、データウェアハウスでクエリしやすいものに変換することも考えていましたが、スタースキーマを設計したことがなく、どこから始めればよいかわかりません。 追加の質問：XSDでを使用して日付データ型を持つタグを定義すると、xs:dateSQL Serverはそれを日付値としてインデックス付けしますか？日付でクエリを実行する場合、日付文字列を日付値にキャストし、インデックスを使用する可能性をなくす必要があるかどうか心配です。

9 database-design  sql-server-2012  schema  reporting 

レポート目的でデータベースのスナップショットを使用することのパフォーマンス上の利点は何ですか？ 私の見たところ、元のデータベースへの書き込みごとに、スナップショット自体に別の書き込みを行う必要があるため、おそらくパフォーマンスが低下します。 その時点までのデータのレポートを作成したいときはいつでもスナップショットを使用することがわかりますが、それはパフォーマンスのカテゴリに分類されません。 繰り返しますが、パフォーマンス上の利点はありますか？

8 sql-server  performance  snapshot  reporting