8

バックグラウンド

私は、SQL Server 2005 によってホストされる単一のデータベースと多数のクライアント アプリケーションを備えた従来のスモール ビジネス自動化システム (在庫、販売、調達など) に取り組んでいます。メイン クライアント (すべてのユーザーが使用) は MS Access 2003 アプリケーション (ADP) で、その他のクライアントには、Excel アドインやコマンド ライン ユーティリティなどのさまざまな VB/VBA アプリケーションが含まれます。

60 ほどのテーブル (ほとんどが 3NF) に加えて、データベースには約 200 のビュー、約 170 の UDF (ほとんどがスカラーおよびテーブル値のインラインのもの)、および約 50 のストアド プロシージャが含まれています。ご想像のとおり、いわゆる "ビジネス ロジック" の一部は、この大量の T-SQL コードにカプセル化されています (したがって、すべてのクライアントで共有されます)。

全体として、システムのコード (T-SQL コードを含む) はあまり整理されておらず、いわばリファクタリングに非常に抵抗力があります。特に、ほとんどのテーブルのスキーマは、小規模 (列の名前変更など) から大規模 (正規化など) まで、あらゆる種類のリファクタリングを必要としています。

FWIW、私はかなり長い間まともなアプリケーション開発経験 (C/C++、Java、VB など) を持っていますが、DBA ではありません。したがって、質問がばかげているように見える場合は、なぜそうなのかがわかります。:-)

質問

このすべての混乱をリファクタリングすることを考えているときに (もちろん平和的な方法で)、次のアイデアを思いつきました。

  1. テーブルごとに、(a) テーブルに含まれるすべての列を含む「ラッパー」ビューを作成します。(b) 場合によっては、テーブルの「実際の」列に基づく追加の計算列があります。

    このような追加の計算列の典型的な (単純ではありますが) 例は、製品の通常価格と割引から派生した製品のセール価格です。

  2. 「ラッパー」ビューのみがテーブルを直接参照するように、すべてのコード (T-SQL と VB/VBA クライアント コードの両方) を再編成します。

    したがって、たとえば、アプリケーションまたはストアド プロシージャがテーブルからレコードを挿入/更新/削除する必要がある場合でも、テーブルに対して直接ではなく、対応する「テーブル ラッパー」ビューに対してそれを行います。

したがって、基本的にこれは、ビューによってすべてのテーブルをシステムの残りの部分から分離することです。

このアプローチは、特に保守性の観点から、多くの利点を提供するようです。例えば：

  • テーブル列の名前を変更する場合、影響を受けるすべてのクライアント コードを一度に書き直さなくても実行できます。

  • 派生属性を実装する方が簡単です (計算列を使用するよりも簡単です)。

  • 列名のエイリアスを効果的に使用できます。

明らかに、これらすべての利点には何らかの代償が必要ですが、そこにすべてのキャッチが潜んでいるのを見ているかどうかはわかりません.

誰かが実際にこのアプローチを試しましたか? 主な落とし穴は何ですか？

明らかな欠点の 1 つは、「ラッパー」ビューを対応するテーブルと同期して維持するコストです (テーブル内の新しい列もビューに追加する必要があります。テーブルから削除された列はビューからも削除する必要があります。など)。 .)。しかし、この価格は、コードベース全体をより回復力のあるものにするためには小さく、公正であるように思われます.

他の強力な欠点を知っている人はいますか?

たとえば、テーブルの代わりにこれらすべての「ラッパー」ビューを使用すると、パフォーマンスに何らかの悪影響が及ぶ可能性が非常に高くなりますが、この影響は心配するほど大きくなるでしょうか? また、ADODB を使用している場合、いくつかの結合されたテーブルに基づいている場合でも、更新できないレコードセットを取得するのは非常に簡単です。では、「ラッパー」ビューは事態を大幅に悪化させるのでしょうか? などなど…。

コメント（特に共有された実際の経験）は大歓迎です。

ありがとうございました！

PS私は、「ラッパー」ビューのアイデアを議論する次の古い記事を踏んだ：

ビッグビュー神話

この記事では、上記のアプローチを避けるようにアドバイスしています。しかし...この記事では、この考えに反対する正当な理由は見当たりません。まったく逆に、ビューを作成する正当な理由のリストでは、ほぼすべての項目がまさに、すべてのテーブルに対して「ラッパー」ビューを作成することが非常に魅力的である理由です (特にレガシー システムでは、リファクタリング プロセスの一部として) ）。

この記事は非常に古い (1999 年) ため、その理由が何であれ、当時は適切であったとしても、現在では適切ではない可能性があります (逆もまた同様です)。最新バージョンの SQL Server と MS Access を使用して、最近このアイデアを検討したり、試したりした人から話を聞くのは非常に興味深いことです...

4

3 に答える 3

11

データベースを設計するときは、次のことを好みます。

  • コードによるテーブルへの直接アクセスはありません (ただし、ストアド プロシージャ、ビュー、および関数からは問題ありません)
  • すべての列を含む各テーブルのベース ビュー
  • ルックアップ列 (タイプ、ステータスなど) を含む各テーブルの拡張ビュー
  • すべての更新のストアド プロシージャ
  • 複雑なクエリ用の関数

これにより、DBA はコード ベースを乱すことなく (列の追加、クリーンアップ、データの挿入などのために) テーブルを直接操作できるようになり、テーブルに加えられた変更 (一時的またはその他の変更) からコード ベースを隔離することができます。

この方法ではパフォーマンスが低下する可能性があります。

于 2008-10-26T05:19:07.920 に答える
4

1 つのテーブル ビューの場合、パフォーマンスへの影響はありません。SQL Server は、これらのビューを使用してコードの実行計画を作成するときに、基になるテーブルを使用します。ビューを変更せずに基になるテーブルを誤って変更しないように、これらのビューをスキーマ バインドすることをお勧めします (次の可哀想な人のことを考えてください)。

表の列の名前を変更する場合

私の経験では、これはめったに起こりません。列の追加、列の削除、インデックスの変更、およびデータ型の変更は、実行する通常のテーブル変更スクリプトです。

派生属性を実装する方が簡単です (計算列を使用するよりも簡単です)。

私はそれに異議を唱えます。計算を列定義に入れることとビュー定義に入れることの違いは何ですか? また、計算列ではなくビューに移動すると、パフォーマンスが低下します。唯一の本当の利点は、テーブルを変更するよりもビューで計算を変更する方が簡単であることです (インデックスとデータ ページのため)。

列名のエイリアスを効果的に使用できます。

これがビューを持つ本当の理由です。テーブルと列のエイリアシング、および複数のテーブルの結合。過去数回の仕事でのベスト プラクティスは、データを非正規化する必要がある場所でビューを使用することでした (既に指摘したように、ルックアップなど)。

いつものように、DBA の質問に対する最も誠実な回答は、状況やスキルセットなどに応じて「依存します」です。あなたの場合、「すべて」をリファクタリングすると、とにかくすべてのアプリが壊れます。ベース テーブルを正しく修正すると、ビューから取得しようとしている間接化は不要になり、将来の変更のためにスキーマのメンテナンスが 2 倍になるだけです。ラッパー ビューをスキップし、テーブルとストアド プロシージャ (すでに十分な情報が隠されています) を修正すれば問題ありません。

于 2008-10-26T09:59:17.417 に答える
1

私はスティーブンのコメントに同意します -- 主な理由は、あなたが Access を使用しているからです。このデータベースを再設計するときは、Access の長所と短所に焦点を合わせておくことが非常に重要です。私はそこにいて、Access フロントエンド/SQL Server バックエンドでそれを行いました (ただし、ADP プロジェクトではありませんでした)。

プロジェクト内の Access フォームの外部でデータが変更されないようにするには、ビューが便利だと付け加えておきます。欠点は、すべての更新でストアド プロシージャが必要になることです。ストアド プロシージャがない場合は、ストアド プロシージャも作成する必要があります。

于 2008-10-26T05:47:34.570 に答える