Reputation: 18465
Could you help me to understand what is the best solution between unique complex SQL request and several simple SQL request with merging in my code?
Let say I work on a job offer website. A job offer is composed by competencies. Each competence is listed in a area of interest. For instance a competence may be C# and his area of interest is IT. An announcer can create a new job offer and choose C# as required competence for the job.
On the other side a user choose on, two, three or more area of interest. Yes our user doesn't choose their competences but they area of interest. Lest say My user xxx choose three area of interest.
On his home page I would like to display the list of new job offer of these 3 area of interst order by date. What should I do in my code.
A unique complex SQL request with join on job offer on competence and area of interest and area of interest of my user and my user table with a WHERE clause on my user
A more simple SQL request that a call 3 times to get 3 list of job offer with join on job offer on competence and area of interest with WHERE clause on my area of interest and after that I merge my three lists in my code.
What if i need to order my list on the job offer date but highlight or prioritize the job offers that may be in several area of interest.
EDIT
I have a database requirement : I need to works with stored procedure only
Upvotes: 0
Views: 70
Reputation: 1353
One complex query is just much better in 99% of all cases.
However, if you need to process the data very often and don't need the newest data all the time, you can of course reimplement the database logic in your code and achieve a better performance. But that will only work if you use the data very often, and if you can ignore any changes during that time. And remember, it is quite much work to implement all that join logic with proper indexing and optimization. I would suggest that it's just not worth the effort.
Upvotes: 1