Splitting up long queries for readability / maintainability

I have inherited a Access database that has a query that SELECTs over 50 columns. Even in the MS Access graphical query design tool, it's too much information to handle IMO.

A quick disclaimer - I have a programming background, but almost no experience with databases.

For this particular problem, I need data from 50+ columns. Is there a better way to get this information than one huge query?

I am a bit at a loss on how to proceed. The consensus on开发者_C百科 the web seems to be that SQL queries should be kept relatively small and well formated. I just don't see how to apply that principle when you need so many fields. Can I use lots of simple queries with a UNION or INSERT INTO a temporary table? Any suggestion or RTFMs?

EDIT: More info on the application. The data is spread across 14 tables. I'm grabbing the data to write it out to an external file which has 50+ fields per row (think CSV version of a spreadsheet).

EDIT: Managing and debugging SQL queries in MS Access looks like it contains relevant advice.

---

I think you're worrying yourself over nothing at all. Pulling 50 fields from 14 tables in order to output to a flat file is nothing at all. The point is that you're intentionally denormalizing data because you need a flat-file output. By definition, that will mean lots of columns.

As others have said, 50 columns in one table would be out of the ordinary (though not necessarily a design error), but in the situation you describe, I don't see an issue at all.

In short, it sounds like a perfectly fine setup and I just have to wonder what makes you think it's a problem to begin with.

---

I would echo most of the comments about needing 50+ columns every time you run your query.

However, if it's the ugliness of the query that gets you the 50+ columns that is causing your grief, you could create a view for that query. It doesn't get rid of the fact that you're dealing with a bunch of data, but it could encapsulate a large, hairy beast of an SQL statement.

---

If you're retrieving data from all columns, then you can write SELECT * FROM ....

---

If there are 50 columns in a single table, the database design is questionable at best. That might practically mean that you'll just have to cope with not-so-elegant solutions.

Do you really need all that data at once? If not, it's probably better to only SELECT the data you need at a given time. You should provide more information on the actual task.

---

If your data is coming from multiple tables, you could use Common Table Expressions to divide the query into groupings.