2017-03-16 3 views
-1

私のクライアントは、私にさまざまな製品の約14kのURLを与えてくれました。そして、私はその製品のすべての価格変更を1日に保存したいと思っています。 dbストレージと膨大な最適化が必要になると思います。私は以前これをやったことがない。私はmysql DBを使用しています。製品ごとにこれらの価格変更をすべてJSON列に保存するのか、別の行に保存するのですか?これに関するヒントを探しています。ありがとう!これらのデータをすべてdbに保存する最も良い方法は何ですか?

+1

最良のデータベース正規化の方法に従って保存してください。パフォーマンスが問題になった場合は、それを再設計します。しかし、ほとんどのデータベースは何千もの行を処理できますが、問題はありません。 – Barmar

+0

私はそれを各製品のjson列に保管することを考えています。これは大丈夫でしょうか? – user3407278

答えて

1

JSON列は、通常のSQL列と同じくらい効率的ではありません。どのデータを使用するか分からない場合に備えて予約する必要があります。どんなデータを持っているのかはかなりわかります。

これはかなり簡単な2つのテーブルスキーマです。製品のテーブルと価格の変更テーブル。

create table product (
    id integer primary key auto_increment, 
    name varchar, 
    url varchar unique, 
    ...any other information about the product you might want to store... 

    index(url) 
); 

プライマリキーを与えることで、URLの変更を防ぐことができ、それを参照するテーブルに格納する必要がある量を減らすことができます。 URL全体ではなく整数の主キーを格納するだけで済みます。検索の高速化のため、URLのインデックスが作成されます。

これで、他のテーブルで参照できる製品テーブルが作成されました。価格の変化の表のように。

create table product_price_changes (
    product_id integer references product(id), 
    price numeric(9,2) not null, 
    change_time datetime not null, 

    index(change_time) 
); 

この表には、製品の価格が変更された時期とその価格が格納されます。これは、SQLのものにデータのリストを添付する方法です。 change_timeは高速検索のために索引付けされています。

シンプルジョインを使用すると、特定の製品に対するすべての変更を効率的に表示できます。

select price, change_time 
from product_price_changes ppc 
join product prod on ppc.product_id = prod.id 
where prod.url = ? 
order by change_time 
+0

このようにしてDBサイズがgbsの100sを超えないでしょうか?そのような詳細な回答を書いていただきありがとうございます。 – user3407278

+0

@ user3407278どのように整理しても、データの総量は似ています。 – Barmar

+0

@ user3407278それはあなたが何をどのくらい保管しているかによって決まりますが、100GBは***多くの***データです。ストレージコストは、[変数タイプのストレージ要件](https://dev.mysql.com/doc/refman/5.7/en/storage-requirements.html)を参照してください。製品表は重要ではなく、変更に比べて製品が比較的少ない。各変更は、4(int)+ 4 + 1(数値(9,2))+ 8バイト(datetime)+ある程度のオーバーヘッドです。したがって、価格の変更につき20〜30バイトを話しています。インデックスに加えて非常に効率的です。 – Schwern

関連する問題