Hacker News Reader

Comment by sparker72678 | Hacker News Reader

I mean, more power to you if this is something you want, but writing raw SQL is something I will never miss.

Why? Just like learning Emacs/vim, the time investment is well worth it.

You get much more elaborate the more time you invest in learning, and the skills gained will still be valuable in 25 years - as opposed to whatever subset of SQL the query builder du jour would give you.

It sounds like the commenter knows SQL, so it’s not like they want to avoid learning it. I can only guess, but more likely they dislike the fact that you have to represent your raw queries etc safely as a string in your application’s language - which isn’t hard but it does look a little ungainly and tends not to scale too well. As for the “du jour” part - is there that much churn and fanboyism in ORMs?

Strings do give you the ability to copy them right into your code from the SQL console after testing.

While that is true, I think most queries would involve parameters of some sort, so those would need to be fiddled with at the very least after pasting to your code, plus you'd also want to format them so they don't look that out of place. And at that point you've likely got a single maybe-weirdly indented query that appears as a plain string, which is fine if you have just a couple but can get a little tricky if you have a larger application.

I'm not super religious about this - a colleague and I were discussing Hangfire.io's SQL Server code which has inline SQL[0] and we ended up agreeing that it's fine - but if I'm writing an application with a SQL backend I'm definitely leaning towards using something like EF in .NET

[0] = https://github.com/HangfireIO/Hangfire/blob/master/src/Hangf...

True about the params. I guess I've always put the queries in as "here" strings, so they do look out of place in the sense that the structure is different. In most cases the sql was in a file with a bunch of other "lowest" level db calls, so I kind of got used to that being the look of those particular source files.

Looked at the Hangfire code and the last two methods there look a lot like what I used to do in the old C# days. Except I'd have whole files of db stuff like that, and other files for the C# code that called them.

Ah neat so there's a very real separation between the code itself and the queries, that I think addresses the weirdness of seeing a block of SQL in a string literal that I find a bit jarring. Out of curiousity, is this Perl by any chance? I haven't really seen here docs in use outside shell or Perl scripts

Haven't used Perl but they're in a lot of languages, Lisps, Python ("""), Ruby, PHP etc. but C# does at least have the verbatim-type of strings which would be good enough. Don't use the interpolation features though, use the @params and let the SQL driver do the replacements.

I've learned vim. It was not worth it. I'm more productive with vscode and nano.

I know SQL, 99% of the time, an ORM is more productive, for the rest, I can still write SQL manually. It's not an XOR.

I got pretty proficient at using vim in vscode, and personally for me the investment was worth it. It's great for working in HTML with chords like `va"p` (replace selection around quote with clipboard) and `dip` (cut out the contents inside this xml tag). YMMV depending on the type of work you do.

I'm completely hopeless in nano because I can't for the life of me use the arrow keys for moving around, so I just end up typing random strings of hjkl/bw or whatever in the buffer until I realize I have the wrong editor and switch to some variant of vi so I don't fight with my fingers.

One major advantage of vi is that it's always there (except on Windows :().

I'm fluent in SQL, and even with ActiveRecord it's not always possible to escape having to write it directly, but I still don't like it.

Writing raw SQL comes with all kinds of risks you can abstract away through nice ORM APIs, and with a good ORM API I find that it's much easier to clearly communicate intent in the code.

YMMV.

Even sticking to "just" SQL without a true ORM, using a well-designed query builder instead of writing raw strings will save you from inevitable "oops, forgot a comma" bugs.

With the library I'm using (Quill), the DSL is mostly a copy of the standard library's collections, so other than a little boilerplate, it's mostly already familiar.

In my experience, writing "raw" SQL only sucks if your schema sucks and/or you don't have much patience for abstract thinking and building views to make common use cases easier.

I much prefer being able to write a simple SQL query to deliver a piece of business functionality, especially if this is part of some configuration-time setup and not a code-time thing.

It's also 1000x easier to discuss the implications of a particular SQL query with other non-wizards. Emailing my project managers C# method snippets is just going to return more questions to my inbox.

Its really worth taking the time to learn well. Any library that abstracts that for you, is using some rules to create sql underneath, so knowing what its (probably) doing can give you a lot of insight when tracking down performance problems or bugs. And, suggest changes you can make to the schema, or stored procedures if necessary to improve performance as well.

Reply on news.ycombinator.com