4 ms·

This is where a bunch of people with no clue talk about how great pgsql is and everyone should create their startup using raw sql and only psgsql because it doe

by braz1973 11y ago

This is where a bunch of people with no clue talk about how great pgsql is and everyone should create their startup using raw sql and only psgsql because it does everything even nosql ;) It is funny how forums gravitate towards inappropriate and obscure solutions and then recommend them in every situation. You can see the same effect all over the internet. Eg MFA on reddit recommending Allen Edmond shoes. A completely inappropriate shoe with leather soles that costs 10 times as much as modern shoes. NoSQL databases are much nicer to work with for typical web applications (yeah, even the ones with relational data). They are much closer to how we actually use data as a programmer. Most startups using a SQL database will be using an ORM, which is a massive piece of software designed to make SQL databases more compatible with how we actually work. Even then, they still don't have the flexibility you get from using a nosql solution. As for this article, it is hard to get past the fact that he thinks the only reason to use nosql is for scalability. He also states that mysql was fine, yet fails to understand that the massive startups using mysql didn't use it at all like a relational database.

eropple 11y ago
> They are much closer to how we actually use data as a programmer. No, they're how you, as what sounds like a predominantly object-oriented programmer, use data. And that's fine, but don't pretend it's universal. A programmer approaching a problem from a functional perspective may well exploit the relational nature of an RDBMS to work smartly within the paradigm. (I've seen it done, and done very well and easily, in a way that's approachable even for relatively novice functional programmers.) Even if using an object-oriented style of programming, with the feature set of something like PostgreSQL--or SQL Server, if that's your bag--and the ability to very easily provide assurances around data integrity and correctness using the built-in tools, you have a very powerful and easy-to-use set of tools for building a rugged, correct data model. For product developers that do not find a cavalier approach to users' data to be acceptable, this can be a wise choice. Being fast and wrong is not always the right answer (and I personally consider it to usually be the wrong one). But it's even better to be fast and right, and that can quite obviously be done, in many cases, with a relational data store. And this may mean understanding how to write code in a style that doesn't necessarily use the Active Record pattern or a similar ORM. That's true. But that does not imply an inherent product development benefit to using such a tool (for their partisans), nor does the common reliance on these tools and its well-documented failures imply that the various NoSQL technologies are better at building a product.
- braz1970 11y ago
  Err no. It's great that you have just discovered functional programming but your claim that the data presented by a relational database is only unnatural for object oriented programming is absurd. When you join tables you get something like this: User1 firstname1 lastname1 role1 rolename1 User1 firstname1 lastname1 role2 rolename2 User1 firstname1 lastname1 role3 rolename3 This is purely a result of how the database works. That data is never presented to the user in that way. It has to be converted into a new form.

eropple 11y ago

> They are much closer to how we actually use data as a programmer. No, they're how you, as what sounds like a predominantly object-oriented programmer, use data. And that's fine, but don't pretend it's universal. A programmer approaching a problem from a functional perspective may well exploit the relational nature of an RDBMS to work smartly within the paradigm. (I've seen it done, and done very well and easily, in a way that's approachable even for relatively novice functional programmers.) Even if using an object-oriented style of programming, with the feature set of something like PostgreSQL--or SQL Server, if that's your bag--and the ability to very easily provide assurances around data integrity and correctness using the built-in tools, you have a very powerful and easy-to-use set of tools for building a rugged, correct data model. For product developers that do not find a cavalier approach to users' data to be acceptable, this can be a wise choice. Being fast and wrong is not always the right answer (and I personally consider it to usually be the wrong one). But it's even better to be fast and right, and that can quite obviously be done, in many cases, with a relational data store. And this may mean understanding how to write code in a style that doesn't necessarily use the Active Record pattern or a similar ORM. That's true. But that does not imply an inherent product development benefit to using such a tool (for their partisans), nor does the common reliance on these tools and its well-documented failures imply that the various NoSQL technologies are better at building a product.

braz1970 11y ago
Err no. It's great that you have just discovered functional programming but your claim that the data presented by a relational database is only unnatural for object oriented programming is absurd. When you join tables you get something like this: User1 firstname1 lastname1 role1 rolename1 User1 firstname1 lastname1 role2 rolename2 User1 firstname1 lastname1 role3 rolename3 This is purely a result of how the database works. That data is never presented to the user in that way. It has to be converted into a new form.