Question

We are developing advertisement scheduling system. Now, we want to calculate prize details for that. Right now, database is like, we have 2 tables city and daypart. city contains 30+ million records, and daypart contains 6 records like 6am to 10pm.etc. Now we want to calculate prize for advertisement. i.e if any user has given advertise to Mumbai city for 3 dayparts then how to calculate prize for that. One way is that create one more table and in that kept all the combinations of city and daypart and its prize. but then this table contains 60+ millions records, and if new daypart is added then we have to update this table again which is more problematic.
ex. city contains 1 record and daypart contains 6 records, then new table contains total 6 records and its prize.
is there any other way to calculate prize for above scenario?

Answer 1

As you’ve mentioned, prize amounts can differ based on city or daypart, and it doesn’t sound like there’s any standard algorithm or calculation to calculate a prize based on city and daypart (prize amount seems proprietary information to your system) – so some sort of lookup table would probably be your best bet.

I’d imagine your table columns would look something like this:

Countries: id (integer, non-null), countryName
Cities:    id (integer, non-null), cityName,   countryId
Prizes:    cityId, startHour, amountPerHour

Some notes:

• City and Country are split into multiple tables based on your information of 30+ million city records.

• Rather than store ‘dayparts’ as a time range (3pm-6pm), store it in the lookup table as a price per hour that starts at a specific time. For example:

  • If CityA (id=1) costs $15 for 6am-9am, and $30 for 9am-12pm, (and 0 otherwise, for simplicity) then this table would contain these entries:

    cityId    startHour    amountPerHour
     1         0            0
     1         6            5
     1         9            10
     1         12           0
    

  • This gives you the flexibility to easily add new dayparts (one of your concerns), or even have different dayparts per city. StartHour would represent the startHour within the day (0-23), and could even be a decimal value if necessary (12.5 for 12:30pm).
  • Calculation for a time range just becomes a matter of figuring out how many startHours are within your range, then doing some basic math with amountPerHour.

If this doesn’t meet your needs, another alternative (as you mentioned) is just a straight-up lookup table, in which case you’d have a table of dayparts, and prizes table would become cityId | daypartId | amount.

The size of your tables isn’t that bad if you’re worried about performance – especially if you properly use your primary key columns and have table indexes.