8 MySQL traps that have to be said

MySQL installation is simple, fast, feature-rich. It is also the benchmark for open source movement, and its great achievements show us that a successful company can be built on open source code.
However, people who used MySQL had waved their fists at the monitor. But you can't invent a technology that can save thousands of Internet data per second, without a single mistake.
To get up this summer, we've listed 8 reasons to complain about open source relational databases. The reasons listed below are not limited to MySQL, but some are for relational databases. If we don't figure out the relational database and MySQL, we'll always be in the 90 's. We need to pull it down and rebuild that. Or we turn to use a recently popular, time-to-exist database that can list a bunch of reasons like the following.
Deep-rooted bugs
There are bugs in any big package. But a bit more in-depth, you will find and Mysql-related bugs self-made system. Suddenly you need to be mindful, because NULL does not appear in the same way, the foreign KEY constraint is not executed as you think, and even the automatic growth of the primary key will go wrong.
Small problems exist in large numbers and are not always repairable, which is why some people keep a list. Fortunately, MySQL maintains a very good bug reporting system so that we can know what we can't imagine, and know that others are suffering the same.
non-flexibility of relational tables

Relational tables are logical and methodical-but they make it possible for programmers to fabricate or hard-plug some data into columns that already have a pattern defined. One of the reasons for the growing popularity of NoSQL is that it gives programmers enough flexibility to accelerate the use of databases. If a street address needs an additional line, you can easily insert it into a NoSQL document. If you want to add a complete new block of data, no matter what it contains, the document model can accept your data unchanged without having to change the data format it requires.
Imagine that you created a full-zip form in integer format. The table is very efficient and the rules are good to execute. All of a sudden, someone uploaded a nine-digit zip code that used a hyphen. Or maybe, you got a letter from a Canadian customer with a zip code on it.
At this time, everything was messed up. The boss asked the website to return to normal work within a few hours. However, there is no time to rebuild the database now. What can programmers do? Maybe you can use hacking to change the Canadian zip code from Base64 to base 10 format? or set up a secondary form that uses escape encoding to illustrate the actual zip code or other? Who knows? There are hackers everywhere, and they are all dangerous. But you don't have time to fix it.
MySQL's Association rules make everyone honest and cautious, but it can force us to avoid the hassle of being vulnerable to attack and deception.
Join Union Query

Once upon a while, storing data in tables was a great innovation in the history of computer science. The separated table is not only simple in structure, but also simplifies its use. However, it needs to be queried using the join statement.
SQL's complex queries built through a series of joins push developers into the abyss of confusion and despair. and the storage engine needs an optimal way to parse the join statement efficiently. Developers need to rack their brains to write query statements, and then the database parses them.
This is why a lot of developers who pay attention to the speed of operation abandon the data table instead of using the nonstandard data tables. Do not differentiate between data entities and save all data to a large table--to avoid complex queries. This is really fast, and the server does not run out of memory.
Disk space is now cheap. 8TB of disk is already on sale, the bigger also wants to go public. We no longer have to work our brains out to use join.
the chaos of the branch

Yes, a reliable, well-supported MySQL branch can bring competition and choice, but it also causes confusion and confusion. Worse, a MySQL branch called MARIADB is maintained by Monty Widenius. He is also involved in writing MySQL. So, is mariadb truly independent and worthy of our support? Or is it mysql? Should we stick to the core code that was run by the organization that created the original MySQL database? Or should we join those who are thought to be smarter, often cool traitors?
Also, how do we get information about compatibility? On the one hand, we are convinced that MARIADB is very similar to MySQL. On the other hand, we have to believe in differences-why else are we arguing about it? Maybe they work the same way in two camps, in the range of performance and our queries? But maybe they're different-or they'll be different in the future.
Storage Engine Clutter

MySQL is not actually the same database; It consists of several databases, and most of their details are masked by a unified surface. At the beginning, there was a MyISAM engine, which soon but could not be completed in a coherent. Sometimes it's good that you need speed and can accept inconsistent results.
When people need more, InnoDB with full transaction support appears. But that's not enough. Now it may have 20 options for the storage engine-enough to make a database administrator crazy. Of course, sometimes it's nice to switch between different storage engines without having to rewrite your SQL, but there's always confusion after switching. This table is the engine I choose is MyISAM or InnoDB? Or, do I decide that the output data is in CSV format?
Motive for profit
Although MySQL is a successful open-source product, it is still a business, full of professional developers who get paid by it. While most users continue to enjoy the best possible experience from an open source license, the company is no doubt struggling to earn enough money to keep it running. This leads to a strange divergence between the "Community Edition" and the complete product sold to the enterprise by the free code.
Should you pay for it? How much money have you earned here? Is it fair to conduct business on the Community edition? is the extra feature in the Enterprise Edition just a gimmick to entice us to keep paying? This, at least, illustrates that it is another set of questions that need to be answered. Which version do you choose? What kind of license is followed? Which feature set does it use?
lack of native JSON support

The best way to look at the age of MySQL is to install it, and then you will realize that you need to add more drivers to make it available. MySQL usually communicates on port 3306, and it generally outputs formatted data that it is difficult to understand. If you want your code to communicate with it, you have to add another layer of code that translates the MySQL language into something useful. These layers of code, distributed as libraries, often require people to purchase a commercial license.
Modern data storage tiers typically communicate directly with JSON. While MySQL and MariaDB now have the ability to parse the JSON portion of SQL, this is far from good enough that native JSON interfaces are already widely used in Couchdb,mongodb, or any of the latest tools.
The rise of closed sources and proprietary modules

Did I say that MySQL is open source? It is, but in addition to some of the newer, non-open source code, proprietary modules developed around the "open source core". Programmers need to eat, and Oracle needs to make money with its hard work, which is one of the business realities. It's not like those hospitals that use MySQL to get free medical care. It is not like those farmers who use MySQL to give away food.
Requiring MySQL to always stick in a very high standard is a bit unfair, because the success of open source may be a trap. This is because it starts to be free, but does not mean it can always be so. If businesses need many new features, they will have to pay for it in one way or another. Sometimes paying Oracle is much cheaper than writing your own code. Sometimes commercial, non-open source code is meaningful. The truth goes without saying.

English Original: http://www.pcadvisor.co.uk/news/software/8-mysql-gotchas-worth-a-rant-3620577/

8 MySQL traps that have to be said