Jump to content

Recommended Posts

Hey all, I was just advised to use MySQL as a database for the following info, but I'm new to it and I'm not sure how I can use it to store multiple entries for a field in a single record.

 

I'm trying to keep a record of prices of some items, and want to include for each item:

 

EAN (like UPC), maybe ID (could use EAN for it), product name, genre, maybe a few other things

Date (probably weekly), price (for that week).

date, price

date, price

etc etc.

 

So for each product, I'll be continually adding new dates and prices, and need to keep the previous date and price data stored, but I can't find any info on how to do that as all the basic examples I've found just include a single entry for each field, and I know I shouldn't be continually adding new fields. And using a new table just to store date and price data for each product sounds crazy (I'd have 1000s of tables). Any tips? Thanks

 

EDIT: 1 database for products, then another for dates + prices, which for each entry includes a link to the product (by ID / EAN)? That's gonna be a lot of unrelated data in one table... I could create multiple ones for each genre of product, but still a lot of data in each table.

Link to comment
https://forums.phpfreaks.com/topic/155007-how-to-store-historical-data/
Share on other sites

And using a new table just to store date and price data for each product sounds crazy (I'd have 1000s of tables). Any tips? Thanks.

 

Two (2) tables will be enough for that.

 

One to store some 'constant' data. Second to store price + date.

Is that gonna be ok for say around 10,000 products, and maybe date and price info every day, for over say 10 years? that's... erm.... around 36,500,000 entries for date and price in one table? And if it went to 50 years and 100,000 producs.... That's not gonna slow things down, or cause any redundancy issues?

No more than having separate table for each product (each table means another file on the disk that has to be opened, loaded into memory, scanned, etc.). Databases work well on 'long' and 'thin' datasets. And redundancy? That's exactly how you avoid it :)

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.