4 ms·

I don't agree with these two points: | The database does not need round-the-clock availability (middle-of-the-night maintenance windows are no problem). Lots

I don't agree with these two points: | The database does not need round-the-clock availability (middle-of-the-night maintenance windows are no problem). Lots of SQL databases are part of 24/7 critical infrastructure. | Queries do not need to be particularly fast, they just need to return correct results eventually. Queries can be very fast if you predefine the correct indexes to suit the particular query. Only ad-hoc queries that you didn't plan for will be slow (sometimes). As it would be on any type of database.

gnaritas 17y ago
> Only ad-hoc queries that you didn't plan for will be slow Not true. If that were so denormalization wouldn't be a standard technique to speed up queries that join many tables and have to be really fast. The fact is SQL databases force you to reconstruct your document from many tables in a query and that is costly, even with indexes. It's simply much faster to not break the data up in the first place to fit it into a tables and rows data structure if speed is your primary concern. Storing a complex document, as is, will result in much faster retrieval. RDBM's are a tool, a damn fine tool, but like any tool, they're aren't the answer to every solution and far too many people pull out the RDBMS as the answer to every problem.
- mattmcknight 17y ago
  Except you just showed that normalization has performance tradeoffs, not that relational databases aren't a good solution. They offer you the flexibility to normalize or denormalize as the conditions demand. Of course they aren't the answer to every problem, and I think unstructured or semi-structured data (such as HTML pages or text data with entity tags) is a good case for storing things in a more document oriented system.
  - gnaritas 17y ago
    Normalization was just an example, the point was that joins are expensive. Even denormalized, you can't do much without joins for any complex data structure. Relational databases are always are good solution; however, they are not always the best solution for the problem at hand. The real problem is that once someone has their head wired to an RDBMS, it's often impossible to get them to even consider another solution. It becomes their golden hammer. The articles main point, that "SQL Databases Are An Overapplied Solution", is absolutely correct.
    - wvenable 17y ago
      "the point was that joins are expensive." That is a blatant myth. Joins are not slow.
      - trezor 17y ago
        They are in MySQL, which everyone here seems to be using despite everyone knowing it is the least performant database system out there.
        wvenable 17y ago
        I use MySQL and SQL Server everyday and there isn't a really huge difference in performance. And I'm working with large (100 line) queries over large sets of data trying to return real-time results. I've got more joins, subselects, and unions going on than the average user will ever use and I still return results instantly. Now older versions of MySQL, like 3.23, are still in use (unfortunately) and pretty crappy but it was released over 8 years ago. Most of these performance myths about MySQL are outdated.
        trezor 17y ago
        Last time I checked, and feel to correct me if I am wrong, MySQL used Row lookups when doing JOINs. There was no support for more efficient join algorithms like hash-join or merge-join, something which kills performance if you intend to run JOINs on a result/working-set bigger than just a few rows. Are there any improvements in this area, or is it still just the same old, same old?
      - gnaritas 17y ago
        They are when compared to no joins. Rebuilding a data structure is more expensive than not taking it apart in the first place.
        silentbicycle 17y ago
        Yes, but normalization is done to lean on the RDBMS's constraints to ensure the data is internally consistent, not for performance-related reasons. Similarly, keeping backups may waste storage space, but when you need them, you really need them, and it's too late to change your mind.
pavel_lishin 17y ago
> The database does not need round-the-clock availability (middle-of-the-night maintenance windows are no problem). Yeah, this is idiotic. This kind of thinking is why it sometimes took three days to register for classes in college, and why I couldn't check my account balance in the evening after I got home from work/class, why I sometimes couldn't search the library catalog... etc., etc. I can think of perhaps one of our clients who would be fine with their database being down for hours at a time at night. Maybe.

gnaritas 17y ago

> Only ad-hoc queries that you didn't plan for will be slow Not true. If that were so denormalization wouldn't be a standard technique to speed up queries that join many tables and have to be really fast. The fact is SQL databases force you to reconstruct your document from many tables in a query and that is costly, even with indexes. It's simply much faster to not break the data up in the first place to fit it into a tables and rows data structure if speed is your primary concern. Storing a complex document, as is, will result in much faster retrieval. RDBM's are a tool, a damn fine tool, but like any tool, they're aren't the answer to every solution and far too many people pull out the RDBMS as the answer to every problem.

mattmcknight 17y ago
Except you just showed that normalization has performance tradeoffs, not that relational databases aren't a good solution. They offer you the flexibility to normalize or denormalize as the conditions demand. Of course they aren't the answer to every problem, and I think unstructured or semi-structured data (such as HTML pages or text data with entity tags) is a good case for storing things in a more document oriented system.
- gnaritas 17y ago
  Normalization was just an example, the point was that joins are expensive. Even denormalized, you can't do much without joins for any complex data structure. Relational databases are always are good solution; however, they are not always the best solution for the problem at hand. The real problem is that once someone has their head wired to an RDBMS, it's often impossible to get them to even consider another solution. It becomes their golden hammer. The articles main point, that "SQL Databases Are An Overapplied Solution", is absolutely correct.
  - wvenable 17y ago
    "the point was that joins are expensive." That is a blatant myth. Joins are not slow.
    - trezor 17y ago
      They are in MySQL, which everyone here seems to be using despite everyone knowing it is the least performant database system out there.
      - wvenable 17y ago
        I use MySQL and SQL Server everyday and there isn't a really huge difference in performance. And I'm working with large (100 line) queries over large sets of data trying to return real-time results. I've got more joins, subselects, and unions going on than the average user will ever use and I still return results instantly. Now older versions of MySQL, like 3.23, are still in use (unfortunately) and pretty crappy but it was released over 8 years ago. Most of these performance myths about MySQL are outdated.
        trezor 17y ago
        Last time I checked, and feel to correct me if I am wrong, MySQL used Row lookups when doing JOINs. There was no support for more efficient join algorithms like hash-join or merge-join, something which kills performance if you intend to run JOINs on a result/working-set bigger than just a few rows. Are there any improvements in this area, or is it still just the same old, same old?
    - gnaritas 17y ago
      They are when compared to no joins. Rebuilding a data structure is more expensive than not taking it apart in the first place.
      - silentbicycle 17y ago
        Yes, but normalization is done to lean on the RDBMS's constraints to ensure the data is internally consistent, not for performance-related reasons. Similarly, keeping backups may waste storage space, but when you need them, you really need them, and it's too late to change your mind.

pavel_lishin 17y ago

> The database does not need round-the-clock availability (middle-of-the-night maintenance windows are no problem). Yeah, this is idiotic. This kind of thinking is why it sometimes took three days to register for classes in college, and why I couldn't check my account balance in the evening after I got home from work/class, why I sometimes couldn't search the library catalog... etc., etc. I can think of perhaps one of our clients who would be fine with their database being down for hours at a time at night. Maybe.