4 ms·

Apparently, it isn't PostgreSQL; If you have no need for Postgres features and you're not familiar with it, sticking to MySQL is fine.

by cbg0 14y ago

gbog 14y ago
Well you can say the same for windows vs Linux or visual basic vs any other language, and you can also continue using paper glue to attach paintings on the wall. It is not a matter of what you need, it is a matter of using good tools that will help you do good work, understand better what you do, build durable products, and so on. Just one example: MySQL will not complain if you add a check constraint but will not actually add it to your schema. That's a very Microsoft-y way to handle things, and should give cold sweat to any coder.
- cbg0 14y ago
  This is actually documented behavior: "The CHECK clause is parsed but ignored by all storage engines." From: http://dev.mysql.com/doc/refman/5.5/en/create-table.html http://dev.mysql.com/doc/refman/5.5/en/create-table.html I believe it was left to support certain migrations(?). You can create a trigger instead. I'm pretty certain many people will consider MySQL a good tool with which they produce good work. While it may have its quirks, it's present on virtually all shared hosting environments, just like PHP, so it's very easy to create and deploy an application powered by both these technologies.
  - gbog 14y ago
    So, you are telling me that it is a good thing, a normal behavior for a reliable tool to just ignore instructions I send to it and do nothing with it, not even a warning? So when I migrate a database, I have to carefully check each and every instructions (schema and data) and make sure MySQL did not "decide" it was not worth it and just silently threw it by the window? I have hard time to believe you are serious here...
    - cbg0 14y ago
      I'm pretty certain when you migrate from a different database you're supposed to check your schema and data anyway, or do you just "decide" it should work without question? I'm not saying this MySQL behavior is acceptable, I'm just saying that you should be aware of the limitations and quirks of the tools you work with.
      - emil0r 14y ago
        So it's not acceptable behaviour, yet we shouldn't point it because we should know it has this unacceptable behaviour? Doesn't make any sense to me I'm afraid.
geon 14y ago
MySQL was a lot worse before 2004 or so. It wouldn't do transactions, nor proper joins, if I remember correctly. I think the bad reputation still sticks to it.
- gbog 14y ago
  I won't talk for the others but for me the "bad reputation" is not because of missing features, it is because of a wrong handling of ambiguous cases. If you ask a (SQL) question to a database and your question is ill-formed, ambiguous, or meaningless, it is very dangerous for the database engine to try to guess your meaning and answer something. There are enough troubles with SQL (eg the Null debate) to add up to the mess by adding guesses.

Apparently, it isn't PostgreSQL; If you have no need for Postgres features and you're not familiar with it, sticking to MySQL is fine.

by cbg0 14y ago

Apparently, it isn't PostgreSQL; If you have no need for Postgres features and you're not familiar with it, sticking to MySQL is fine.

gbog 14y ago

Well you can say the same for windows vs Linux or visual basic vs any other language, and you can also continue using paper glue to attach paintings on the wall. It is not a matter of what you need, it is a matter of using good tools that will help you do good work, understand better what you do, build durable products, and so on. Just one example: MySQL will not complain if you add a check constraint but will not actually add it to your schema. That's a very Microsoft-y way to handle things, and should give cold sweat to any coder.

cbg0 14y ago
This is actually documented behavior: "The CHECK clause is parsed but ignored by all storage engines." From: http://dev.mysql.com/doc/refman/5.5/en/create-table.html http://dev.mysql.com/doc/refman/5.5/en/create-table.html I believe it was left to support certain migrations(?). You can create a trigger instead. I'm pretty certain many people will consider MySQL a good tool with which they produce good work. While it may have its quirks, it's present on virtually all shared hosting environments, just like PHP, so it's very easy to create and deploy an application powered by both these technologies.
- gbog 14y ago
  So, you are telling me that it is a good thing, a normal behavior for a reliable tool to just ignore instructions I send to it and do nothing with it, not even a warning? So when I migrate a database, I have to carefully check each and every instructions (schema and data) and make sure MySQL did not "decide" it was not worth it and just silently threw it by the window? I have hard time to believe you are serious here...
  - cbg0 14y ago
    I'm pretty certain when you migrate from a different database you're supposed to check your schema and data anyway, or do you just "decide" it should work without question? I'm not saying this MySQL behavior is acceptable, I'm just saying that you should be aware of the limitations and quirks of the tools you work with.
    - emil0r 14y ago
      So it's not acceptable behaviour, yet we shouldn't point it because we should know it has this unacceptable behaviour? Doesn't make any sense to me I'm afraid.

geon 14y ago

MySQL was a lot worse before 2004 or so. It wouldn't do transactions, nor proper joins, if I remember correctly. I think the bad reputation still sticks to it.

gbog 14y ago
I won't talk for the others but for me the "bad reputation" is not because of missing features, it is because of a wrong handling of ambiguous cases. If you ask a (SQL) question to a database and your question is ill-formed, ambiguous, or meaningless, it is very dangerous for the database engine to try to guess your meaning and answer something. There are enough troubles with SQL (eg the Null debate) to add up to the mess by adding guesses.