3 ms·
You are right. If that’s the query you need to write, you’ll be ok. That said, I don’t think I’ve ever had occasion to write a query quite like that. I’ve writ
by hyperpape 2y ago
You are right. If that’s the query you need to write, you’ll be ok.
That said, I don’t think I’ve ever had occasion to write a query quite like that. I’ve written
select * from blah where id in (1,2,3…) and condition
or
select * from blah where condition1 and condition2
but never a query quite like this. Do you know of use cases for it?
Given that most queries don't look like that, I think my criticism is reasonable. For most use cases, this query will have performance downsides, even if it doesn't for some very narrow use-cases.
- throwup238 2y agoThat sounds like the developer use case. Data scientists doing ETL and analyzing messy data with weird rules like the ones above are common (although the id is usually a contains/in to handle lists of rows that don’t fit any of the conditions but must be included). I’ve had to do some weird things to clean up data from vendor databases in several industries.
- nycdotnet 2y agoRecord selector to drive a data grid. Ex: Filter employees by location, or active/terminated, or salary/hourly, etc. and let the user choose one or many of these filters.
- deleted 2y ago[deleted]
- hombre_fatal 2y agoThe use case is basically every /search endpoint or any table view where the user can select filters.