5 ms·

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

> 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 ?
  - 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.
    - 7y ago

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 ?
- 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.
  - 7y ago