共计 3349 个字符，预计需要花费 9 分钟才能阅读完成。
这篇文章给大家分享的是有关不使用 MySQL 的理由有哪些的内容。丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，一起跟随丸趣 TV 小编过来看看吧。
不使用 MySQL 的理由有哪些
首先，不使用某种技术的理由和使用这个技术的理由在本质上不同。常常，反对某些东西的理由会更加让人注意。我们可能需要几条理由才会真正的使用这个技术，但是只要一个理由就会让我们止步。软件的选择就是这样的决定，仅有一个理由是决不足够促使我们做出肯定的决定，但是一个充分的负面理由会否定很多积极的因素。
虽然有一长串关系数据库管理系统 (RDBMS) 可以供我们选择，但是我将对比限制在几个最常用的产品上。虽然全面的对比很少，还是存在着很多技术上的比较。在这里，我们只关心“正规”理由。
MySQL 使用 GPL
最重要的理由优先。在这里并不适合 GNUGeneralPublicLicense，并且也不应该是数据库技术的选择。很明显，GPL 许可证对很多环境是积极的，但是对于其他一些环境，GPL 的软件是没有希望的。在这些情况下，连 PostgreSQL 的 BSD 许可证仍然太“开放”，那么一个商业的许可证会更加适合。
MySQL 不使用 GPL
在一些情况下，MySQL 是收费的，这样 GPL 可能不能很好的服务于这些情况。如果你想要将这个数据库的许可证和你自己的项目一起销售，你的项目一定要采用相似的许可证，或者你需要购买商业许可证。如果这个因素改变了你的软件的销售方式，你需要处理由于必须支持 MySQL 的多个版本或者配置而引起的额外的负担(这会增加终端用户的成本)，或者存在由于 MySQL 的使用造成的不合理的影响。在这些情况下，一些软件分销商可能倾向于采用其他的产品，比如 BSD 许可证的 PostgreSQL。
和现有环境的集成
我知道大型的 IT 公司会有 Oracle 和 Sybase 的单位软件使用权 (SiteLicense)，以及很多 MS-SQLServer 的专有许可证(specificlicense)。在这些公司中，这种 MS-SQL 的实例主要是各部门的无知职员造成的，他们不知道他们已经花钱购买了其他数据库的 sitelicense。在这种环境下，再加入 MySQL(或者其他的数据库) 是不明智的想法，如果 DBA 已经有太多环境需要处理。在存在已有数据库的情况下，如果维护的是一个通用的平台，那么很明显维护的负担会降低。进一步，如果这个公司已经有了使用某个私有系统的许可证，那么使用 MySQL 的主要理由就不存在了。
产品的成熟度
通过比较，在 2009 年 Oracle 将庆祝它的第一个产品发布了 30 周年，那时 MySQL 第一个产品的发布时间还不到 Oracle 的一半。单就自身而言，MicrosoftSQLServer 仅仅比 MySQL 早了几年，但是它的第一次发布的产品是基于 Sybase 的，该产品的比 SQLServer 早了 6 年。至于其他著名的开源数据库，在 2009 年 PostgreSQL 距离第一次发布已经 20 年。虽然 MySQL 并不是市场上最新的数据库，但是还有很多更老、更稳定的可选产品——并且对很多人来说，这个理由已经足够了。公平的讲，以我的观点这个理由并不是反对使用 MySQL 的特别充分的理由，但是同时，我被逼着告诉一位将为关键任务的应用选择平台的保守 IT 经理基于这个理由作决定将是错误的。
功能集的成熟度
有些人被吸引去编辑 MySQL 和其他系统的全面的功能比较，以此作为权威的决策工具，但是在很多情况下，这根本就不可能成功。随着各个厂商新版本或者补丁的的发布，这个功能列表很快变得过时。进一步，对某些应用很重要的功能和其他的应用一点关系都没有，这样“10% 更多的功能”将是没有结果的度量。真正发挥作用的是在发布的时候功能集是否和需求一致，或者足够一致。
有时候，你可以绕过一些缺少的功能，比如 MySQL4.1 版本中使用 join 替代子查询。RDBMS 中大部分的必要的功能都在 MySQL5.0 中实现，但是我们仍然有理由认为这些功能的成熟是避开 MySQL 的一个可能的理由。比如，缺乏视图、触发器和存储过程是对 MySQL 由来已久的批评。这些都被 MySQL 支持超过一年时间了，但是相比之下，在其他的 RDBMS 中这些功能已经存在超过 10 年了。
当然，MySQL 团队的开发周期在很多方面都给人留下了深刻的印象。然而，如果用户的性格是排斥新技术，那么长期支持的功能获胜的概率会更大。在这种情况下，上面提到的三个主要的功能就是日前才加入的。即使在 MySQL5.0 中，ACID(Atomicity,Consistency,Isolation,Durability)的一致性在当一些存储过程或者函数被用于修改数据库而造成死机的情况下还是无法保证的。
认证的可用性
有一些 IT 公司喜欢认证。虽然 MySQL 的确有一个认证培训计划，它的培训可用性还是没有 Oracle 或者 MS-SQLServer 那样广泛。广义上讲，即使 MySQL 的 IT 人员相对容易找到，但是认证或者培训仍然很少，也没有很多第三方的培训可用。对于大的 IT 公司而言，遵循商业数据库系统的实际的公司经验也是需要的，但是一些具有 MySQL 经验的人可能没有足够的深度。
另外一个相关的问题是合格的第三方的支持的可用性。虽然直接从厂商得到的支持服务能够在一定程度上解决这个问题，但是如果强烈的需要第三方的本地的现场支持，那么这个问题还是存在。
公司因素的考虑
Oracle、Sybase 和 Microsoft 都是上市公司。关于 MySQL 公司后台的实力的无论怎么说，事实是这家公司不是上市公司，意味着按照法律财政数据不需要公开。冒着被指控传播 FUD(惧、惑、疑，Fear,UncertaintyandDoubt)的风险，上市公司相对透明 (无论正确与否) 能够为一些 IT 经理和他们报告的上级提供些许的确定性、可靠性和安全。如同一句老话说的，没有人因为购买了 IBM 的产品而被解雇，这句话同样适用于这里 (即使 IBM 日前决定销售 MySQL); 使用著名大公司的产品的确帮助一些人在晚上睡的着，他们是投资者、PHB(Dilbertreference:Pointy-HairedBosses) 和经验丰富的 IT 经理。
可扩展性的领悟
我很小心的命名这最后一个理由。很多业内的专家对于 MySQL 不能很好的扩展都有一致的感知。这个问题被很多人都讨论过，虽然大部分的讨论趋于消除水平扩展和垂直扩展之间区别。MySQL 谈到水平扩展比垂直扩展的次数更多，但是将可扩展性列为使用 MySQL 的主要理由之一。
不使用 MySQL 的理由有哪些
同时、我注意到存在着一个趋势，但是我还没有可靠的数据支持这个趋势，那就是受过正规培训的 DBA 往往会选择私有的 RDBMS，比如 Oracle。我怀疑那些有正规培训和经验的 DBA(而不是软件工程师)往往对私有的系统有一种偏爱。在那些为 DBA 分配了固定角色的大环境中(相对于兼职的咨询师或者兼具程序员身份的人)，MySQL 可能由于这个原因而失宠。在这个层次上，MySQL 的扩展性是否是个真实或者想象出来的批评就变的无关紧要了。如果没有一个充分的理由颠覆这个因素，当你负责安排资源的时候，你想要给他们那些他们最喜欢、带来好处的工具。如果你的那些具有 15 年经验的 DBA 想要 Oracle，并且 Oracle 也在预算之内，那么从长远来看这个方法会有回报的。
进行到了这里，当比较几种稳定的、成熟的、功能丰富的产品的时候，人们就可以不再于哪一个才是绝对意义上“更好的”产品这个问题。取代这个问题的应该是一个需要更多洞察力的问题：哪一个产品才是最适合于给定环境的。我认为主要的 RDBMS 产品都会遇到这个问题，包括 MySQL。这个情况何时发生的问题对一些产品可能是公开的，而这几个产品也欢迎在这个问题上展开讨论。我能够这么说，每个产品都会有不适用的特殊时刻，这就是今天的格局，对任何主要的系统都是一样的。在 MySQL 的例子中，我相信我们已经提到了几个最充分的理由——这些理由不会是一锤子买卖，也不会很快变的过期的。
感谢各位的阅读！关于“不使用 MySQL 的理由有哪些”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
