To make story short, i’m building self-learning banner management system. Users will be able to insert these banners to their site when banners will be shown based on sales/impressions ratio.
I have 4 tables
Banners
bannerID int
bannerImage varchar....
SmartBanners
smartBannerID int
smartBannerArrayID int
bannerID int
impressionsCount int
visibility tinyint (percents)
SmartBannerArrays
smartBannerArrayID int
userID int
Statistics
bannerID int
saleAmountPerDay decimal...
Each night i need to generate new “visibility” for each SmartBanner based on whole SmartBannerArray that same user has. So i need to get sum of impressions and sales for each bannerID in SmartBannerArray.
All comes to my mind is to use double cursor, one will loop thought SmartBannerArrays get needed values for sum of impressions and sales and then inner loop which will access each SmartBanner and change it’s “visibility” percentage based on
(sales/impressions)/(sumOfSales/sumOfImpressions)*100
Hope you get the picture…
Is there any other way to design better tables or not to use double cursor to avoid server overload ?
MORE INFO
Each sale written to Statistics table , field is updated because i need daily sum per banner rather each sale. User create BannerArray, choose products he would like to promote. Each product he chose is written to Banners table with proper image and other info.
SmartBanners table stores bannerID so as Statistics table, while BannerArray table assigns this group of banners to certain user.
The picture is not so clear. Why cursors at all, what is wrong with this?
Which can be used then as subquery to calculate ‘visibility’ directly.
EDIT2:
Illustrating the principle (SQL not optimized), why not:
if you want to avoid the cursors.
Also, not to forget – if this data is not going to be updated often (what’s the frequency of the update of the statistics table? I imagine you update it periodically from some logs) AND if you are looking to maximize read performance you might consider triggers.
EDIT3:
In MS SQL you can also use OVER clause, just a short example
This SQL is not tested.