Mysql VIEWS vs. PHP query
I am working on a web application which involves create list of Restaurants in various lists like "Joe's must visit places". Now for each Restaurant and list, I have display on website which calculates
- Calculating popularity of a Restaurant
- Popularity of a list
- Number of lists a Restaurant is present in
Currently I am using MySQL statements in PHP for this but planning to switch to MySQL VIEWS and do a simple select statement in PHP...
my question is, What is Advantage/Disadvantage of using VIEWS over writing sql queries in PHP?
Using views adds a level of abstraction : you may later change the structure of your tables, and you will not have to change the code that displays the information about the lists, because you will still be querying the view (the view definition may change, though).
The main difference is that views are updated after each insertion, such that the data is "ready" whenever you query the view, whereas using your custom query will have MySQL compute everything each time (there is some caching, of course).
The bottom line is that if your lists are updated less frenquently than they are viewed, you will see some gains in performance in using views.
My complete answer would depend upon several things (from your application's perspective):
- do you plan to allow users to create and share such lists?
- can users create lists of any kind, or just by plugging values into existing query templates?
Assuming you have a couple of pre-defined lists to display:
Use of views offers a couple of advantages:
- your code will be cleaner
- the query to generate the views will not have to be parsed each time by mysql.
I'm not sure about this: I don't think mysql caches views as Tomasz suggests - I don't think views contain "already preparted data".
One disadvantage is that the logic involved in creating the list goes into the database instead of living in your PHP code - something I'm very averse to. In my world databases are for data, and code is for logic.
The original question was about pros and cons, but not seeing much about disadvantages in the answers so far.
Isn't one disadvantage of views that they can give you the false comfort of running a simple query? For instance, SELECT username FROM myview WHERE id='1' That looks simple, but what if "myview" is a really complex SELECT... Perhaps even built on other views? You end up having a simple-looking query that, in the background, takes a whole lot more work than if you had written your query from the ground up.
I've been experimenting with views, and despite the benefits, have not yet been fully sold. I'd be interested in hearing what others perceive about the disadvantages of Views, rather than just the party line about why views are so great. Might still make the switch, but would like to understand more about performance.
If that tables you are trying to make view from are not subject to a frequent change, definitely you gain performance, as you are only doing simple select from already prepared data. But be aware of the fact, that view is not something that is made "once and forever" - every change of a content of one of the tables will make database engine do "view refreshing", so another query (query you are making view from) must be called to taki into account changes that were made. To sum up:
Infrequent changes? Performance. Frequent / constant changes (community adding, commenting, rating your restaurants) - better go with SQL queries.
In my opinion databases are used for data layer and it is not that proper to put business code inside them. It both reduces maintainability and it contradicts clean separation of layers. The same applies to including business code and calculations in java scripts of web pages. For java script it is even more serious since it creates security threats. Source control for the code inside database is also another issue.
Now that code is inside database, the security and access complications (to views and stored procedures) is also added.
Migrating an application from one database engine to another will be much more difficult (since in addition to simple queries the stored procedures/views etc. are possibly different too). If the database is only about data then an abstraction layer could allow changing the database engine (at least on at some extent).
Slight performance gains (since data is not coming out of the database for processing, it is processed right inside the database).
Code will seem cleaner (since the dirtiness is hidden inside the database views, stored procedures etc.).