6 ms·

> Yes. It is, and the parent is saying why (despite the fact it had more features) it shouldn’t be treated as anything more than a nosql document store with mat

> Yes. It is, and the parent is saying why (despite the fact it had more features) it shouldn’t be treated as anything more than a nosql document store with mature replication. This is very unfair to innodb which is a mature enterprise level relational engine.

dijit 7y ago
InnoDB is very nice, especially when compared to myISAM. If this post only contained information regarding myISAM then there would be a lot to unpack and it would look like flaming. I think I’m being fair to innodb though. It’s not necessarily InnoDBs fault that it cannot handle schema changes in a transaction, or munges data if the column isn’t the right size, or that it fails a commit but overwrites data anyway. These are generally MySQL problems, and it doesn’t matter which storage engine you use.
- grumpydba 7y ago
  > or munges data if the column isn’t the right size Same behaviour as Ms sql server or sybase. Would you be so harsh with them? > it cannot handle schema changes in a transaction. Same behaviour for some cases on sql server and sybase. Also in MySQL 8 some schema changes are indeed atomic. You are being unfair as those limitations are perfectly fine to live with. > it fails a commit but overwrites data anyway. Please provide more information
  - dijit 7y ago
    Ugh, this is going to get tedious, you're obviously feeling defensive for some reason. Please try not to be. MSSQL does not munge data if the column is not equipped for it, I have no idea about sybase. You can test this easily by making an int column and putting a maxint+1 in.. it will tell you "NO" and not insert anything. MSSQL supports schema changes in transactions, fully, again, not sure about sybase. MySQL 8 might support it /sometimes/ but the major concern I had with this fact is that MySQL doesn't tell you it's going to break its transaction isolation. -- it just commits in the middle of your transaction and moves on. My final point is mitigated somewhat by MySQL "Strict" mode, which nobody enables. I have very limited internet but this video should explain/show the behaviour I'm referencing: https://www.youtube.com/watch?v=emgJtr9tIME https://www.youtube.com/watch?v=emgJtr9tIME
    - grumpydba 7y ago
      > MSSQL does not munge data if the column is not equipped for it, I have no idea about sybase. You can test this easily by making an int column and putting a maxint+1 in.. it will tell you "NO" and not insert anything. It does truncate strings.so does MySQL. But you need to enable strict mode. Easy. Mssql does allow ddl in transactions, but do not do it, you will have huge locking issues. It will also not work in snapshot isolation. My point stands: all major enterprise dbms have limitations. And you are dismissing MySQL, but by your standards Mssql and sybase would also be dismissed. This is unfair. You just need a semi competent dev to know those limitations. And MySQL with innodb is not that far from sql server or sybase.
      - dijit 7y ago
        > My point stands: all major enterprise dbms have limitations. And you are dismissing MySQL, but by your standards Mssql and sybase would also be dismissed. You are refuting a claim I never made. My issue is not with the limitations, these are a fact of life with any and all technology. My issue is with silent data corruption and subtle issues that break expectations Thus, requiring any user of the system to be fully versed in all the documentation and to be prescient enough at all times when interacting with the database. I can’t make such guarantees, and PostgreSQL follows the principle of least surprise much better. If I have two options and one of them has odd silent failure modes and the other holds your feet to the fire to ensure correctness. I will consistently choose the latter.
        grumpydba 7y ago
        > it shouldn’t be treated as anything more than a nosql document store with mature replication. This is the outrageous statement I was replying too. I get it, postgresql is your thing (I'm a postgresql dba BTW). However you are being excessive and unfair. You are just repeating a meme without having administered databases professionally. You need to study your database of choice. Postgresql or Mysql. Are you aware of postgresql's fsync bug ? Is postgresql more than a nosql database because of that ? > My issue is with silent data corruption and subtle issues that break expectations SQL server and sybase do truncate data too. Silently. Are they nothing more than nosql databases because of that ?
  - dang 7y ago
    Your comments in this thread crossed repeatedly into getting personal (taking the form 'you are this', 'you need to that', etc., and impugning someone else's level of knowledge). Would you please not do this when posting here? It isn't necessary, it's provocative and distracting, and indeed it provoked and distracted. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - grumpydba 7y ago
      Sorry but it seems necessary, PC principal.

dijit 7y ago

InnoDB is very nice, especially when compared to myISAM. If this post only contained information regarding myISAM then there would be a lot to unpack and it would look like flaming. I think I’m being fair to innodb though. It’s not necessarily InnoDBs fault that it cannot handle schema changes in a transaction, or munges data if the column isn’t the right size, or that it fails a commit but overwrites data anyway. These are generally MySQL problems, and it doesn’t matter which storage engine you use.

grumpydba 7y ago
> or munges data if the column isn’t the right size Same behaviour as Ms sql server or sybase. Would you be so harsh with them? > it cannot handle schema changes in a transaction. Same behaviour for some cases on sql server and sybase. Also in MySQL 8 some schema changes are indeed atomic. You are being unfair as those limitations are perfectly fine to live with. > it fails a commit but overwrites data anyway. Please provide more information
- dijit 7y ago
  Ugh, this is going to get tedious, you're obviously feeling defensive for some reason. Please try not to be. MSSQL does not munge data if the column is not equipped for it, I have no idea about sybase. You can test this easily by making an int column and putting a maxint+1 in.. it will tell you "NO" and not insert anything. MSSQL supports schema changes in transactions, fully, again, not sure about sybase. MySQL 8 might support it /sometimes/ but the major concern I had with this fact is that MySQL doesn't tell you it's going to break its transaction isolation. -- it just commits in the middle of your transaction and moves on. My final point is mitigated somewhat by MySQL "Strict" mode, which nobody enables. I have very limited internet but this video should explain/show the behaviour I'm referencing: https://www.youtube.com/watch?v=emgJtr9tIME https://www.youtube.com/watch?v=emgJtr9tIME
  - grumpydba 7y ago
    > MSSQL does not munge data if the column is not equipped for it, I have no idea about sybase. You can test this easily by making an int column and putting a maxint+1 in.. it will tell you "NO" and not insert anything. It does truncate strings.so does MySQL. But you need to enable strict mode. Easy. Mssql does allow ddl in transactions, but do not do it, you will have huge locking issues. It will also not work in snapshot isolation. My point stands: all major enterprise dbms have limitations. And you are dismissing MySQL, but by your standards Mssql and sybase would also be dismissed. This is unfair. You just need a semi competent dev to know those limitations. And MySQL with innodb is not that far from sql server or sybase.
    - dijit 7y ago
      > My point stands: all major enterprise dbms have limitations. And you are dismissing MySQL, but by your standards Mssql and sybase would also be dismissed. You are refuting a claim I never made. My issue is not with the limitations, these are a fact of life with any and all technology. My issue is with silent data corruption and subtle issues that break expectations Thus, requiring any user of the system to be fully versed in all the documentation and to be prescient enough at all times when interacting with the database. I can’t make such guarantees, and PostgreSQL follows the principle of least surprise much better. If I have two options and one of them has odd silent failure modes and the other holds your feet to the fire to ensure correctness. I will consistently choose the latter.
      - grumpydba 7y ago
        > it shouldn’t be treated as anything more than a nosql document store with mature replication. This is the outrageous statement I was replying too. I get it, postgresql is your thing (I'm a postgresql dba BTW). However you are being excessive and unfair. You are just repeating a meme without having administered databases professionally. You need to study your database of choice. Postgresql or Mysql. Are you aware of postgresql's fsync bug ? Is postgresql more than a nosql database because of that ? > My issue is with silent data corruption and subtle issues that break expectations SQL server and sybase do truncate data too. Silently. Are they nothing more than nosql databases because of that ?
- dang 7y ago
  Your comments in this thread crossed repeatedly into getting personal (taking the form 'you are this', 'you need to that', etc., and impugning someone else's level of knowledge). Would you please not do this when posting here? It isn't necessary, it's provocative and distracting, and indeed it provoked and distracted. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - grumpydba 7y ago
    Sorry but it seems necessary, PC principal.