電話、SIM カード、電話と SIM のペアリング、および電話と SIM のペアリングの履歴を保持するデータベースを設計しています。1 台の電話は、一度に 1 つの SIM カードにしかペアリングできません。
私の問題は、電話と SIM のペアリングを一意に識別する主キーを考えることです。現在、IMEI と ICCID の *comp(ound|osite) キーを取得していますが、これはユーザーが新しいエントリを追加しないことに依存しているため、1 つの電話と 1 つの SIM ルールが破られます。
検証を使用して、デバイスと SIM のペアリング テーブルにこのルールを適用できますが、これは悪い習慣でしょうか?
前もって感謝します。
*私は現在、複合キーと複合キーの違いを覚えるのに苦労しているので、これを言います.
同じテーブルでのペアリングの履歴が必要な場合。次に、ID主キーがその役割を果たします
結局、シムをphone1からphone2に移動してから、phone1に戻すことができました。
テーブルのキーを再入力すると別のユニバースに移動する可能性があるため、少しやんちゃです...pair_idが時間ディメンションで増加するという暗黙の仮定があります。テーブルへのCRUDアクセスで何かによって壊される可能性のあるもの。
datetime date_pairedを追加することもできますが、シムをすばやく交換した場合は...現在と履歴の2つのテーブルに適した時間だと思います。
私の問題は、電話と SIM のペアリングを一意に識別する主キーを考えることです。現在、IMEI と ICCID の *comp(ound|osite) キーを取得していますが、これはユーザーが新しいエントリを追加しないことに依存しているため、1 つの電話と 1 つの SIM ルールが破られます。
ええと、要件は 1 つの電話に対して 1 つの SIM であるとは言いませんでした。「一度に 1 つの電話を 1 つの SIM カードにしかペアリングできない」とおっしゃいました。(強調を追加しました。)
IMEI 列と ICCID 列のペアは、このテーブルの適切な候補キーのように思えます。(私はあなたの言葉を信じています。携帯電話や SIM カードについてはあまり詳しくありません。) そもそもユーザーがデータを入力できるようにする場合は、何らかのビジネス プロセスが必要です。おそらく、アプリケーション コードまたはSQL -- ルールが「1 つの電話/1 つの SIM」または「1 つの電話/1 つの SIM ずつ」であるかどうかに関係なく、更新を許可します。
なんで？これらの値を正しく入力するのは困難です。
実際の候補キーを配置した後に代理 ID 番号を追加しても問題はありません。実際の候補キーを配置せずに代理 ID 番号を追加するのは、多くの間違いがあります。