仕事を検索する人がいて、仕事のリストがあるとしましょう。だから私は2つのテーブルを持っています：人と仕事。今、私はその人のスキルのリストを持っています、そして私は仕事の要件のためのスキルのリストを持っています。
このようなスキルテーブルを1つ持つ方がよいのは次のとおりです。
CREATE TABLE skills_reference
(
id INT,
reference_id INT, -- can reference people(id) or job(id)
reference ENUM('person','job'),
skill FOREIGN KEY REFERENCE skills(id)
)
または、2つのテーブルを用意します。1つはpeople_skills用で、もう1つはjobs_skills用です。どちらがより良いパフォーマンス結果をもたらしますか？
ありがとう。
IMO、2つのテーブルを作成する必要があります。1つは用job_skill(job_id, skill_id)、もう1つは用person_skills(person_id,skill_id)です。ただし、どちらも同じスキルテーブルを指しています。
パフォーマンスは1つの考慮事項にすぎないことを指摘しておきます。多くの場合、最初にデータモデルの論理的なサウンドデザインに焦点を当て、次にパフォーマンスに焦点を当てる必要があります（問題がある場合）。
RDBMSが機能する場合、多くの場合（80％）、最もクリーンな設計がパフォーマンスにも最適です。
これを設計する場合、定義されたスキルの世界を含むマスタースキルテーブルがあると思います。次に、JobSkillsテーブルとPeopleSkillsテーブルがあります。どちらにも、マスタースキルテーブルへのFK参照があります。
パフォーマンスの結果は、使用法によって異なります。人々は主に、人のスキルだけを検索するのでしょうか、それとも仕事のスキルだけを検索するのでしょうか、それともスキルが仕事に一致する人を検索するのでしょうか。データが頻繁に更新されると思いますか？データに許容できる「鮮度」とは何ですか（つまり、変更を検索に反映するまでの時間）。Oracle、MSSQL、MySQLなどを使用しているシステムは何ですか？
何にでも適用できるパフォーマンスの普遍的なルールはほとんどありません。プログラミングはそれほど考え抜かれたものではありません。
個人的には2つのテーブルを使用people_skillsしjob_skillsます。そのように考えて、それらに対して結合を書く方が簡単だと思います。
よろしく
K
PS 2つのテーブルが巨大になった場合は、いつでもそれらを別々のディスクに移動して、重いクエリを実行するときのioの競合を減らすことができます。