4

私が尋ねる理由は、MySQL が現在サポートしていない特定の CHECK 制約を使用したいからです。この種の制約が適切に設定されていないと、アプリケーション コードがデータベースの責任をより多く引き受けるため、外部キーと参照整合性を使用する理由全体が減少するように見えます。

「ダム」データ モデルを作成し、すべての参照整合性チェックをアプリケーション コードのレイヤーに移動すると、参照整合性エラーがデータベースではなくアプリケーションでトラップされるため、テストがより簡単になる可能性があります。また、新しいモジュールの開発がスピードアップする可能性もあります。テストの前に、必ずしも参照的に完全である必要がないためです (用語ですか?)。

では、MySQL で「適切な」データ モデルに固執し、外部キーや「ON UPDATE CASCADE」ステートメントなどを保持することには、他に何か利点がありますか?

それとも、MySQL を捨てて別のものに移行するべきでしょうか?!

ありがとう！

4

3 に答える 3

2

他の方法でチェック制約をエミュレートできます

  • 引き金
  • 単一行テーブルへの FK
  • 単一値の列挙

不便ですが、世界の終わりではありません。

とにかく、すべての制約をアプリケーションで実行できるわけではありません。独自性？ゼロサム チェック (例: アカウントが無効になる前に残高 = ゼロ)。

問題が発生したときにクリーンアップするのはあなたのデータとあなたの混乱です...

于 2012-01-16T20:58:43.423 に答える