SQL Server内のNoSQL

この質問は、SQLとNoSQLの違いに関するものではありません。私は現時点では本当に理にかなっていない何かの理由を探しています（おそらく私の理解や感謝の欠如のため）。

MVC5、Entity Framework 6コード、SQL Server 2008を使用してゼロから新しいプロジェクトを開始しました。アプリケーションコードのビジネスレイヤー内で適用する必要があります。

私の意見では、外部キーはデータ/参照整合性の一部を形成し、実際にはビジネスロジックを模倣していません。ビジネスロジックは、参照を適用する対象/タイミング/方法/理由を制御するプロセスと検証に過ぎません。一意の制約はほぼ間違いなくビジネスプロセスであることを理解できますが、私にとってこれはロジックを補完するだけで、整合性の一部を形成します。

2番目の引数は、データにNoSQLアプローチを採用することです。SQL-Server 2008の使用、レポートの必要性、テラバイトにスケーリングされないデータ、Mongo、Ravenなどのテクノロジーに対する考慮の欠如を考慮すると、これは非常に珍しくて非正統的であることがわかりました。

以前にそのようなシナリオに出くわした人はいますか？なぜ参照データ用に設計されたSQL ServerでNoSQLアプローチを採用し、外部キーを必要としないのですか？

データベーススキーマを確認したとき、これはビジネスロジックであり、ビジネスレイヤー内で適用する必要があるため、すべての外部キーおよびその他の制約を削除する必要があると述べました。

それから彼はばかです、そして、あなたのコードベースからの若干の抜粋はいつかThe Daily WTFで終わるでしょう。彼のアプローチが意味をなさないこと、そして率直に言って彼の説明も意味がないことは絶対に正しい。

参照整合性制約は「ビジネスロジック」ではないことを彼に説明してみてください。独自の検証機能を備えた正確性基準です。 ビジネスロジックは、データをどのように処理するかに関するものです。整合性とは、データ自体が破損しないようにすることです。それがうまくいかない場合は...まあ、彼が担当しています。あなたは彼の計画に沿って進み、損害をいくらか軽減しようとするか、より良い職場を探し始めることができます。（または両方。）

外部キーを作成する理由はまだありません

- ジョエル・スポルスキー

包括的な記述はさておき、一意性または外部キー制約を使用しないことを選択した正当かつ強力な理由があることを認める価値があります。ほとんどは次のようになります：

• パフォーマンス。アトミックトランザクションで整合性チェックを行うことは無料ではありません。また、多くの場合、データベースは拡張が困難なアーキテクチャの一部です。おそらく、アプリケーションロジックで既にチェックを行っており、2番目のパフォーマンスヒットを負わせないでしょう。
• 必要性の欠如。おそらくあなたのデータが汚れていて、それでいいのです。これはあなたが何をしているかに大きく依存します。

参照してください。外部キーが悪いのか？

しかし、それらはあなたの質問の理由と一致しません。

これはビジネスロジックであり、ビジネスレイヤー内で適用する必要があります。

この理由は少し奇妙です。一意性およびその他の整合性の制約は、ACIDデータベースの領域です。アプリケーションコードは、SQLServerの原子性と整合性の保証に近づくことができません。強力なデータ整合性が必要な場合、データベースを無視するのは愚かなことです。

2番目の議論は、彼らがデータストレージにNoSQLアプローチを採用したいので、そのような制限を実施したくないということです。

2番目の理由は、実際には理由ではありません。それは結論です。ただし、制約は正確さとパフォーマンスの間のトレードオフであり、NoSQLデータベースは後者に偏っていることは事実です。

おそらく、システムアーキテクトはこれらの正当な理由を念頭に置いており、あなたは聞いたことがないでしょう。または多分彼はとんでもない馬鹿です。

いずれにせよ、一意性と外部キー制約の使用を控える有効な（普遍的ではないが）理由があります。

PS外部キーが必要ないと判断した場合でも、リレーショナルデータベースを使用しても大丈夫です。一般化として、リレーショナルデータベースは、NoSQLの対応データベースよりも成熟しています。単一のノードとして、それらはさらに高速であり、それらの上に NoSQL抽象化を構築できます。