views:

67

answers:

1

I'm working on building a MySQL database and I'm thinking that rather than encode a bunch of complex join queries in the front end I'll create a view for any queries I need and then have all the front end code do simple SELECT whatever FROM some_view WHERE something=5; queries.

It seems like a great idea as it abstracts away the underlying schema so the front end doesn't need to know about it and given that MySQL can merge views into queries I'd think this would be no less efficient than the more direct solution.

Now for the question: Is this a stupid idea for some reason I'm not spotting?


Note: This would only go two layers deep, e.i. views would only reference tables, never views.

+2  A: 

Views can simplify the amount of text you need to create a query, but layering views on top of one another is a bad practice.

That encapsulation also risks poor performing queries, because the views need to be executed before being able to join to one another--all that logic inside might not apply to what you need for the ultimate result, so being lazy can easily mean a query that doesn't perform as well as it should.

Because the views are queries that are only run when called, you won't know about missing references until runtime.

Be aware that when using SELECT * in a view, the database captures the column list when the CREATE VIEW statement was run - if the columns change, you need to refresh the view to pick up the changes.

There's also no performance difference between a view and running the query the view is based on. With the exception of materialized views (which MySQL doesn't support), views are just a prepared statement. If simple enough, WHERE predicates can be pushed from the FROM view WHERE .... into the inner query, but it means no use of functions and isn't reliable.

Conclusion

OK, but be careful.

OMG Ponies
So is that a "Sure, go for it.", a "WTF are you thinking!" or a "OK, but be careful."?
BCS
@BCS: See update
OMG Ponies
"There's also no performance difference between a view and running the query the view is based on."Don't you think we are executing an extra query to first create a view and then fetching the data through it...?
anand
@anand: Unless using a materialized view, `SELECT * FROM your_view` is the same as running the query the view encapsulates. Or do you mean `CREATE VIEW your_view AS ...`?
OMG Ponies
@anand: for clarification, I'm not proposing that each query create it's own view, use it, and throw it away. The use mode is that the views be part of the schema; created at DB setup and then not changed until the schema changes.
BCS
@OMG I know the view will be created just once and then will be queried each time. But the view would be constructed through the tables using the joins. Views dont have their own data. So they will fetch the data from the tables only. I don't know the exact mechanism, but i guess each time the data in table changes view would need to get that data using the same joins and then you will execute a query to fetch it from the view? Pls correct me if i am wrong
anand
@anand: A non-materialized view is just a prepared statement, and because of the abstraction you'd only get an error regarding underlying table changes the next time the view was referenced in a query. We're saying the same thing, but your terminology is somewhat confusing (doesn't help that I can be [pedantic](http://dictionary.reference.com/browse/pedantic))...
OMG Ponies