4

方法 1 :

CREATE TABLE `ads` (
  `idads` int(11) NOT NULL AUTO_INCREMENT,
  `idobject` int(11) NOT NULL,
  `ad_type` enum('SALE','RENT','NEWHOUSING','GBUY','LAND','FIXMOVE') DEFAULT 'SALE',
)

CREATE TABLE `house` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `uid` varchar(15) DEFAULT NULL,

「SALE」データを選択するには

SELECT * FROM ads a JOIN house h on (h.id = a.idobject) WHERE a.ad_type = 'SALE';

方法 2

CREATE TABLE `ads` (
  `idads` int(11) NOT NULL AUTO_INCREMENT,
  `uid` varchar(15),


CREATE TABLE `house` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `uid` varchar(15) DEFAULT NULL,

「SALE」データを選択するには:

 SELECT * FROM ads a JOIN house h on (a.uid=h.uid);

method2 の uid はすでに data_type の情報を持っています。

私はどちらがベストプラクティスなのか混乱しています:
Method1 の方が速いようですが、 ad_type = 'SALE'; を指定する必要があります。
Method2 はより単純なようで、uid で参加するだけでよいのですが、遅いようですか? 本当ですか？

どれがベストプラクティスですか? そして、どちらがより良いパフォーマンスですか? それとも全く違いますか？
PS。テーブル広告は、テーブル ハウス、テーブル ランド、テーブル ニューハウジングなどと結合されるため、正規化します。テーブル広告には、ads_start_date、ads_end_date、およびその他の有用な情報が格納されます。

4

2 に答える 2

1

adsこのような設計の問題にアプローチする最も有用な方法は、アプリケーションがすべて(販売、賃貸、土地など) をまとめて処理できる必要があるかどうかを検討することです。それを行う必要がある場合は、最初の選択肢が最良の選択です。

土地の広告、賃貸物件の広告などを独自のテーブルに配置する方が理にかなっている場合は、2 番目の選択肢が最適です。houseテーブルですでにそのようなことを行っているようです。しかし、それは私の推測です。

通常の自動インクリメント列で簡単に結合できるのに、uuid で結合するのはベスト プラクティスではありません。id完全に適切な一意のキーがある場合に、uuid を代理の一意のキーとして使用すると、'id余分な作業とストレージが発生します。

id 列 (主キー列) に統一した名前を付けるのがベスト プラクティスです。つまり、表と表で使用house.house_idします。そうすることで、SQL コードの読み取りと検査が容易になります。houseads.house_idads

于 2013-09-18T11:53:28.047 に答える
1

テーブルに自動インクリメントidがある場合は、それを主キーにすることを強くお勧めします。

CREATE TABLE `ads` (
  `idads` int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY,
------------------------------------------^
  `idobject` int(11) NOT NULL,
  `ad_type` enum('SALE','RENT','NEWHOUSING','GBUY','LAND','FIXMOVE') DEFAULT 'SALE',
);

原則として、私は最初の方法を好みます。ad_type自動インクリメントされた主キーには、埋め込みコードなどの追加情報はありません。2 番目の方法では、「uid」と呼ばれるもの (実際には「ユーザー ID」であるべきだと思います) は 2 つの目的を果たしています。一意のキーになろうとしており、型情報をエンコードしようとしています。

型情報を明示的な列にすることを強く好みます。

于 2013-09-18T11:54:54.697 に答える