Hi, I am new to NopCommerce and I am starting to get used to it, so sorry if this question sounds stupid.
I want to crate a ranking system for a different kind of search I am creating. This rank system would consider the number of sales of a given product and the total number of sales of all products in my store to generate a score to be used in the search.
I was thinking to calculate this score on the fly, and do not store it in a DB or something like that: if a user searches for a given product, I would calculate the score for the products that match the criteria he chose, this way I would have the most actual score. For that, I would have 3 questions: 1- Is there any place where the total sales are stored or should I retrieve it from the order variant table? 2- Is there any place where the total sales for a product/product variant are stored or should I retrieve from the orderVariantTable? 3- Is there any way to store the information about total sales somewhere that can be accesses by all requests? Like a cache system or something? (It would be ok to have this value cached for 3 seconds).
I was also thinking about creating a DB view that would contain the product ID, the total sales, the product sales and the generated score. But I think this would require a a lot of processing because each time a product is sold, this view would have to be update (the score for each product would change).
What do you think of this approach? Which one would you use?
Interesting thing, but I wouldn't implement quite none of these. I would hook up to the Events of nop (IEntityInserted<> and IEntityUpdated<>) for the entities of your interests to store the relevant data in a simple-to-query structure (where to store them is only a matter of choice).
Then i would have a background job processing those data and generating results, the front end would retrieve the results and display them as you wish.
Doing it "really" realtime (on the fly) would potentially be painfully slow and difficult to scale. But you can have the background job process them as often as he can.
You can skip the first part and have the bgjob process directly from the nop data structure, at two costs: the actual job processing slower, and putting more stress on the nop db.
Anyways, all depends on the "heavyness" of the computation you have to do on those data, and obviously the amount of data.
Thanks for the reply, let me see if i understood your idea: You are saying that already exists the IEntityUpdated<> and IEntityInserted<> events? I couldn't find anything about it on the documentation (I do not have the source code at the moment). I will check it later to figure out the difference between them.
In this event you would populate a structure and insert this information in the database. You would also create a background task to perform the calculations and store it somewhere in the DB. Then you would retrieve this information when needed, right?
Did I get it right?
This looks a better solution than my proposals, I will check how it goes tonight :)