I am curious if creating a view with over 100 fields in about 45 tables is an *acceptable* practice or if there is a better way to do this.

I am programming a php frontend to a mysql db and need to create the select statement. What I have are a lot of fields to be populated into a template. This template has a header to make the documant more readable then the corasponding data fields below it. The header is not stored in the db, only the fields. So I may have the following:

These fields are scattered all throughout the db and I will need to join them all together to get what I need.

As I am thinking about this, it doesn't seem right. There has to be another way, or is this common practice?

I am not that proficient with php and I know I could probably create a class to handle multiple views but right now that is not an option for me.

if the view is necessary, then it's acceptable

however, i doubt very much that you will be able to write an actual query that spans 45 tables

that is how you develop a view -- develop and test the underlying query first, make sure it is producing the correct results, then slap CREATE VIEW AS in front of it

Its necessary but you are correct, not possible. I tried every which way and I just can't get it working. I am going to have to find another alternative using another php class.

Thanks for the pointer on the creation of the view; great advice. Now I know what I am up against.