4 ms·

> 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,

> 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 ?

dijit 7y ago
You've made a few comments about me here which I feel are undeserved, if you knew me you would not assume I am "repeating a meme", I am a classically trained sysadmin, not historically a coder, and I've been the bastion of data consistency in a few very high transaction/heavy database driven companies and I've been in the industry close to 15 years now. -- incidentally the only time I lost data was due to silent corruption bugs in the application or as a discovery made after inheriting a MySQL 5.1 cluster. My choice of database technology is driven by industry experience, not fanboyism (many who know me, know that I fought very hard against the fad of mongodb, for instance). And it's true I prefer PostgreSQL these days, mostly because the only time it's ever bitten me was with the autovacuum and that was all the way back in postgresql 8.2! It's possible I'm incompetent, but I'd rather not go into a slinging match about competency right now. I am aware of postgresql's fsync bug, but that's not _at all_ comparable to: defined, documented behaviour in a database engine. Yes, bugs happen and bugs are bad, but what the grandparent stated was absolutely not a bug, it's documented behaviour, it's known behavior and it's only _just_ becoming addressed and only in the loosest of terms (incidentally as programmer mindshare is starting to focus on alternatives). FWIW, I personally believe that MySQL and its ilk should be relegated to legacy applications, I do not hold it as fact that there's a cojent reason to choose it for a new project even as a NOSQL solution unless a few things are true: 1) All your developers only know MySQL and MySQL specifics (as in, you're a pure mysql shop and you know it very well) 2) You already have a product built on MySQL, it's costly to move. 3) You are the people who are building/designing mysql and trying to compete with more competent database engines. You bring up truncation of strings, but I was talking primarily about ints/floats. As a person who has 'dba' in his name you've made a lot of claims disparaging MSSQL, some of them I told you that you were wrong about and you agreed; but I am fairly certain that MSSQL does not truncate a string on insert. I'm going to test this claim. EDIT:: Sorry it took me an hour to install MSSQL on my laptop, I'm on vacation in Russia and internet here is hard to come by. Anyway: MSSQL does not silently insert varchars. #> create table #sometable(acolumn varchar(8)) #> insert into #sometable(acolumn) values('blah blah blah way more than 8 chars') Msg 8152, Level 16, State 14, Line 7 String or binary data would be truncated. `select *` shows no new rows, which is what I would expect.
- grumpydba 7y ago
  It all depends on the ANSI_WARNINGS switch. Some clients set it, some don't. Thus you have to be explicit or you might have a NoSQL database. You should also read about arithabort and arithignore. As I told you, you need to study the database engine you are using. For Mssql too. So you assumed it's always on. The type of mystake some non diligent devs do with MySQL. Gives it an undeserved bad rep. A dba can help you and teach you the nuances. Ask them at your company. There have been a considerable amount of efforts made to improve innodb. It's plenty fast and properly used, it's well behaved. Just like Mssql.
  - jhanschoo 7y ago
    You are talking past the person you are replying to. Parent comment points out that MySQL has quirks that helps you shoot yourself in the foot moreso than other engines. Eventually you will slip up, no matter how diligent you are. The argument is that it's easier to slip up and with more frequency in MySQL, so when faced with a choice there are safer alternatives.
    - grumpydba 7y ago
      > Parent comment points out that MySQL has quirks that helps you shoot yourself in the foot moreso than other engines. It used to be true. Not so much anymore. Study the defaults on mysql 8.
      - krageon 7y ago
        To summarise: Broadly the grandparent is correct, but some of his problems have been addressed in a very new version of the database in question. Is that fair?
        grumpydba 7y ago
        Most of the "problems" also exist in enteprise scale database server such as sql server and sybase. If parent meant that sql server and sybase are no more than nosql data store, I beg to differ. Those issues have been "fixable" in innodb for years using flags. This is getting old. I think people come in here to have accurate information.
breakingcups 7y ago
SQL Server does not truncate data silently, it errors out with "String or binary data would be truncated."

dijit 7y ago

You've made a few comments about me here which I feel are undeserved, if you knew me you would not assume I am "repeating a meme", I am a classically trained sysadmin, not historically a coder, and I've been the bastion of data consistency in a few very high transaction/heavy database driven companies and I've been in the industry close to 15 years now. -- incidentally the only time I lost data was due to silent corruption bugs in the application or as a discovery made after inheriting a MySQL 5.1 cluster. My choice of database technology is driven by industry experience, not fanboyism (many who know me, know that I fought very hard against the fad of mongodb, for instance). And it's true I prefer PostgreSQL these days, mostly because the only time it's ever bitten me was with the autovacuum and that was all the way back in postgresql 8.2! It's possible I'm incompetent, but I'd rather not go into a slinging match about competency right now. I am aware of postgresql's fsync bug, but that's not _at all_ comparable to: defined, documented behaviour in a database engine. Yes, bugs happen and bugs are bad, but what the grandparent stated was absolutely not a bug, it's documented behaviour, it's known behavior and it's only _just_ becoming addressed and only in the loosest of terms (incidentally as programmer mindshare is starting to focus on alternatives). FWIW, I personally believe that MySQL and its ilk should be relegated to legacy applications, I do not hold it as fact that there's a cojent reason to choose it for a new project even as a NOSQL solution unless a few things are true: 1) All your developers only know MySQL and MySQL specifics (as in, you're a pure mysql shop and you know it very well) 2) You already have a product built on MySQL, it's costly to move. 3) You are the people who are building/designing mysql and trying to compete with more competent database engines. You bring up truncation of strings, but I was talking primarily about ints/floats. As a person who has 'dba' in his name you've made a lot of claims disparaging MSSQL, some of them I told you that you were wrong about and you agreed; but I am fairly certain that MSSQL does not truncate a string on insert. I'm going to test this claim. EDIT:: Sorry it took me an hour to install MSSQL on my laptop, I'm on vacation in Russia and internet here is hard to come by. Anyway: MSSQL does not silently insert varchars. #> create table #sometable(acolumn varchar(8)) #> insert into #sometable(acolumn) values('blah blah blah way more than 8 chars') Msg 8152, Level 16, State 14, Line 7 String or binary data would be truncated. `select *` shows no new rows, which is what I would expect.

grumpydba 7y ago
It all depends on the ANSI_WARNINGS switch. Some clients set it, some don't. Thus you have to be explicit or you might have a NoSQL database. You should also read about arithabort and arithignore. As I told you, you need to study the database engine you are using. For Mssql too. So you assumed it's always on. The type of mystake some non diligent devs do with MySQL. Gives it an undeserved bad rep. A dba can help you and teach you the nuances. Ask them at your company. There have been a considerable amount of efforts made to improve innodb. It's plenty fast and properly used, it's well behaved. Just like Mssql.
- jhanschoo 7y ago
  You are talking past the person you are replying to. Parent comment points out that MySQL has quirks that helps you shoot yourself in the foot moreso than other engines. Eventually you will slip up, no matter how diligent you are. The argument is that it's easier to slip up and with more frequency in MySQL, so when faced with a choice there are safer alternatives.
  - grumpydba 7y ago
    > Parent comment points out that MySQL has quirks that helps you shoot yourself in the foot moreso than other engines. It used to be true. Not so much anymore. Study the defaults on mysql 8.
    - krageon 7y ago
      To summarise: Broadly the grandparent is correct, but some of his problems have been addressed in a very new version of the database in question. Is that fair?
      - grumpydba 7y ago
        Most of the "problems" also exist in enteprise scale database server such as sql server and sybase. If parent meant that sql server and sybase are no more than nosql data store, I beg to differ. Those issues have been "fixable" in innodb for years using flags. This is getting old. I think people come in here to have accurate information.

breakingcups 7y ago

SQL Server does not truncate data silently, it errors out with "String or binary data would be truncated."