3 ms·

Has nothing to do with the language. 1 (in its isolated presentation) exists outside of my set of data and that's not something that gives me comfortable feelin

by chaps 3y ago

Has nothing to do with the language. 1 (in its isolated presentation) exists outside of my set of data and that's not something that gives me comfortable feelings. It forces me to think (less think more good) why some random value needs to float around my data and maybe needs to be appended or summed or whatever.. because reasons. As far as I'm concerned you might as well make it 200 or 1648194. And why would those ever be needed in any context around my data?

naikrovek 3y ago
1 isn't data, here. it's just a flag to return that row. I am sure you know this, so I'm wondering why you consider it data which is outside of your data set. it isn't data when used like this.
- chaps 3y ago
  In the sense that code is data: yes, it absolutely is data.
  - naikrovek 3y ago
    don't be obtuse. it isn't in the dataset and it isn't returned in the results. > code is data, so it's data dude, don't. this is the weakest and most grasping argument I think I've ever heard.
    - chaps 3y ago
      No need to be a dismissive dickhole about it, friend. Maybe I'm not wording it right then? Like I said in other posts, I copy paste SQL statements all the time. If I were to copy/paste that statement then all I'd get is a bunch of ones and that's useless to me. The SQL itself is data to me in the same way that when I view a lazy list comprehension, I view it (and SQL) as something that's just waiting to be run. Maybe not now, and maybe not in the current SQL, but there's a non-zero chance that I'll copy/paste it. So in that context, a bunch of ones is useless to me and IS data because the ones are literally the output of the SQL statement. Better to generalize my code writing process in a way so that I can copy/paste a "select *" or "select rownum" because those are more useful down the line. Really think we all just code differently.
      - naikrovek 3y ago
        > No need to be a dismissive dickhole about it, friend. name-calling. it's a weak, last resort move. you don't get a bunch of 1s from that query. And, I think I know why you're copying and pasting queries all the time instead of writing them.
        chaps 3y ago
        "you don't get a bunch of 1s from that query." You've seriously missed the point if this is what you're still saying. Take a step back, breathe, and try to consider that you've missed something. Whether that's a point I've made, or a lack of perspective, I don't know. For example, we almost definitely work in different fields with different practices and reasons for doing things differently. And that's fine. But your continued dismissiveness isn't helpful. Like another post said, "select *" is helpful in data analytics work. If it's not helpful in your field, that's also fine. But for me and my colleagues, it is. And I promise you're wrong in your thinking of why I copy paste SQL. What a weird fucking conversation. Also, calling someone obtuse is name calling, so pot kettle black and all that, ya obtuse weirdo. Good luck, friend.
kbenson 3y ago
Would it make you feel better about it to think of it as (or write it as) "select true" ? Because that's essentially what it's communicating, that there is something to return and that's what we're checking for.
- chaps 3y ago
  Nope, for the same exact reason. Select * makes the most sense because * is in the context of my data, not something I'm working into it. Pretty sure it's the same speed. Also mind you, I use a lot of CTEs, so this would look weird in that context -- hence why using row number sometimes makes more sense and achieves the same thing.
  - hobs 3y ago
    Filter out everything, Project only what you need, Transform it as lightly as possible. In any context I understand a row number would never "make sense" if a constant of 1 would be the same output, it would be a lot more code that does... nothing? Any code using select * just breaks in the future with any new columns being added, no thanks.
    - chaps 3y ago
      Any code using select * just breaks in the future with any new columns being added, no thanks. For you, maybe. In my workflows this is really a non-issue for me. Maybe consider that we use SQL differently and your goals and challenges are different from mine. (Edit: What's with the downvotes from people just disagreeing about preferences? So weird.)
      - hobs 3y ago
        I didn't downvote you, but consider this - I work with SQL a lot, like a lot a lot. Something that's your code today is probably my code tomorrow. So when you say "my flow is X" and your flow is inimical to maintaining it and extending it, people might get a bit irritated at the last dev that did the exact same thing.
hobs 3y ago
Yes, and all those constants would be treated the same, just like in many languages things are conventions - you don't need to use _ to name a variable that you throw away, but you do, because conventions. There's so many people that want to complain about the conventions of SQL but praise the conventions of other languages and I think its often just "which did you see first?"
- chaps 3y ago
  You're missing the point that I don't really care about how they're treated. I want to glance at it and know what it does. For me, the 1 gets in the way. Maybe it doesn't get in the way for you because you don't use it the same way as I do, as a practice.
deleted 3y ago
[deleted]
rrrrrrrrrrrryan 3y ago
> Has nothing to do with the language. ...but... this is literally how you write an EXISTS clause in SQL. > you might as well make it 200 or 1648194 Yes, you can put anything there. There's lots of funky inconsistent syntax in SQL because it evolved organically over literally the past half century. It has everything to do with the language.
- chaps 3y ago
  Yes, you can put anything there. And yes, you missed the point.

by chaps 3y ago

naikrovek 3y ago

1 isn't data, here. it's just a flag to return that row. I am sure you know this, so I'm wondering why you consider it data which is outside of your data set. it isn't data when used like this.

chaps 3y ago
In the sense that code is data: yes, it absolutely is data.
- naikrovek 3y ago
  don't be obtuse. it isn't in the dataset and it isn't returned in the results. > code is data, so it's data dude, don't. this is the weakest and most grasping argument I think I've ever heard.
  - chaps 3y ago
    No need to be a dismissive dickhole about it, friend. Maybe I'm not wording it right then? Like I said in other posts, I copy paste SQL statements all the time. If I were to copy/paste that statement then all I'd get is a bunch of ones and that's useless to me. The SQL itself is data to me in the same way that when I view a lazy list comprehension, I view it (and SQL) as something that's just waiting to be run. Maybe not now, and maybe not in the current SQL, but there's a non-zero chance that I'll copy/paste it. So in that context, a bunch of ones is useless to me and IS data because the ones are literally the output of the SQL statement. Better to generalize my code writing process in a way so that I can copy/paste a "select *" or "select rownum" because those are more useful down the line. Really think we all just code differently.
    - naikrovek 3y ago
      > No need to be a dismissive dickhole about it, friend. name-calling. it's a weak, last resort move. you don't get a bunch of 1s from that query. And, I think I know why you're copying and pasting queries all the time instead of writing them.
      - chaps 3y ago
        "you don't get a bunch of 1s from that query." You've seriously missed the point if this is what you're still saying. Take a step back, breathe, and try to consider that you've missed something. Whether that's a point I've made, or a lack of perspective, I don't know. For example, we almost definitely work in different fields with different practices and reasons for doing things differently. And that's fine. But your continued dismissiveness isn't helpful. Like another post said, "select *" is helpful in data analytics work. If it's not helpful in your field, that's also fine. But for me and my colleagues, it is. And I promise you're wrong in your thinking of why I copy paste SQL. What a weird fucking conversation. Also, calling someone obtuse is name calling, so pot kettle black and all that, ya obtuse weirdo. Good luck, friend.

kbenson 3y ago

Would it make you feel better about it to think of it as (or write it as) "select true" ? Because that's essentially what it's communicating, that there is something to return and that's what we're checking for.

chaps 3y ago
Nope, for the same exact reason. Select * makes the most sense because * is in the context of my data, not something I'm working into it. Pretty sure it's the same speed. Also mind you, I use a lot of CTEs, so this would look weird in that context -- hence why using row number sometimes makes more sense and achieves the same thing.
- hobs 3y ago
  Filter out everything, Project only what you need, Transform it as lightly as possible. In any context I understand a row number would never "make sense" if a constant of 1 would be the same output, it would be a lot more code that does... nothing? Any code using select * just breaks in the future with any new columns being added, no thanks.
  - chaps 3y ago
    Any code using select * just breaks in the future with any new columns being added, no thanks. For you, maybe. In my workflows this is really a non-issue for me. Maybe consider that we use SQL differently and your goals and challenges are different from mine. (Edit: What's with the downvotes from people just disagreeing about preferences? So weird.)
    - hobs 3y ago
      I didn't downvote you, but consider this - I work with SQL a lot, like a lot a lot. Something that's your code today is probably my code tomorrow. So when you say "my flow is X" and your flow is inimical to maintaining it and extending it, people might get a bit irritated at the last dev that did the exact same thing.

hobs 3y ago

Yes, and all those constants would be treated the same, just like in many languages things are conventions - you don't need to use _ to name a variable that you throw away, but you do, because conventions. There's so many people that want to complain about the conventions of SQL but praise the conventions of other languages and I think its often just "which did you see first?"

chaps 3y ago
You're missing the point that I don't really care about how they're treated. I want to glance at it and know what it does. For me, the 1 gets in the way. Maybe it doesn't get in the way for you because you don't use it the same way as I do, as a practice.

deleted 3y ago

[deleted]

rrrrrrrrrrrryan 3y ago

> Has nothing to do with the language. ...but... this is literally how you write an EXISTS clause in SQL. > you might as well make it 200 or 1648194 Yes, you can put anything there. There's lots of funky inconsistent syntax in SQL because it evolved organically over literally the past half century. It has everything to do with the language.

chaps 3y ago
Yes, you can put anything there. And yes, you missed the point.