私は自分のプロジェクトのデータベースを設計していますが、プロジェクトにはさまざまな種類のオブジェクトがあります。すべてのオブジェクトにコメントが含まれている可能性があります。これは、同じコメントテーブルから取得されます。
2つの異なる種類のオブジェクトが同じIDを持っていて、コメントテーブルからプルすると、お互いにコメントをプルするときに問題が発生する可能性があることに気付きました。列を追加するだけで解決できobject_typeますが、クエリなどで維持するのが難しくなります。
データベース全体で一意の行IDを使用するための最良のアプローチは何ですか？
Facebookがオブジェクトに非常に大きな数のIDで番号を付けていることに気づきました。おそらく、そのタイプをid mod trillion他の非常に大きな数で判別します。それはうまくいくかもしれませんが、同じことを達成するためのオプションは他にありますか、または十分に大きな数の範囲に依存することは問題ありませんか？
ありがとう！
Twitterが一意のIDに使用するようなものを使用できます。
http://engineering.twitter.com/2010/06/announcing-snowflake.html
ただし、作成するすべてのオブジェクトについて、このサービスに対して何らかのAPI呼び出しを行う必要があります。
object_typeid列に統合してコンセプトを微調整してみませんか？たとえば、IDは、オブジェクトタイプ、セパレータ、および列内の一意のIDを連結したものになります。
データベース全体の一意のIDジェネレーターがパフォーマンスのボトルネックにつながる可能性があるため、このアプローチはより適切に拡張できる可能性があります。
データベースインスタンスが1つしかない場合は、新しいテーブルを作成してIDを割り当てることができます。
CREATE TABLE id_gen (
id BIGINT PRIMARY KEY AUTO_INCREMENT NOT NULL
);
これで、新しい一意のIDを簡単に生成し、それらを使用して行を保存できます。
INSERT INTO id_gen () VALUES ();
INSERT INTO foo (id, x) VALUES (LAST_INSERT_ID(), 42);
もちろん、これをシャーディングしなければならない瞬間、あなたは少し困っています。このテーブルを管理する単一のデータベースインスタンスを確保することもできますが、すべての書き込みで単一障害点が発生し、重大なI / Oボトルネックが発生します（地理的に異なるデータセンターを処理する必要がある場合にのみ悪化します）。
Instagramには、 ID生成スキームに関するすばらしいブログ投稿があります。これは、PostgreSQLの素晴らしさと、特定のアプリケーションに関する知識を活用して、シャード全体で一意のIDを生成します。
もう1つのアプローチは、衝突を示す可能性が非常に低いUUIDを使用することです。いくつかのトレードオフを伴いながら、「無料」でグローバルな独自性を得ることができます。
さらに別のアプローチ（前述）は、SnowflakeなどのスケーラブルなID生成サービスを使用することです。（もちろん、これには、前述のサービスのインストール、統合、および保守が含まれます。これを実行する可能性は、プロジェクト固有のものです。）
テーブルをオブジェクトクラスとして、行をオブジェクトとして、列をオブジェクトパラメータとして使用しています。すべてはクラスtechnameで始まります。このクラスでは、すべてのオブジェクトに、データベース内で一意の一意の識別子があります。オブジェクトクラスはテーブルオブジェクトクラスにオブジェクトとして登録され、各オブジェクトクラスのパラメータはそれにリンクされています。