61–70 of 100 posts
Earlier quoted context omitted.
He probably meant "disclosure", not "disclaimer".
The overlords of HN have deemed my post is too old for an "edit" button so, yes, my use of "disclaimer" is a case of auditory familiarity overruling accurate terminology
Earlier quoted context omitted.
The reason for me to use ORM rather than direct SQL queries is so I can keep everything written in a single language, so I can develop with one IDE. Having everything under one roof is a huge boon to productivity, rather than having to edit the logic in the IDE, then edit the database queries in a different editor, and the two knowing nothing about each other. It lets me directly map my source language's type system…
Don't most IDE's do SQL in the mix with everything else or am I just spoiled by Visual Studio? My opinion is that one uses an ORM for different situations than they would use SQL. Many applications can use an ORM and nothing else. Some can use an ORM for basic CRUD tasks and then raw SQL to do analysis or reporting.
It's critical to have a good understanding of SQL, but once you do, ORMs with a functional syntax solve this problem for many of us. I know it's not possible for some people to use ORMs as they can't risk the ORM making a performance mistake, but I think the solution is to improve ORMs to the point that writing raw SQL is akin to writing assembly instead of using a higher level language. That said, we're not there ye…
I think the solution is to upgrade SQL the language. There's a very low complexity threshold after which you have to trade readability/composability for decent performance (in other words, there are a lot of cases where a human can notice a permissible optimization, but a database can't because it might break correctness for some odd edge case). We're solving that problem with programming languages (notably Rust); I'…
I wish CTEs ("common table expression", i.e. a "with clause") had the same performance as a subquery in PSQL. I always assumed they'd be implemented as a kind of macro that expanded to a subquery. Is there a good reason for this distinction? For that matter, having some kind of SQL-oriented macro/preprocessor language would be fantastic. I guess GPP (General Preprocessor, https://logological.org/gpp ) is always an op…
Earlier quoted context omitted.
I can sympathize. For me, that's Scala JVM on the server, ScalaTags/ScalaCSS/ScalaJS in the web browser, Slick for the ORM, and SBT for the build system. The bliss of learn once, program anywhere. When this hits reality though, I use Relate https://github.com/lucidsoftware/relate (disclaimer: I'm a contributor) It's SQL, but with minimal syntactic overhead. sql"SELECT * FROM users WHERE email IN ($emails)".asList[Use…
Since you're already using Slick, what's the difference between Relate and Slick's native SQL literals[1]? [1]: http://slick.lightbend.com/doc/3.2.0/sql.html
[1]: https://www.playframework.com/documentation/2.5.x/ScalaAnorm...
It's critical to have a good understanding of SQL, but once you do, ORMs with a functional syntax solve this problem for many of us. I know it's not possible for some people to use ORMs as they can't risk the ORM making a performance mistake, but I think the solution is to improve ORMs to the point that writing raw SQL is akin to writing assembly instead of using a higher level language. That said, we're not there ye…
Earlier quoted context omitted.
I disagree about SQL being like assembly. It's a fairly high level language, because underneath the engine is figuring out how to use indexes and actually run your query. If you want to draw parallels, ORMs are more like writing code in a template language that's written in the language you're actually working in. I've spent far too much time fighting with ORMs trying to get the SQL I want generated. Additionally for…
I've found views, parameterized-views/table-valued-functions can be a nice compromise to keeping the SQL relatively simple and thus ORM friendly without sacrificing performance.
When it comes to optimizing a slow running query, having to step through layer after layer of nested view can be incredibly challenging.
It's critical to have a good understanding of SQL, but once you do, ORMs with a functional syntax solve this problem for many of us. I know it's not possible for some people to use ORMs as they can't risk the ORM making a performance mistake, but I think the solution is to improve ORMs to the point that writing raw SQL is akin to writing assembly instead of using a higher level language. That said, we're not there ye…
ORMs are for people who don't know SQL.
Earlier quoted context omitted.
Don't most IDE's do SQL in the mix with everything else or am I just spoiled by Visual Studio? My opinion is that one uses an ORM for different situations than they would use SQL. Many applications can use an ORM and nothing else. Some can use an ORM for basic CRUD tasks and then raw SQL to do analysis or reporting.
you (and I) are absolutely spoiled by Visual Studio w/SSDT. there is nothing even remotely close to that level of integration for database development in other stacks.
It's also available standalone as "DataGrip", though I've never used it:
Earlier quoted context omitted.
I've found views, parameterized-views/table-valued-functions can be a nice compromise to keeping the SQL relatively simple and thus ORM friendly without sacrificing performance.
This can be dangerous if over used. It can be very tempting to quickly pull in a 'left join blah' to grab some fields you may need. But that blah view could be hiding some massive performance sapping beast. When it comes to optimizing a slow running query, having to step through layer after layer of nested view can be incredibly challenging.