具有两个表和多个数据和价格范围的复杂查询
假设我有这些表:
[ properties ]
id (INT, PK)
name (VARCHAR)
[ properties_prices ]
id (INT, PK)
property_id (INT, FK)
date_begin (DATE)
date_end (DATE)
price_per_day (DECIMAL)
price_per_week (DECIMAL)
price_per_month (DECIMAL)
我的访问者运行如下搜索: 列出 5 月 1 日至 12 月 31 日期间每天价格(price_per_day 字段)在 10 到 100 之间的前 10 个(分页)属性
我知道这是一个巨大的查询,我需要对结果进行分页,所以我必须完成所有计算并仅在一个查询中登录......这就是我在这里的原因! :)
有关问题的疑问
如果存在差距,这是否是可接受的属性?
没有间隙。所有可能的日期都在数据库中。
如果在某些超级时期价格在 10 到 100 之间,但在其他时期不是,您想购买该房产吗?
在完美的世界中,不......我们需要考虑所有变化/时期来计算该时期内该类型价格的“总和”。
另外,“前10个”是什么?它们是如何订购的?最低价优先?但价格可能不止一种。
这只是一个分页示例,每页有 10 个结果...可以通过全文搜索进行排序,我将添加关键字和这些内容...正如我所说,这是一个相当大的查询。
Let's suppose that I have these tables:
[ properties ]
id (INT, PK)
name (VARCHAR)
[ properties_prices ]
id (INT, PK)
property_id (INT, FK)
date_begin (DATE)
date_end (DATE)
price_per_day (DECIMAL)
price_per_week (DECIMAL)
price_per_month (DECIMAL)
And my visitor runs a search like: List the first 10 (pagination) properties where the price per day (price_per_day field) is between 10 and 100 on the period for 1st may until 31 december
I know thats a huge query, and I need to paginate the results, so I must do all the calculation and login in only one query... that's why i'm here! :)
Questions about the problem
If there are gaps, would that be an acceptable property?
There're no gaps. All the possible dates are in the database.
If the price is between 10 and 100 in some sup-periods, but not in others, do you want to get that property?
In the perfect world, no... We'll need to calculate the "sum" of that type of price in that period considering all the variations/periods.
Also, what are the "first 10"? How are they ordered? Lowest price first? But there could be more than one price.
This is just an example of pagination with 10 results per page... Can be ordered by the FULLTEXT search that I'll add with keywords and these things... As I said, it's a pretty big query.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
这与 @mdma 给出的答案类似,但我在价格范围的连接子句中使用条件,而不是
HAVING
技巧。我还建议创建覆盖索引:
这允许您的查询尽可能最佳地运行,因为它可以直接从索引读取值。它根本不需要从表中读取数据行。
This is similar to the answer given by @mdma, but I use a condition in the join clause for the price range, instead of the
HAVING
trick.I would also recommend creating a covering index:
This allows your query to run as optimally as possible, because it can read the values directly from the index. It won't have to read the rows of data from the table at all.
你告诉我们的不够精确。根据您的数据结构和您的问题,我假设:
但仍然存在问题:
根据答案,可能没有单个查询可以解决问题。但是,如果您接受差距,则可能会返回您想要的结果:
该查询不会为您提供价格或其他详细信息。这需要进行额外的查询。但也许我的假设都是错误的。
What you tell us is not precise enough. From your data structure and your question I assume:
But there are still questions:
Depending on the answers, there might be no single query doing the trick. But if you accept the gaps, that could return what you want:
That query doesn't give you the prices or other details. That would need to go in an extra query. But perhaps my assumptions are all wrong anyway.
这也可以作为 GROUP BY 来完成,我认为这会非常有效,并且我们得到一些聚合作为包的一部分:(
我手头没有 MySQL,所以我没有测试过。我不确定MIN(IF ...) 但使用 CASE 的模型在 SQLServer 上运行。)
This can also be done as a GROUP BY, which I think will be quite efficient, and we get some aggregates as part of the package:
(I don't have MySQL to hand so I haven't tested. I was unsure about the MIN(IF ...) but a mock-up using a CASE worked on SQLServer.)