开发者

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.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜