与えられたオブジェクトがN個以下の子オブジェクトを持つことができるビジネスレベルの制約があるとします。子オブジェクトを作成する場合は、そのオブジェクトに対してN個以上の子オブジェクトを作成しないようにするにはどうすればよいでしょうか？RDBMSにおける複数行のテーブル制約
READを実行して既存の子オブジェクトの数を取得する場合は、Nより小さいかどうかを検証してから、テーブルにINSERTを実行します。別のINSERTが取得できるREADとINSERTの間に時間があります。
これは、他のクエリに悪影響を与える可能性があるため、テーブルをロックしたくない場合です。
さらに具体的な例は、常駐オブジェクトとホームオブジェクトがある場合です。 Residentテーブルには、id、resident_name、home_idのようなものがあります。 4人以下の住人が同じhome_idを持っていることをどうやって確認しますか？
リレーショナルDBの制約は、ビジネスルールを実装するためのものではなく、技術的なレベルでのデータの完全性を保護するように設計されており、多くの現代の開発者はDBをまったく気に入らず、シンプルな永続性メカニズムしかし、あるデータベースでは、格納されているprocsとトリガーを使用して、あなたが望むものを達成することができます。
このルールに違反しないようにするには、DBがデータベースにアクセスする唯一の方法であるサービスのプライベートデータストアになっていなければなりません。 。このサービスは、このルールと他のビジネスルールを明確かつ一貫した方法で実装できます。
私はアプリケーションコードでそれをやっても大丈夫です！私はアプリケーションコードでそれを検証し、データの整合性を保証する方法を見ていきたいと考えています。 – thait84
私はテーブルをロックせずにDBレベルでどのように可能かはわかりません。アプリケーションレベルでさえ、並行性に問題があります。 –
私が考えていたことは、Residentテーブルのデータを変更する要求が、ホームテーブル内の特定のHomeのロックを取得する必要があるということでした。その後、指定されたホームの居住者のデータを読み込み/検証/変更することができ、誰もあなたの下にあるデータを変更していることを保証することはできません。これにより、他の家庭の居住者が読書や修正をしている他の人に悪影響を及ぼすのを防ぐことができます。 – thait84
プログラムのロジックではなく、SQLでない –
あなたがアプリケーションでそれを行う場合、あなたはどんな種類のロック機構を持っていますか？ 2番目の段落でそれを呼び出しました。READ、VALIDATE、INSERTを実行すると、別のINSERTが中間に入ります。パフォーマンスが悪いテーブル全体をロックしない限り。 – thait84