Well abs(sin(x)) is always going to return a value between 0 and 1, and I dunno how casting to bit works.. if it rounds this might be used to consistently grab half the users. If CAST(anything except 0) as BIT —> 1, then this could be used to grab a very small subset of users? If their clientIds happen to be clientId%180 == 0
this post was submitted on 30 Jun 2024
23 points (100.0% liked)
SQL
470 readers
1 users here now
Related Fediverse communities:
- #sql on Mastodon
- #postgresql on Mastodon
- c/PostgreSQL on programming.dev
Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
You're right in that any non-zero value casted to bit becomes 1, but that includes negative values, so I'm even more confused why you'd need ABS there...
Well then, to answer OP’s question about intent, I don’t have much of a clue, but here’s some Idea Ore that maybe someone can refine into a plausible explanation:
- clientId basically has to be sequential or none of this makes sense
- conceptually, I believe this statement is equivalent to clientId%180 == 0
- i can’t fathom CAST(ABS(SIN())) being more efficient than modular division, so maybe the dev was trying to be clever, hated the hardcoded 180, or some other unknown going on
- a sine wave goes -∿- so this is where it hits the x-axis
- given that, there has to be some periodic or cyclical purpose, relating to the why/how of the clientId creation. For example, when the results of this are graphed with a created_at timestamp, it might give useful insights to growth (or something)
I forgot to mention this is in SQL Server, so SIN operates on radians. So I THINK this can only ever cast to a 0 when clientId is also 0
It certainly doesn't for any of the 100,000 existing rows
Personally, I'd look very closely at any records this returns and verify that they are normal. A previous developer could have left some sort of backdoor or other nasty surprise in the code/database such could only be tripped with a very specific condition.
Alternatively, consider the context around this code. What is done with those records? Maybe there is a very specific bug elsewhere in the code or in a front end tied to this database. Sure, the right solution was to fix that other bug. But, that may not have been an option. So, this strange bit of code "solved" the problem and was then promptly forgotten.
The client table has around 100,000 rows each with a unique clientId, none of which are returned from the CAST / ABS / SIN
I think you are right and this is a 'fix' for something lost to time. I am going to talk to the original dev tomorrow to see if they remember what it was for
Let us know, ya?
I'm not that sturdy with SQL functions, but my understanding is this:
Get the client ID, and use that as input to a sine function to get a new number. Then get the absolute value of this number. Then you cast this as a bit, and you end up selecting all clients who through this lovecraftian horror ends up as 0.
Why?? I have no idea. It looks to me like they want only to select a subset of clientIDs, but with something that is hard to predict but with the same result every time for the same clients.
Update: The original dev does not remember exactly. However they have said that clientId was originally a VARCHAR, so this may have been checking for both '0' or ''
So an over-engineered workaround to a bad datatype perhaps?