私の質問は、MySQL データベースの参照整合性の概念に関するものです。DBA からの何らかの制限により、MySQL の参照整合性機能を使用することは許可されていません。私の質問は、「MySQL に参照整合性機能がない場合、MySQL に外部キーの概念をどのように実装できますか?」ということです。
ありがとう。
私の質問は、MySQL データベースの参照整合性の概念に関するものです。DBA からの何らかの制限により、MySQL の参照整合性機能を使用することは許可されていません。私の質問は、「MySQL に参照整合性機能がない場合、MySQL に外部キーの概念をどのように実装できますか?」ということです。
ありがとう。
MyISAMテーブルを使用していると思いますか?あなたは自分でチェックをすることにかなり行き詰まっています。
したがって、tableBがtableAに依存している場合は、tableAから削除する前に、まずtableBから削除する(または他の更新を実行する)必要があります。挿入を使用すると、メインテーブルにレコードを作成してから、依存テーブルにレコードを作成します。
これは面倒で、MyISAMテーブルを保持するために私が見つけた唯一の理由はFULLTEXTインデックス作成でした。私があなたのデータベースの制限についてもっと知っていれば、私はおそらく他の提案をすることができます。
ETA:
彼があなたにInnoDBテーブルの使用を制限しているのなら、あなたのDBAについて疑問に思うでしょう。いずれにせよ、セキュリティ上の理由からInnodbテーブルの作成と使用を許可しない場合、ストアドプロシージャまたはトリガーの使用を許可する可能性はほとんどありません。そのため、基本的に、 CRUD操作をスクリプト言語で実行するアプリケーションの作成に行き詰まります。
したがって、特定のケースごとに、これらの操作に対する制限を考慮する必要があります。おそらく最も簡単な方法は、参照整合性を強制するかのようにデータベーススキーマをマップすることです。テーブルの変更によってアクションが発生する可能性がある場合は、その詳細を含めます。操作後遺症オプションは、RESTRICT、SET NULL、およびCASCADEです。
データベースがどのように応答するかがわかったら、それに応じてクエリをプログラムできます。
したがって、従業員に住所があり、従業員が削除されると住所が表示されなくなる場合は、次のようになります。
Innodbバージョン(Addressesには従業員の外部キーとON DELETE CASCADE
アクションがあります)
DELETE FROM Employees WHERE employee_id=7;
MyISAMバージョン:
DELETE FROM Employees WHERE employee_id=7;
DELETE FROM Addresses WHERE employee_id=7;
これにより、状況が少し明確になることを願っています。
これが意味することは、すべての開発者は、存在する必要があるリレーションシップを具体的に知っている必要があり、挿入または更新を行うときは親テーブルからすべての子テーブルまで作業し、削除を行うときは子テーブルから親テーブルまで作業する必要があるということです。もちろん問題は、すべての開発者が、制約に関係するすべてのテーブルが設定されていないことに気付いているわけではないということです。また、関係のレイヤーがある場合は、チェーンの一番下まで削除を行う必要があります。
ORM を使用する場合、そこで関係を定義できると思いますか? 一度も使用したことがないかどうかはわかりませんが、使用できると思います。とにかく調べる価値があります。
ORM を使用しておらず、参照整合性を定義できない場合は、少なくとも関係をどこかにテーブルに保存して、開発者が影響を受けるテーブルを検索できるようにします。
参照整合性を具体的に定義できない場合の別のアプローチは、トリガーを介してそれを強制することです。
トリガーを拡張するために編集: 親テーブルでトリガーの代わりにトリガーを作成する場合 (これらは私の SQL で使用できますか?)、実際の削除を行う前に削除するテーブルを指定することにより、カスケード削除の動作を模倣できます (この方法カスケード削除を行う前に、昔はそれを行っていました)。更新で主キーが変更された場合に更新するテーブルを指定することもできます (変更されないキーがデザインに含まれていることを願っていますが、自然キーを使用した場合はそうではありません)。子テーブルの挿入トリガーは、キー フィールドの値が親テーブルに存在するかどうかを確認し、存在しない場合は拒否します。
以前は myIsam テーブルを使用していました。
したがって、これは手動で作業を行う必要があることを意味します。たとえば、親行を削除する前に、いくつかの SELECT を実行する必要があります。
それは可能ですが、参照整合性がなければ同じではありません。しかし、動作します。
「選択」を容易にするためにストアドプロシージャを使用する場合があります。もう 1 つの適切なアプローチは、データベース スキーマをモデルの背後に隠し、そのインターフェイスを介して使用することです。
この文脈で DBA からよく耳にする 1 つの議論は、「RI を使用すると、再編成のためのアンロード/ロードが難しくなる」というものです。
もちろん、それ自体は真実ですが、悪役は、通常、「難しい」という言葉は、「DBA が仕事をするのがほぼ不可能になるほど難しい」という意味であると示唆されているということです。
そして、それは雄牛です。