15

私はデータベース駆動型システムの開発の初期段階にあり、システムの大部分は継承タイプの関係を中心に展開しています。約 10 列の親エンティティがあり、親から継承する約 10 の子エンティティがあります。各子エンティティには、約 10 列があります。親エンティティに独自のテーブルを与え、それぞれの子エンティティに独自のテーブル (サブクラスごとのテーブル構造) を与えることは理にかなっていると思いました。

今日、ユーザーから、私が作成したシステムの構造を見せてほしいというリクエストがありました。彼らは、table-per-subclass 構造のアイデアに難色を示しました。独自のカスタム クエリを実行しやすいため、100 列までの大きなテーブルを 1 つ好むでしょう。

ユーザーのためにデータベースの非正規化を検討する必要がありますか?

4

13 に答える 13

59

絶対違う。後でいつでもビューを作成して、彼らが見たいものを見せることができます。

于 2009-11-13T16:29:27.297 に答える
13

彼らは効果的に報告を求めています。

必要なすべてのフィールドを含むビューへのアクセスを彼らに与えることができます...そうすれば、データモデルを台無しにすることはありません.

于 2009-11-13T16:29:30.980 に答える
8

いいえ。データを適切に構造化し、ユーザーがデータの非正規化されたビューを必要とする場合は、データベースに VIEW として作成します。

あるいは、おそらく RDBMS はこのプロジェクトに適したストレージ ツールではないことを考慮してください。

于 2009-11-13T16:30:15.917 に答える
5

彼らはユーザーであり、システムのプログラマーではありません。クエリ用に別のインターフェイスを提供します。このようなパワー ユーザーは、役に立ちますが、対処するのが面倒です。仕事ができるように、特定の方法で設計されたデータベースが必要であることを説明してください。それが完了したら、クエリを簡単にする他の手段を提供します。

于 2009-11-13T16:35:17.787 に答える
4

彼らは何を知っている!? そもそもユーザーがデータベースに直接アクセスするべきではないと主張することもできます。

これを行うと、数人のユーザーがばかげたクエリを実行しているという理由だけで、大きなパフォーマンスの問題が発生する可能性があります。

于 2009-11-13T16:35:44.160 に答える
3

適切に正規化されたテーブルを維持しながら、ユーザーが望む形式で VIEW を作成した場合はどうでしょうか?

于 2009-11-13T16:29:55.327 に答える
3

ユーザーの提案に賛成または反対する多くの技術的な理由は別として、さまざまなシナリオの結果と (さらに重要なことに)それらの結果のコストを伝える際に同じページにいる必要があります。ユーザーがあなたのクライアントであり、仕事をするためにあなたにお金を払っている場合は、彼らのひどい「提案された」アイデアは、開発時間や追加のハードウェア リソースなどにより多くの費用がかかる可能性があること を説明してください。

うまくいけば、あなたの専門知識と、あなたのアイデアが長期的にはユーザーにとってより優れた価値を持つ理由を示すような方法で説明できます。

于 2009-11-13T16:58:04.847 に答える
2

多かれ少なかれ誰もが言ったように、その方法は狂気であり、いつでもビューを構築できます。

この点について彼らを説得できない場合は、このスレッドと、ユーザーが完全に理解していないことに干渉していると主張するプロの数を示すことを検討してください。土台を崩した。

開発者の技術の大部分は、長期的にはうまくいかないものを感じ取ることであり、正規化のルールはその点でほぼ標準的です。非正規化が必要な状況 (データ ウェアハウスなど) もありますが、これはその 1 つとは思えません。

また、あなたの手元には特に厄介なブランドのユーザーがいるように思えます。それは、時間があれば自分の仕事をもっとうまくやれると考えているアマチュア開発者です。これは役に立つかもしれないし、役に立たないかもしれませんが、私はこれらのタイプがプレゼンテーションにうまく反応することを発見しました.私は専門家であり、多くの問題を未然に防ぎます。

于 2009-11-13T18:03:18.273 に答える
1

顧客は常に正しい。ただし、顧客の要件をドルやセントに換算すると、顧客は引き下がる可能性があります。100 列のテーブルでは、データベースが適切な実装で自動的に行うコードを記述するために、追加の開発時間が必要になります。さらに、コードが増えると問題が増え、デバッグのしやすさが低下するため、サポート コストが高くなります。

于 2009-11-13T18:28:25.383 に答える
1

私はここで悪魔の擁護者を演じて、両方のソリューションが実際のデータの貧弱な近似のように聞こえると言います. オブジェクト指向プログラミング言語がこれらのデータ モデルのいずれかで実装されない傾向があるのには理由があります。それは、リレーションに関する Codd の 1970 年のアイデアが、オブジェクト指向データ構造を格納およびクエリするための理想的なシステムだったからではありません。:-)

SQL はもともとユーザー インターフェイス言語として設計されたことを思い出してください (そのため、SQL は漠然と英語に似ており、その時代の他の言語 (Algol、C、APL、Prolog) とはまったく異なります)。現在、SQL データベースをユーザーに公開しない唯一の理由は、セキュリティ (ユーザーがサーバーをダウンさせる可能性があります!) と使いやすさ (カチッとクリックできるときに SQL を書きたいと思う人がいるでしょうか?) だけです。したいのなら、なぜそれらをさせないのですか?

「システムの大部分が継承タイプの関係を中心に展開している」ことを考えると、それをネイティブに表現できるデータベース、Postgres (SQL が重要な場合) またはネイティブオブジェクトデータベース (素晴らしい) のいずれかを真剣に検討します。 SQL との互換性が必要ない場合)。

最後に、すべてのエンジニアリング上の決定はトレードオフであることを忘れないでください。(他の誰かが提案したように)「自分の銃に固執する」ことで、ユーザーの欲求の価値はゼロであると暗黙のうちに言っています. SO にこれに対する正しい答えを求めないでください。なぜなら、ユーザーがあなたのデータで何をしたいのか (またはあなたのデータが何であるか、またはあなたのユーザーが誰であるかさえ) がわからないからです。多テーブル ソリューションが必要な理由を彼らに伝えてから、両者が受け入れられる解決策を一緒に考えてください。

于 2009-11-13T18:30:25.520 に答える
1

データベースに対して直属の部下が誰かを実行することを含まない回答を考え出すことを強くお勧めします。その瞬間、DB 構造は固定され、基本的にレガシーと考えることができます。

ビューは良い出発点ですが、後でさらに分離するために、これをエクスポートとして構造化することをお勧めします。もちろん、「リアルタイム」のデータが必要な人に出くわすでしょう。通常、適切なビジネス分析により、これは不要であることがわかります。実際のリアルタイム要件は、レポート システムで処理するのが最善ではありません。

明確にするために、私は個人的にサブクラスごとのテーブルアプローチを好みますが、実際にはトランザクションテーブルからの直接報告ほど大きな問題ではないと思います.

于 2009-11-13T16:50:20.510 に答える
1

ビュー(他の人が示唆しているように)またはインラインテーブル値関数を選択します(これの利点は、日付範囲や顧客アカウントなどのパラメーターが必要であることです。これにより、ユーザーが制限なしでクエリを実行するのを防ぐことができます問題空間) 最初に。インライン TVF は、実際にはパラメーター化されたビューであり、エンジンがそれらを処理する方法という点で、パフォーマンスが非常に低くなる複数ステートメントのテーブル値関数やスカラー関数よりもはるかにビューに近いものです。

ただし、ビューが複雑または集約的である場合、場合によっては、これが本番パフォーマンスに影響を与える可能性があります。適切に作成されていないアドホック ユーザー クエリを使用すると、より適切に作成されたクエリよりもロックが長く持続したり、さらにエスカレートしたりする可能性があります。また、ユーザーが ER データ モデルを誤って解釈し、多対 1 または多対多の関係がある場合に乗算された数値を生成する可能性もあります。次のオプションは、インデックスを使用してこれらのビューを具体化するか、テーブルを作成してそれらを更新し続けることです。これにより、次のオプションに近づきます...

したがって、ビュー オプションのこれらの欠点と、データのコピーを作成することで軽減することを既に考えていることを考えると、次に検討するオプションは、異なる構造のデータの別の読み取り専用 (これらのユーザー向け) バージョンを用意することです。 . 通常、私は最初に Kimball スタイルのスター スキーマを調べます。完全な時間整合性データ ウェアハウスは必要ありません。もちろん、それはオプションですが、レポート モデルを最新のデータに保つこともできます。スター スキーマは非正規化の特殊な形式であり、特に数値レポートに適しています。特定のスターがユーザーによって誤って悪用されることはありません。トリガー、スケジュールされたジョブなど、さまざまな方法でスターを最新の状態に保つことができます。

このようなソリューションでは、実質的に 2 倍以上のストレージ要件が必要になる場合がありますが、データをよく理解し、トランザクション用と分析用の 2 つのモデルを使用することを気にしない場合、他の方法と比較すると、非常に優れたオプションになる可能性があります。 (ビューの最も単純な最初のオプションを使用して、とにかくこの論理的な分離をすでに開始していることに注意してください)。

一部のアーキテクトは、多くの場合、サーバーを 2 倍にし、何らかのレプリケーションを使用して SAME モデルを使用して、より頻繁に、または異なる方法でインデックスが作成されたレポート サーバーを提供します。このような 2 番目のサーバーは、レポート要件のある運用トランザクションに影響を与えず、かなり簡単に最新の状態に保つことができます。モデルは 1 つしかありませんが、もちろん、これにはユーザーが独自のプレイグラウンドを取得するため、パフォーマンスに影響を与えることなく、基礎となるモデルのみにアドホックにアクセスできるようにするという同じユーザビリティの問題があります。

これらの猫の皮をむく方法はたくさんあります。幸運を。

于 2009-11-13T18:23:40.313 に答える
0

あなたはClass Table Inheritanceを実装しましたが、彼らはSingle Table Inheritanceを求めています。どちらのデザインも特定の状況で有効です。

Martin Fowler のPatterns of Enterprise Application Architectureのコピーを入手して、各設計の長所と短所について詳しく読むことをお勧めします。いずれにせよ、その本はあなたの本棚にある古典的なリファレンスです.

于 2011-07-12T16:51:00.217 に答える