外部キー/カスケード削除が悪い場合、なぜその機能を備えたデータベースサーバーを使用するのですか？
Wordpress/Railsなどで外部キー制約が使用されていない、またはデータベースから機能がカスケード削除されていることに気付きました。代わりに、PHP/Ruby /スクリプトレベルでこれを処理します！
this と this を読みました。外部キー制約に対するほとんどの議論は、パフォーマンス、マルチスレッド、ロック、スケーラビリティなどについて語っています。
外部キーに対する引数が有効であると仮定すると、私の質問は次のとおりです。
- 外部キーが悪い場合、WordPress/Railsなどが外部キーをサポートするsql-serverを使用するのはなぜですか？ MySQLからNoSQLの種類のサーバーに移行するメリットはありますか？
- 一方、アプリケーションは、問題に遭遇することなく外部キー機能を利用する方法でコーディングできますか？
- アプリケーション/スクリプトレイヤーでの「リレーション」の格納と管理にのみデータベースを使用している場合、noSQL/redisはより良いですか
最初のリンクから始めましょう。それははっきり言っています：
参照整合性を備えた大規模なデータベースで作業すると、うまく機能しません。
そして、そうです。 「大規模なデータベース」がテラバイトサイズであり、テーブルに数十億行あるという手がかりがない可能性があります。単純な選択が何億もの関連要素にカスケードされて削除される可能性があり、パフォーマンスの問題が発生します。
これは、wordpressログまたはほとんどのCMSなどの通常の小さなデータベースでは問題ではありません。facebookのようなことをしたり、財務シミュレーションデータを処理したりすると、問題になります。 xのバッチでのトランザクション以外のストアドプロシージャで機能する数十億行のテーブルと削除-削除の終了により、数億行が簡単にクリーンアップされる可能性があるため。
MySQLからNoSQLの種類のサーバーに移行するメリットはありますか？
ほとんどありません。プロが適切にそれらを使用するとき、それらは役に立ちます。
一方、アプリケーションは、問題に遭遇することなく外部キー機能を利用する方法でコーディングできますか？
はい。
アプリケーション/スクリプトレイヤーでの「リレーション」の格納と管理にのみデータベースを使用している場合、noSQL/redisの方が優れていますか？
私はかつて、（パフォーマンスを向上させるために）参照整合性を使用しない銀行のテクノロジーアップグレードのアプリケーションレビューを行いました。 SQL Server（古いAdabasインストールを置き換えることになっている）にデータをロードすると、整合性制約違反により失敗しました。一部の*が使用されていないルックアップテーブルの値を削除したため、履歴レコードの40％が無効になりました（すべてのアクティブな顧客ではなく、古い顧客分類コードに置き換えられた古い顧客分類コードなど） ）。参照整合性に関する警告は出されませんでした。その結果、一部の解雇された人々と回避策で立ち往生した問題と、上に部分的に役に立たないデータウェアハウスの構築がありました。
アプリケーション/スクリプトレイヤーで関係を管理することはこれで終わりです。エラーが発生します。データは価値があり、アプリケーションは変化します。
SQLレベルの機能について不平を言うほとんどの人は、不平を言うのではなく、それらについての本を読んで理解することをお勧めします。残念なことに、インターネット上の多くのアドバイスは、ドキュメントさえも読むことを拒否する人々によって書かれています。常に注意してください。 NoSqlへのほとんどのアドバイスは、無知に強く基づいています。