14

2つまたは3つのデータベーステーブルを共有するいくつかのアプリケーションを設計しており、他のすべてのテーブルは各アプリから独立しています。共有データベースには主にユーザー情報が含まれており、他のテーブルを共有する必要がある場合もありますが、それが私の本能です。

参照整合性が必要なため、すべてのアプリケーションソリューションに対して1つのデータベースに頼っています。各データベースで同じ情報を最新の状態に保つ必要はありませんが、おそらく最後に10個のテーブルのグループのみが関連情報を持つ100以上のテーブルのデータベース。

アプリケーションごとのデータベースアプローチは、すべてをより整理された状態に保つのに役立ちますが、すべてのデータベースの関連テーブルを最新の状態に保つ方法がわかりません。

したがって、基本的な質問は、両方のアプローチのどちらをお勧めしますか？

ありがとう、

ホルヘ・バルガス。

編集1：

参照整合性を持たないことについて話すとき、それは、テーブルが異なるデータベースにある場合、テーブルに外部キーを含める方法がないためです。アプリケーションごとに少なくとも1つのテーブルには、共有の1つへの外部キーが必要です。テーブル。

編集2：

関連する質問へのリンク：

2番目のものだけが受け入れられた答えを持っています。まだ何をすべきかを決めていません。

答え：

アプリケーションごとにデータベースを使用し、共有データベースへのクロスデータベース参照を使用し、共有データベースのテーブルを模倣するビューを各データベースに追加し、NHibernateをORMとして使用することにしました。メンバーシップシステムとして、asp.netシステムを使用します。

また、トリガーと論理的削除を使用して、親なしでリヴィン・ラ・ヴィダ・ロカを飛び回るIDの数を最小限に抑えようとします。データベースの同期を維持するために必要な開発作業は多すぎ、見返りは少なすぎます（皆さんが指摘しているように）。だから、私はむしろ孤立したレコードを介して自分の道を戦うことを望みます。

ORMとビューの使用が最初にsvintoによって提案されたので、彼は正しい答えを取得します。

この難しい決断を手伝ってくれたすべての人に感謝します。

4

9 に答える 9

6

どちらの方法も理想的に見えません

アプリケーション間の関係については、データベース層で参照しないことを検討し、アプリケーション層で参照する必要があると思います。これにより、アプリごとに1つのデータベースに分割できます。

私は100以上のテーブルを持つ1つのアプリに取り組んでいます。私はそれらを1つのデータベースに持っており、プレフィックスで区切られています-各テーブルには、それが属するモジュールのプレフィックスがあります。次に、このカスタムグループを使用するために、データベース関数の上にレイヤーを構築しました。また、このテーブルグループを利用して、データの編集を非常に簡単にするデータ管理者を構築しています。

于 2010-05-10T16:44:59.360 に答える
4

それは状況によって異なり、使用しているデータベースとフレームワークによってオプションが少し異なります。ある種のORMを使用することをお勧めします。そうすれば、それほど気にする必要はありません。とにかく、データベース内の独自のスキーマに各アプリを配置し、schemaname.tablenameで共有テーブルを参照するか、各アプリケーションスキーマにビューを作成して、SELECT * FROM schemaname.tablenameそのビューに対してコードを作成することができます。

于 2010-05-10T16:41:15.343 に答える
2

どちらかを選択するための厳格なルールはありません。

複数のデータベースがモジュール性を提供します。複数のデータベース間での同期に関する限り、リンクサーバーとそのビューの概念を使用でき、統合データベース（統合アクセス）の利点も得られます。

また、複数のデータベースを保持することで、セキュリティ、データ、バックアップと復元、レプリケーション、スケールアウトなどの管理を改善できます。

私の2セント。

于 2010-05-10T16:51:39.080 に答える
2

THatは、「多くのアプリケーション」のようには聞こえませんが、「実行可能ファイルが異なる1つのアプリケーションシステム」のように聞こえます。当然、1つのデータベースを共有できます。Schemataを賢く使用して、1つのデータベース内のさまざまな機能領域を分離します。

于 2010-05-10T17:50:17.240 に答える
1

私の意見では、すべてのアプリケーションに1つのデータベースがあります。データは、繰り返しがない場合に保存されます。

他のアプローチでは、複製することになり、複製を開始すると、それ自体が頭痛の種になり、データも同期しなくなると思います。

于 2010-05-10T16:44:03.810 に答える
1

データベースを分割し、すべての共有テーブルに1つの共通データベースを用意しました。それらはすべて保存SQLServerインスタンス上にあるため、複数のデータベース間でクエリを実行するコストには影響しませんでした。

レプリケーションの鍵は、サーバー全体が仮想マシン（VM）上にあることでした。したがって、レプリケーションでDev / Test環境を作成する場合、ITサポートはそのイメージのコピーを作成し、必要に応じて追加のコピーを復元します。

于 2010-05-12T07:44:39.587 に答える
1

私たちのビジネスでは、アプリケーションごとに個別のデータベースを使用し、少量の共有情報と時折リンクされたサーバーのクロスデータベース参照を使用しました。これは、開発、ステージング、ビルド、および本番環境で非常にうまく機能しました。

ユーザーの場合、ユーザーベース全体がWindowsにあります。Active Directoryを使用して、グループへのアプリケーション参照を使用してユーザーを管理します。これにより、アプリがユーザーを管理する必要がなくなります。これはすばらしいことです。グループ管理を一元化することはしませんでした。つまり、各アプリケーションにはグループとセキュリティのテーブルがありますが、これはあまり良くありませんが機能します。

アプリケーションが実際に異なる場合は、アプリケーションごとにデータベースを作成することをお勧めします。振り返ってみると、ユーザー向けの中央共有データベースも機能しているようです。

クロスデータベース参照整合性のためにトリガーを使用できます。

参照するデータベースを保持するサーバーへのリンクサーバーを作成します。次に、4つの部分からなる名前付けを使用して、参照データを保持するリモートデータベースのテーブルを参照します。次に、これをテーブルの挿入トリガーと更新トリガーに入れます。

例（単一行の挿入と更新を想定）：

DECLARE @ref (datatype appropriate to your field)

SELECT @ref = refField FROM inserted

IF NOT EXISTS (SELECT *
FROM referenceserver.refDB.dbo.refTable
WHERE refField = @ref)
BEGIN
RAISERROR(...)
ROLLBACK TRAN
END

複数行の挿入と更新を行うには、参照フィールドのテーブルを結合できますが、非常に遅くなる可能性があります。

于 2010-05-10T23:32:30.123 に答える
1

スケーラビリティとメンテナンスの観点から最も適切なアプローチは、「共有/共通」テーブルのサブセットを自給自足にして「共通」データベースに配置することです。他のすべての場合、論理スコープ（ビジネスロジック）ごとにアプリケーションごとに1つのデータベースがあります。決定）そしてこの構造を常に維持する

これにより、ソフトウェアのコミッショニング/デコミッショニング/再配置/メンテナンス手順の計画と実行が容易になります（どのアプリにアクセスするかがわかっている場合は、影響を受ける2つのDB（commons + app_specific）が関係していることが正確にわかります。その逆も同様です。

于 2010-05-10T16:52:54.290 に答える
1

この質問への答えは、非機能要件に完全に依存していると思います。いつか数百のノードにデプロイする必要があるアプリケーションを設計している場合は、必要に応じて水平方向に拡張できるようにデータベースを設計する必要があります。一方、このアプリケーションがユーザーでいっぱいの手で使用され、保存寿命が短い可能性がある場合は、アプローチが異なります。最近、EBAYのアーキテクチャがどのように設定されているかについてのポッドキャストを聴きました。http：//www.se-radio.net/podcast/2008-09/episode-109-ebay039s-architecture-principles-randy-shoup、およびアプリケーションストリームごとにデータベースがあり、シャーディングを使用してテーブルを物理ノード間で分割します。現在、彼らの非機能要件は、システムが24時間年中無休で利用可能であり、高速で、数千人のユーザーをサポートでき、重要なデータを失うことがないということです。EBAYは数百万ポンドを稼ぐので、これが開発と維持にかかる努力をサポートすることができます。

とにかく、これはあなたの質問に答えません:)私の人事意見は、あなたの非機能要件が文書化され、誰かによって承認されていることを確認することです。そうすれば、最適なアーキテクチャを決定できます。各アプリケーションで、独自のデータベースと共有データ用の中央データベースを使用したいと思うでしょう。そして、私はそれらの間の依存関係を最小限に抑えようとしますが、それは簡単ではないか、あなたがそれをしただろうと確信しています:)同期すると、頭痛の種になる可能性があります。

一日の終わりに、あなたはあなたのシステムを稼働させる必要があります、そして先のとがった髪の人はあなたのデザインがどれほどクールであるかについて猿に笑いを与えません。

于 2010-05-12T07:34:02.573 に答える