インベントリが必要なさまざまな物理オブジェクトがあり、各タイプのオブジェクトには独自のテーブルがあります。 2つのオブジェクトの例として、インベントリするさまざまな剣を含むテーブルに「swords」を使用し、さまざまなバターに「butters」を使用しましょう。明らかに、これら2つのオブジェクトは、両方ともインベントリで説明する必要があるという事実以外の属性に関しては、実質的に共通点はありません。これが、それぞれが独自のテーブルを持つ理由です。
インベントリされたすべてのオブジェクトに、一意の整数IDを割り当てる必要があります。したがって、在庫番号「5」は剣であり、「6」はバターである可能性があります。
必要なのは、在庫番号 'inv_nums'を追跡するだけの別のテーブルだと思います。次に、「swords」テーブルと「butters」テーブルのそれぞれでそのテーブルを参照する外部キー制約があります。オブジェクトテーブルと「inv_nums」テーブルの間の関係は1:1になります。
在庫番号が不注意またはその他の方法で複数のオブジェクトテーブルによって使用されないことを保証するにはどうすればよいですか?
関数またはプロシージャ(どちらかわからない)を呼び出す挿入でトリガーを使用して、次の連続した在庫番号を作成して返すか、挿入ステートメントで提供されているものがまだ存在しないことを確認する必要があると思います使用します(「inv_num」テーブルにはまだ存在していません)。
私は正しい方向に進んでいますか?これにはどこかにデザインパターンがあるはずですが、私のグーグルは今のところあまり成功していません。私は確かにこれらすべてをアプリケーション層で行うことができましたが、むしろDB自体に適用したいと思います。
私はこれをMySQL/MariaDBに実装していますが、この背後にある概念は(リレーショナル)DBに関係なく同じである必要があると思います。
First _AUTO_INCREMENT
_ _PRIMARY KEY
_を含む「オブジェクト」のテーブルに行を挿入します。 LAST_INSERT_ID()
を使用してIDを取得します。
Then必要な行を他のテーブルに挿入します。最初のステップのIDを一意のIDとして使用します。
これはMySQLとMariaDBで機能します。他のデータベースには、SEQUENCE
の概念があります。これは、MySQL/MariaDBで、基本的に私が提供した「最初の」ステップを使用してシミュレートできます。したがって、本当にある程度dbに依存しない必要がある場合は、SEQUENCE
エミュレーションから始めてください。
(私の意見:RDBMSベンダー間には非常に多くの違いがあるため、すべてに対して1つのコードを使用しようとするのは愚かです。)