4 ms·

This is cool but the problem is you're on MySQL

by TedShiller 4y ago

osrec 4y ago
Why is that a problem?
- TedShiller 4y ago
  Everyone is moving away from MySQL to Postgres
  - endisneigh 4y ago
    Do you have any data supporting this assertion?
    - TedShiller 4y ago
  - paxys 4y ago
    "Everyone" except all the largest and most successful companies in the world.
    - samlambert 4y ago
      This.
      - TedShiller 4y ago
    - bpodgursky 4y ago
      The largest and mot successful companies in the world are still powered by MapReduce. It doesn't mean it's a great technology anymore... it just means it's incredibly hard to migrate tech stacks once you're a huge and successful company.
      - signatoremo 4y ago
        I suppose you meant Hadoop. What have changed that makes it not a great technology any more?
        saberience 4y ago
        Hadoop means HDFS plus MapReduce and/or Yarn. Hadoop isn't some specific technology or tool you install, it's an ecosystem of tools.
        bpodgursky 4y ago
        "Hadoop" is never going to die. Even if it fades into the background, some vestigial remnant within Spark will use a HDFS wrapper to access S3 or something like that. But MapReduce will eventually, finally, kick the can.
    - TedShiller 4y ago
      Everyone, including the largest and most successful companies in the world
      - white_dragon88 4y ago
        Source? Or did you just pull that factoid from your imagination?
        TedShiller 4y ago
        I don't have any imagination
        deleted 4y ago
        [deleted]
- KronisLV 4y ago
  > Why is that a problem? I feel like this will inevitably lead to some not-very-productive discussions, as it already seems to have started in some sibling comments. Personally, I have to admit that there's definitely a trend of looking more in the direction of PostgreSQL, which is a pretty great choice - it follows SQL standards pretty well, has adequate performance, advanced procedural language with support for custom types and even nice projects like PostGIS, which let you work with geospatial data (previewing which is even integrated in pgAdmin). In addition, it has support for JSON (though personally I find the syntax uncomfortable) and other plugins as well, whilst being able to scale both up and down pretty far. That said, I still think that MySQL/MariaDB is a sensible choice for lots of use simpler use cases, where you don't necessarily need custom types and advanced in-database processing with procedural languages (which in my opinion can be risky to begin with, mostly due to challenges in regards to testing and debugging such logic, outside of cases where you need to process a large amount of data and sending it over the network would be disastrous). MySQL/MariaDB has a simpler structure (databases and users, instead of databases, schemas and users), good performance, very good driver support, excellent tooling (in my opinion, MySQL Workbench is ahead of pgAdmin, especially reverse/forward engineering and the whole ER visualization functionality), passable resource usage (a bit more RAM at idle and under load than PostgreSQL in my experience, at least with default container setup which you may/may not want to alter) and a nice ecosystem around it - be it clustering solutions or integrations with almost any language that you might want to use. Also, projects like TiDB are interesting to behold, even though personally I wouldn't want to give up foreign key support for dynamic clustering. At the end of the day, I think that either is a better choice than being stuck with Oracle which just feels more cumbersome and isn't as easy to run wherever you need it, licensing being a concern all of the sudden (and Oracle XE not letting you use certain features either, such as dynamic indices, which you might want to test on your dev environment/locally). Also, the modelling functionality on SQL Developer leaves a lot to be desired. Cannot really comment on the SQL Server offering, because haven't worked a lot with it. For anyone who's on the fence about what RDBMS to use, just pick whatever looks interesting from the top 10-20 here, do some benchmarks, read what others have said and come to your own conclusions for any given project: https://db-engines.com/en/ranking https://db-engines.com/en/ranking It's hard to go absolutely wrong nowadays with any of the popular technologies (that have proven that they can survive for a decade or longer and still receive updates), unless you really misinterpret what would be a reasonable fit for a given workload.
chinabot 4y ago
I'm sure you could find some edge-case scenarios YOU dont like with MySQL but all round its a pretty sensible and stable choice if thats what you want to work with.
- paulryanrogers 4y ago
  IDK that rename-table corruption bug was brutal around 8.14 or so. Configured properly (legacy defaults were kind of janky) and only running vetted versions is probably OK.
aaaaaasss 4y ago

This is cool but the problem is you're on MySQL

osrec 4y ago

Why is that a problem?

TedShiller 4y ago
Everyone is moving away from MySQL to Postgres
- endisneigh 4y ago
  Do you have any data supporting this assertion?
  - TedShiller 4y ago
- paxys 4y ago
  "Everyone" except all the largest and most successful companies in the world.
  - samlambert 4y ago
    This.
    - TedShiller 4y ago
  - bpodgursky 4y ago
    The largest and mot successful companies in the world are still powered by MapReduce. It doesn't mean it's a great technology anymore... it just means it's incredibly hard to migrate tech stacks once you're a huge and successful company.
    - signatoremo 4y ago
      I suppose you meant Hadoop. What have changed that makes it not a great technology any more?
      - saberience 4y ago
        Hadoop means HDFS plus MapReduce and/or Yarn. Hadoop isn't some specific technology or tool you install, it's an ecosystem of tools.
      - bpodgursky 4y ago
        "Hadoop" is never going to die. Even if it fades into the background, some vestigial remnant within Spark will use a HDFS wrapper to access S3 or something like that. But MapReduce will eventually, finally, kick the can.
  - TedShiller 4y ago
    Everyone, including the largest and most successful companies in the world
    - white_dragon88 4y ago
      Source? Or did you just pull that factoid from your imagination?
      - TedShiller 4y ago
        I don't have any imagination
        deleted 4y ago
        [deleted]
KronisLV 4y ago
> Why is that a problem? I feel like this will inevitably lead to some not-very-productive discussions, as it already seems to have started in some sibling comments. Personally, I have to admit that there's definitely a trend of looking more in the direction of PostgreSQL, which is a pretty great choice - it follows SQL standards pretty well, has adequate performance, advanced procedural language with support for custom types and even nice projects like PostGIS, which let you work with geospatial data (previewing which is even integrated in pgAdmin). In addition, it has support for JSON (though personally I find the syntax uncomfortable) and other plugins as well, whilst being able to scale both up and down pretty far. That said, I still think that MySQL/MariaDB is a sensible choice for lots of use simpler use cases, where you don't necessarily need custom types and advanced in-database processing with procedural languages (which in my opinion can be risky to begin with, mostly due to challenges in regards to testing and debugging such logic, outside of cases where you need to process a large amount of data and sending it over the network would be disastrous). MySQL/MariaDB has a simpler structure (databases and users, instead of databases, schemas and users), good performance, very good driver support, excellent tooling (in my opinion, MySQL Workbench is ahead of pgAdmin, especially reverse/forward engineering and the whole ER visualization functionality), passable resource usage (a bit more RAM at idle and under load than PostgreSQL in my experience, at least with default container setup which you may/may not want to alter) and a nice ecosystem around it - be it clustering solutions or integrations with almost any language that you might want to use. Also, projects like TiDB are interesting to behold, even though personally I wouldn't want to give up foreign key support for dynamic clustering. At the end of the day, I think that either is a better choice than being stuck with Oracle which just feels more cumbersome and isn't as easy to run wherever you need it, licensing being a concern all of the sudden (and Oracle XE not letting you use certain features either, such as dynamic indices, which you might want to test on your dev environment/locally). Also, the modelling functionality on SQL Developer leaves a lot to be desired. Cannot really comment on the SQL Server offering, because haven't worked a lot with it. For anyone who's on the fence about what RDBMS to use, just pick whatever looks interesting from the top 10-20 here, do some benchmarks, read what others have said and come to your own conclusions for any given project: https://db-engines.com/en/ranking https://db-engines.com/en/ranking It's hard to go absolutely wrong nowadays with any of the popular technologies (that have proven that they can survive for a decade or longer and still receive updates), unless you really misinterpret what would be a reasonable fit for a given workload.

chinabot 4y ago

I'm sure you could find some edge-case scenarios YOU dont like with MySQL but all round its a pretty sensible and stable choice if thats what you want to work with.

paulryanrogers 4y ago
IDK that rename-table corruption bug was brutal around 8.14 or so. Configured properly (legacy defaults were kind of janky) and only running vetted versions is probably OK.

aaaaaasss 4y ago