Shulou(Shulou.com)05/31 Report--

This article will share with you about the reasons for not using MySQL. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

What are the reasons for not using MySQL

First of all, the reason for not using a technology is essentially different from the reason for using it. Often, the reasons for opposing something attract more attention. We may need several reasons to actually use this technology, but only one reason will stop us. The choice of software is such a decision, only one reason is that it is not enough to motivate us to make a positive decision, but a good negative reason will negate many positive factors.

Although there is a long list of relational database management systems (RDBMS) to choose from, I will limit the comparison to a few of the most commonly used products. Although there are few comprehensive comparisons, there are still many technical comparisons. Here, we are only concerned with "formal" reasons.

MySQL uses GPL

The most important reason comes first. It is not suitable for GNUGeneralPublicLicense here, and it should not be the choice of database technology. Obviously, GPL licenses are positive for many environments, but for others, GPL software is hopeless. In these cases, even if the PostgreSQL BSD license is still too "open", then a commercial license will be more suitable.

MySQL does not use GPL

In some cases, MySQL is charged, so GPL may not serve these situations very well. If you want to sell the license for this database with your own project, your project must use a similar license, or you need to buy a commercial license. If this factor changes the way your software is sold, you need to deal with the additional burden caused by having to support multiple versions or configurations of MySQL (which increases costs for end users), or the unreasonable impact caused by the use of MySQL. In these cases, some software distributors may prefer to adopt other products, such as PostgreSQL under the BSD license.

Integration with existing environment

I know that large IT companies will have unit software use rights (SiteLicense) for Oracle and Sybase, as well as many proprietary licenses for MS-SQLServer (specificlicense). In these companies, examples of such MS-SQL are mainly caused by ignorant employees of various departments who do not know that they have spent money on the sitelicense of other databases. In this environment, it would be unwise to add MySQL (or other databases) if DBA already has too many environments to deal with. In the case of an existing database, if you are maintaining a general-purpose platform, it is obvious that the maintenance burden will be reduced. Further, if the company already has a license to use a proprietary system, the main reason for using MySQL does not exist.

Maturity of the product

By comparison, Oracle will celebrate the 30th anniversary of its first product release in 2009, when MySQL's first product was released less than half as long as Oracle. For its part, MicrosoftSQLServer is only a few years ahead of MySQL, but its first release is based on Sybase, which is six years ahead of SQLServer. As for other well-known open source databases, it has been 20 years since PostgreSQL was first released in 2009. While MySQL is not the latest database on the market, there are many older, more stable options-and for many people, that's good enough. To be fair, in my opinion, this is not a particularly good reason to oppose the use of MySQL, but at the same time, I was forced to tell a conservative IT manager who will choose a platform for mission-critical applications that it would be wrong to make a decision for this reason.

Maturity of the feature set

Some people are attracted to edit comprehensive functional comparisons between MySQL and other systems as an authoritative decision-making tool, but in many cases it is impossible to succeed at all. With the release of new versions or patches from various vendors, this list of features quickly becomes obsolete. Furthermore, functions that are important to some applications have nothing to do with other applications, so "10% more functions" will be a measure of no results. What really works is whether the feature set is consistent or sufficiently consistent with the requirements at the time of release.

Sometimes, you can bypass some missing features, such as using join instead of subqueries in the MySQL4.1 version. Most of the necessary functions in RDBMS are implemented in MySQL5.0, but there is still reason to think that the maturity of these functions is a possible reason to avoid MySQL. For example, the lack of views, triggers, and stored procedures is a long-standing criticism of MySQL. These have been supported by MySQL for more than a year, but by contrast, these features have been around for more than 10 years in other RDBMS.

Of course, the MySQL team's development cycle is impressive in many ways. However, if the user's character is to reject new technologies, the features that have been supported for a long time are more likely to win. In this case, the three main functions mentioned above were added just a few days ago. Even in MySQL5.0, the consistency of ACID (Atomicity,Consistency,Isolation,Durability) cannot be guaranteed when some stored procedures or functions are used to modify the database and cause a panic.

Availability of certification

There are some IT companies that like certification. Although MySQL does have a certification training program, its training availability is not as extensive as Oracle or MS-SQLServer. In a broad sense, even though MySQL IT personnel are relatively easy to find, there is still little certification or training, and there is not much third-party training available. It is also necessary for large IT companies to follow the actual corporate experience of commercial database systems, but some people with MySQL experience may not have enough depth.

Another related issue is the availability of support from qualified third parties. Although support services directly from vendors can solve this problem to some extent, this problem still exists if there is a strong need for local on-site support from third parties.

Consideration of company factors

Oracle, Sybase and Microsoft are all listed companies. Whatever the strength of MySQL's backers, the fact is that the company is not a listed company, which means that financial data need not be disclosed according to the law. At the risk of being accused of spreading FUD (fear, confusion, doubt, Fear,UncertaintyandDoubt), the relative transparency of listed companies (whether correct or not) can provide some certainty, reliability and security to some IT managers and their reported superiors. As an old saying goes, no one gets fired for buying IBM products, and the same applies here (even though IBM decided to sell MySQL a few days ago); using products from famous companies does help some people sleep at night, they are investors, PHB (Dilbertreference:Pointy-HairedBosses) and experienced IT managers.

Understanding of scalability

I named this last reason very carefully. Many experts in the industry have a consistent perception that MySQL can not be well extended. This issue has been discussed by many people, although most of the discussions tend to eliminate the difference between horizontal and vertical expansion. MySQL talks about horizontal scaling more often than vertical scaling, but lists scalability as one of the main reasons for using MySQL.

What are the reasons for not using MySQL

At the same time, I noticed that there is a trend, but I do not have reliable data to support this trend, that is, formally trained DBA tend to choose private RDBMS, such as Oracle. I suspect that DBA with formal training and experience (rather than software engineers) tends to have a preference for proprietary systems. In environments where DBA is assigned a fixed role (as opposed to a part-time consultant or someone who is also a programmer), MySQL may fall out of favor for this reason. At this level, it doesn't matter whether MySQL's extensibility is a real or imaginary criticism. If there is no good reason to subvert this factor, when you are in charge of arranging resources, you want to give them the tools they like best and bring benefits. If your DBA with 15 years of experience wants Oracle and Oracle is within budget, this approach will pay off in the long run.

At this point, when comparing several stable, mature, feature-rich products, people can no longer worry about which is the absolute "better" product. This question should be replaced by a question that requires more insight: which product is best suited to a given environment. I think all major RDBMS products will encounter this problem, including MySQL. The question of when this happens may be open to some products, and these products are also welcome to discuss this issue. I can say that every product has a special moment that is not applicable, and this is the pattern today, which is the same for any major system. In the case of MySQL, I believe we have mentioned some of the strongest reasons-these reasons will not be an one-shot deal, nor will they become out of date soon.

Thank you for reading! This is the end of this article on "what are the reasons for not using MySQL?". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.