0

ユーザーからの登録からの共通データを格納した3つのテーブル（言語、国、国籍）を取得しました。各テーブルには、 idとnameのフィールドがあります。

ユーザーからのほとんどすべてのデータを格納するメインテーブルユーザーを取得しました。

この構造を持つtableregistryと呼ばれる別のテーブル：

id | tableName | tableValue

 1 | finalJoin | 0

 2 | language  | 1

 3 | country   | 2

 4 |nationality| 3

そして、それが保存するもう1つは、多くのユーザーを共有する共通データの一致と呼ばれます。

id | idUser | nTable | cValue

したがって、80人目のユーザーがオランダに住んでいて、彼がペルー出身で中国語を話す場合、データはこのように保存されます（オランダが国別テーブルにID 20を持っていることを考えると、ペルー国籍は国籍テーブルにID34を持っています。中国語は言語テーブルにID22があります）

198 | 80    | 2      | 20

199 | 80    | 3      | 34

200 | 80    | 1      | 22

したがって、人の検索を実行する場合は、ストアドプロシージャを使用して、ユーザーを取得するための3つの一時テーブルを取得するだけの共通データを検索します。1。特定の国から2.ネイティブではない国よりも任意の国に住んでいる3 。特定の言語を話します。

テーブルusersを使用してこれらの一時テーブルに対して複数の結合を実行すると、この検索のユーザーのリストが取得されます。

質問は。ビューを使用する方がよいでしょうか、それとも一時テーブル戦略を維持する方がよいでしょうか。

4

1 に答える 1

0

奇妙なスキーマがあります。これはどう：

CREATE TABLE users (
  id int(11) not null auto_increment,
  ...
);

CREATE TABLE languages (
  id int(11) not null auto_increment,
  name varchar(20) not null
);

CREATE TABLE countries (
  id int(11) not null auto_increment,
  name varchar(20) not null
);

CREATE TABLE nationalities (
  id int(11) not null auto_increment,
  name varchar(20) not null
);

CREATE TABLE user_rel_languages (
  user_id int(11) not null,
  language_id int(11) not null
);

CREATE TABLE user_rel_countries (
  user_id int(11) not null,
  country_id int(11) not null
);

CREATE TABLE user_rel_nationalities (
  user_id int(11) not null,
  nationality_id int(11) not null
);

usersしたがって、言語+国+国籍の特定の構成を持つユーザーを取得するには、リレーションテーブルを介してこれらの各テーブルから選択して結合します。例えば：

select u.* from users u
join user_rel_countries urc on urc.user_id = u.id 
join user_rel_languages url on url.user_id = u.id 
join user_rel_nationalities urn on urn.user_id = u.id 
where country_id = 1 and language_id = 2 and nationality_id = 3 
group by u.id ;

または、非正規化を気にしない場合は、との間の区別を落とすことができcountriesますuser_rel_countries

于 2013-02-16T00:58:19.670 に答える