查看与 ODBC 查询
我正在专用服务器上的 PostgreSQL 中设计一个数据库。我希望经常运行某些复杂的查询，并且可以通过 ODBC/JDBC 客户端（例如 MS-Access 或报告软件）访问结果。
在我看来，我可以选择在 PostgreSQL 中定义 VIEW 并使用 ODBC 导入它，或者在 ODBC 客户端中定义查询并导入基础表。
哪个最好？ 我还缺少其他选择吗？
I am designing a database in PostgreSQL on a dedicated server. I want certain complex queries to be run often, and the results to be accessible with ODBC/JDBC clients such as MS-Access or reporting software.
As I see it, I have the option to either define a VIEW within PostgreSQL and import it using ODBC, or to define the query within the ODBC client and import the underlying tables.
Which is best?
Are there any other options that I am missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不确定你所说的“导入”是什么意思。视图本质上是一个预定义的查询，您可以像从表中一样选择数据。当您执行 SELECT 查询时，无论您是直接访问数据表还是通过视图访问数据表，都只会将查询结果发送回给您。
如果您必须从各种不同的客户端执行相同的查询，那么为该查询定义一个视图可能是个好主意。
分享并享受。
I'm not sure what you mean by "import". A view is essentially a predefined query which you can select data from as you would from a table. When you execute a SELECT query, whether you're accessing the data tables directly or through a view, only the results of the query are sent back to you.
If you have to execute the same query from various different clients it might be a good idea to define a view for that query.
Share and enjoy.
您说您有复杂的查询，这些查询创建了您想要用于报告目的的输出。
汇总、聚合等的执行和存储在数据仓库中的方式与您描述的方式几乎相同。
如果这是您想要的，您应该考虑使用一个表来存储查询的输出。使用调度程序在适当的时间运行 ComplexQuery 并将输出存储在表中。
你必须决定为什么你想要这个。查询的复杂性并不像数据库服务器运行查询所需的资源量那么重要。如果它足够小并且不会对性能产生负面影响，并且您需要实时数据，请使用视图。如果您可以接受定期刷新的数据，这些数据可以快速可用并且不会给服务器带来高负载，那么请选择聚合表。
You say you have complex queries that create an output that you want to be used for reporting purposes.
Rollups, aggregations, etc are performed and stored in the data warehouse in pretty much the same way as you describe.
If this is what you want, you should consider having a table that stores the output of the query. Use a scheduling program to run your ComplexQuery at appropriate times and store the output in a table.
You have to decide why you want this. The complexity of the query is not a factor as much as the amount of resources that required database server to run the query. If this is small enough and it does not negatively affect performance, and you need your data real time, use a View. If you can live with periodically refreshed data, that is quickly available and does not put a high load on the server, go for an aggregate table.