141–150 of 167 posts
Earlier quoted context omitted.
Isn’t sql weakly typed? Or does this depend on the engine?
No it is strongly typed, there is no accident that all PL extensions to the base query language have such a Ada/Pascal similarity. Additional DML has plenty of options to enforce rules that keep data consistency. While they make the life harder to delete/update/insert items in specific sequences, they can save the day on bad queries.
Earlier quoted context omitted.
Only because some people are very opinated in avoiding stored procedures, and think smashing strings together is a much better solution.
Stored procedures have the wrong versioning model. If they were version-locked to the application code, instead of to the database schema, they'd be less of a pain and people might be more willing to use them.
Earlier quoted context omitted.
No it is strongly typed, there is no accident that all PL extensions to the base query language have such a Ada/Pascal similarity. Additional DML has plenty of options to enforce rules that keep data consistency. While they make the life harder to delete/update/insert items in specific sequences, they can save the day on bad queries.
What happens if a query compares a string to a number?
Earlier quoted context omitted.
Just learn SQL. I believe all these SQL replacement layers are just because people don't like SQL and don't learn it, so they learn a training wheels version of it that will cripple their ability to grow because it's simplifications remove expressiveness that caused SQL to be more complex to begin with. Just learn SQL, it's not that hard. A lot of very very smart people put a lot of effort into it. It's very good. Th…
No. SQL is just bad. It's an old way of doing things. It's not hard but it's not good. Take this for example. Why do we have static type checking for typescript? Why do we have a build step for this? Why DON'T we have it for SQL? Why is it runtime strings? So no static checking and the only way to test if a query works is to run it? The purpose of these replacement layers is to get it all under one language. Once it'…
By now I stopped counting the attempts to replace SQL. There is a lot of valid critic for SQL and I would be very happy if some things would have been designed different. OTOH the architecture and mathematics behind relational databases are simple, composable and stood the test of time more than most other designs, methodologies or approaches to software development. Though SQL can be improved, even with my average S…
SQL has one flaw: The verb should come last. So, "FROM users WHERE id = 1 DELETE" or "FROM users WHERE email = 'foo@example.com' SELECT id". That'd cut back on some accidental "oops I dropped the whole table" because I submitted a delete query before writing the where clause. Other than that, it's perfect, no notes.
I have a very long history with language interfaces to databases. - As a grad student in the 80s, I read a lot about "database programming languages", which aimed to provide persistence and query capabilities to conventional programming languages, in a seamless way. - The next step to putting those ideas into practice: Participated in a research project on adding database capabilities to a programming language (anyon…
The thing I’ve never understood is why SQL itself is not the target of attack. There’s already an inherent language abstraction with the planner; Postgres in theory could be the JVM with any number of languages implemented on top. Including a language that lends itself to composition and auto generation of PL functions. ORMs are fundamentally difficult because of the mapping problem, but SQL code builders should be t…
C, C++, Perl, Java, CLR at least. GraalVM was originally designed as repurposing the MaximeVM ideas into a new Oracle SP engine.
You can even use Oracle or SQL Server as application server, having a Web frontend calling into stored procedures exposed as API endpoints.
Is this at all similar to LINQ in C#? I never used it, but I'm vaguely aware of it being a functional approach to querying an RDBMS.
Earlier quoted context omitted.
On the other hand, norms in software right now are that suckers build and maintain software for free + "the love of the game should be enough for anyone", so it's shocking when people break the norm.
That's not the norm that's being broken here. Most DB technologies provide a "pay for updates, if you stop paying you keep the last version you paid for" model. This is how Oracle prices its DB tech, this is how jOOQ is priced (which is probably the closest thing to Acadia), this is how MS prices its DB tech etc.
I'm not saying you can't find paid software, especially from Oracle and Microsoft, but there's a different expectation for "just-a-guy announcing his project on twitter".
You can see a similar mentality regarding Elm in general where the approachability of one guy had people in some sort of parasocial entitlement to the project that you wouldn't see if, for example, it were Google or an unknown who built Elm.
Earlier quoted context omitted.
Stored procedures have the wrong versioning model. If they were version-locked to the application code, instead of to the database schema, they'd be less of a pain and people might be more willing to use them.
There are CI/CD processes for deployment, versioning problem is solved at least for 30 years. Also it is hardly any different from handling version differences in distributed systems, or split between frontend and backend on Web applications.