No, you can’t.
SQL is easy. Data is hard.
We Can Do Better Than SQL
241–250 of 466 posts
Re: We Can Do Better Than SQL
#242Earlier quoted context omitted.
With SQL you can enforce it within the datastore. And if some requirement changes, you can instantly enforce it. Eg.: A new foreign key constraint. Also: It is centrally managed, so you don't need to look all over the source code to find the constraints and don't need duplicates either, if you can, for example,change the data at multiple points.
> With SQL you can enforce it within the datastore. And if some requirement changes, you can instantly enforce it. Eg.: A new foreign key constraint. Which is to say that you have little control over deployment. Adding a new foreign key constraint might block queries for an indeterminate amount of time while a new index is built, but you have no way to introspect or predict that at the SQL level (if you're lucky ther…
We use exclusively stored procedures, so if we want to add a FK constraint while the application doesn't adhere to it, we do one of two things:
Either add it to the application and push out a new version. Or handle it within the stored procedure.
Additionally, there would be the option of updating the database when pushing a new software update out.
> If your data is well architected so that you only have a single representation of each piece of data, sure. Equally if your application is well architected you can have a single API where any given thing happens.
I think I formulated it badly before. In this case I meant that we have one stored procedure for each thing we do. So that, if the underlying data changes for example, we only need to change the procedures directly acessing it. We can then call those procedures from multiple different parts of the code. And the procedures are all managed within one application, mssms in our case, where you can have a much cleaner structure than within code.
In my experience, in PHP for example, you tend to write VERY similar/same queries in multiple locations, which can cause you to find it harder to all instances.
Re: We Can Do Better Than SQL
#243Earlier quoted context omitted.
> all the syntax decided on before there was a community that really understood what good syntax is Here you got me thinking: do we even understand that now? There was quite a bit of contemplating about of semantics, data types and different kinds of abstractions in the programming languages for the last couple of generations already, but the general consensus about the syntax is that "nice syntax is nice, but it isn…
> So, to summarize: I never actually heard a compelling general theory of good syntax. I started to think along these lines when I got serious about learning a foreign language. Humans appear to have some innate language ability that’s reflected, among other things, in commonalities between disparate languages. As far as I can tell, there’s been no serious effort to design a computer language to take advantage of thi…
The commonality you are referring to sounds like Chomsky's concept of Universal Grammar [1].
The object.method(args) "won" because it is a low barrier to entry from English to Programming indeed, but as you become more and more experienced and you shake off the imperative way of thinking in favour of declarative thinking functional languages becomes more expressive than imperative languages. They become better at managing complexity because they allow you to build higher and higher towers of abstraction.
And then homoiconicity [2] shines because of its 'universally grammatic' property.
Re: We Can Do Better Than SQL
#244Completely agree regarding the complexity of various flavors of SQL. The thing is, this complexity came from legitimate need.
My team gets by with a very small subset of PostgreSQL functionality day to day because most of the stuff we're doing with our database is just not that complicated. Simple lookups, writes, joins when our applications interact with the database. Simple joins, grouping, aggregation when we personally interact with the database.
We are not confronted with the full complexity of PostgresQL every day. And on, the flip side, the database itself gives us killer functionality in the form of constraints and transactions. It offers a lot more, but this is all we care about an overwhelming majority of the time.
I am curious how you see it. Is there a compelling reason for a team like mine to leave their comfort zone to work with your new database? Does the new query language really solve any problems for Joe Sixpack, developer?
Re: We Can Do Better Than SQL
#245I see a lot of Stockholm syndrome in this thread / maybe low expectations. Many people are saying SQL isn't that hard to learn but as someone who is new to SQL, I disagree. It takes a max of 15 minutes to understand basic JavaScript/Go/Python primitives and write a program. SQL on the other hand seems much more complex. I might as well be reading Haskell or Lisp. At least those languages are consistent. SQL does not…
> It takes a max of 15 minutes to understand basic JavaScript/Go/Python primitives and write a program.
Basic SQL can be learnt just as quickly, if not quicker, I'd say, as it is close to english in comparison with other languages. IMO the hardest parts are stuff like pivots and cursors, along with performance problems in complex queries.
I personally wrote my first few queries within 30 minutes of starting to learn it.[1] Of course it wasn't particularily good SQL, but workable enough.
[1]Basically got an apprenticeship and was almost instantly told to write some queries.
Re: We Can Do Better Than SQL
#246Earlier quoted context omitted.
At work we almost exclusively use pure stored procedures[1] and everything is normalized very well. It is an absolute joy to write SQL, because of how terse it is while still being very readable. Trying to implement business rules about data relations outside of the DB is a nightmare. [1] We use dynamic SQL within stored procedures for pivots.
You lose source control on your procedures. How you deal with that?
If you use a DBMS to manually update these, yes. Otherwise you can do this in code whenever you want in your build/deploy pipeline.
Re: We Can Do Better Than SQL
#247Earlier quoted context omitted.
For triggers, you can run a procedure that executes it for all past data. Or write a procedure that updates the data to a valid state. When gradually rolling out, you can have adjusted stored procedures that deal with the different versions, and turn off the old one when it is no longer in use. So, I fail to see the problems you mentioned.
And with good practices (mainly a decent type system that lets you distinguish between checked and unchecked values) you'll have no problems with constraints in the application layer either.
I don't think we'll come to an agreement in regards to that, so, I am gonna voice my disagreement and move on.
It was informational that I saw your viewpoint, even though I disagree. In the future I will definitely try and reevaluate my viewpoints to see if maybe I am wrong after all.
Re: We Can Do Better Than SQL
#248It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should th…
In a world where there's a new programming language every other month, what's wrong with suggesting a new query language?
At least we don't have to change our whole data model or give up consistent data to try it!
Re: We Can Do Better Than SQL
#249I agree with the criticism of SQL here but to make yet another SQL but not SQL is not the way forward imo
I hope the writer reads http://www.learndatalogtoday.org/
In Clojure there are multiple databases that you can query by API, SQL and datalog
Re: We Can Do Better Than SQL
#250Earlier quoted context omitted.
Correct but I didn’t explain well. I mean the SQL generation is left to the ORM and I think that’s no accident.
Not for the reason you're implying, actually for the opposite reason. I'm from the days of yore, just before ORMs became popular and it basically replaced a lot of boilerplate code, but it wasn't the SQL that was the bulk of it. It was mainly to save time in writing code to map columns to object properties really, the sql statements themselves were trivial even if you weren't lazy and just used select *. Also, here's…
> It was mainly to save time in writing code to map columns to object properties really, the sql statements themselves were trivial even if you weren't lazy and just used select *.
I am running a side project and yes, writing the native SQL statement to take your object and put it in the database is not a problem, put in the parameterised values and off you go.
But getting the data back from the database? Oh the horror. So much boilerplate in order to see if there are any records returned it all, if there are enough columns with the correct name for the kind of object you are making, if there is data or not in each column as appropriate for that specific column, if a given field can be coerced into being a string or an integer or a date or similar, then they're all marshaled into a dto object which is passed to the create new object validator. 800 lines of code later, and you may have an object back!
Dapper appears to be the sweet spot for me, I am still writing SQL queries and still designing the SQL tables myself, no orm magic here, but it handles the actual marshalling to and from an in-memory dto object versus data in the table for me, and that is very valuable time savings.