@PaulWhite there is also the possibility of having index on ([PRINT], [DEL_METHOD], [INV_NO]) INCLUDE ([TYPE], ...) WHERE ([TYPE] IN (3,5) AND ...) - if those 3,5 are the most common case.
@ErikDarling I don't know, once I got the hang of it then it made perfect sense. Quick rule of thumb from my experience of it: if the grouping sets are strictly subsets of each other then a spool is not needed. Eg ( (ProductId, OrderDate), (ProductId), () ) does not need a spool, but ( (ProductId), (OrderDate), () ) will need one.
I found it useful where a very complex query was being pulled 4 times using UNION and causing deadlocks. I converted it to GROUPING SETS and they were subsets of one another so no spool. As always YMMV.
> Then the secondary replica SQL instance was stopped and the log files were completely deleted to free up space on the secondary replica, and the instance was restarted.
@Zikato I was busy all day, when I remembered to check it I was told my time was up. Lichess doesn't let me know when people move or time limits or anything, it doesn't seem to work properly.
I'm pretty sure I had the game if I didn't do any super stupid moves.
@bbaird Although Codd's arguments are mainly around the relational aspect. I'm arguing on the language front: it has horribly misintuitive syntax (as opposed to unintuitive, it actively intuits you in the wrong way), and extensibility is poor compared to modern languages (can we have proper modularization, pretty please?), and it's designed in a way that actively promotes code injection and discourages any form of dynamic programming (other than concatting strings and using EXEC).
There is no particular reason why SQL could not have been designed to do the kinds of things allowed in LINQ. For example: a variable which contains a query definition, which is then modified with ordering or filtering. Or vv: pass in any variable containing a query matching say a particular RESULT SET, and modify it by ordering it or filtering it. You simply cannot do any of this without resorting to EXEC and stringifying your code
@Charlieface I've never felt particularly limited by SQL with the exception of certain recursive operations and I've done some really wild stuff. But I am absolutely not beholden to any experience in traditional languages.
In this year of our lord 2022 can we at least agree to stop violating first normal form? I get the whole "key" thing is tricky for people, how about just making sure we've got atomic values from a single domain? Surely that can't be too much to ask.
> that type of language is not acceptable on the Stack Exchange network. Please remember that this is supposed to be a professional environment; you can review the Code of Conduct for a refresher on how users are supposed to interact here.
@CadeRoux Not really. You are mainly thinking of scalar UDFs and RBAR procs which are specific problems. I'm thinking things like publicprivate, and classes/namespaces, as well as simple syntax improvements, none of which should affect perf at all.
Even function sargeability can be worked around. See this excellent series from Explain Extended on monotonic functions, which shows how functions could have added properties that define how they react to inputs, allowing the optimizer to reason over them.
Froid was an interesting project from MS Research that gave us scalar function inlining, while not perfect it has a lot of scope for further improvement. Research papers here microsoft.com/en-us/research/project/froid
@Mithical I reported your action and would suggest you to review the mentioned code yourself as well. The problematic language in that message of mine is hardly even a swear word, and on top of that it was not directed at anyone. 24 hour ban seems ridiculous, considering how I have seen actual cases of offensive messages getting just 30 minute suspensions at most.
@Charlieface He's right even in regards to Views TBH. Most people just don't have the level of refactoring that it matters in the end, but I currently do for some cases.
