views:

32

answers:

2

Hello, I am working on the database layout of a straighforward small database in Mysql. We want to modularize this system in order to have more flexiblity for different implementations we are going to make. Now, the idea was to have one module in the database (simple a group of tables with constraints between them) pass its data to the next module via views. In this way, changes in one module would not affect the other ones, as we can make sure in the view that the right data is present there at any time, although the underlying structure of tables might be different.

The structure of the App handling the database would likewise be modularized.

Is this something that is sometimes done? On a technical side, as I understand views can't have primary keys - how would I then adress such a view? What other issues should be considered?

A: 

This is a valid approach, though you should of course be careful:

  • Make sure that your queries are very well tested for performance with query plans analyzed. The views will use the underlying tables's indexes, BUT the likelyhood of bad execution plan is higher.

  • Make sure that enough views exist to cover all needed info.

DVK
+1  A: 

Is this something that is sometimes done?

Yes, views are often used to insulate things from data models in a state of flux.

On a technical side, as I understand views can't have primary keys - how would I then address such a view?

MySQL doesn't support materialized views. Non-materialized views are just prepared SQL statements - they don't exist in the data model, and performance is ultimately based on what exists on the underlying table(s) and query optimizations.

That said, layering views (creating a view that selects from another) is not recommended - it's brittle, and there's a big risk that performance will decrease because someone wants simplicity over query optimization.

OMG Ponies
"That said, layering views (creating a view that selects from another) is not recommended - it's brittle, and there's a big risk that performance will decrease because someone wants simplicity over query optimization."I'd upvote you a million times over if I could for this statement alone. I had to work with a system that did that and it almost lost us a multimillion dollar client because performance was so bad. There is no easy fix later for this kind of junk either.
HLGEM
Thank you very much for your answer. Maybe I could clarify the last part of the question: I wasn't implying to layer views, but want to have a table relating to the data in the view (via a foreign key)... just that I don't know what to relate to, since the view doesn't have a primary key.I could construct one 'manually' in the view I guess combining some of the values if that's the way to go?
Stefan
@Stefan: A primary key is a constraint, which you can't apply to non-materialized views. All that matters is there are column(s) in the view you can reference in a JOIN clause to the table in question to get related data.
OMG Ponies
@OMG Ponies: thanks a lot, now I see. I would just use several conditions like (t1.a=view.a AND t1.b=view.b) to set up the join.
Stefan
@Stefan: Yep, you got it. Don't forget to mark an answer when you feel your question has been answered.
OMG Ponies