【关于TalkX】
TalkX是一款基于GPT实现的IDE智能开发插件，专注于编程领域，是开发者在日常编码中提高编码效率及质量的辅助工具，TalkX常用的功能包括但不限于：解释代码、中英翻译、性能检查、安全检查、样式检查、优化并改进、提高可读性、清理代码、生成测试用例等。
TalkX建立了全球加速网络，不需要考虑网络环境，响应速度快，界面效果和交互体验更流畅。并为用户提供了OpenAI的密钥，不需要ApiKey，不需要自备账号，不需要魔法。
TalkX产品支持：JetBrains (包括 IntelliJ IDEA、PyCharm、WebStorm、Android Studio)、HBuilder、VS Code、Goland.
My relationship with relational databases relates back to the late 90s. It was part of my first steps with computers and programming, became an essential part of my formal education and studies as a software engineer and constantly followed me through my professional career. I almost crawled through the entire RDBMS rabbit hole and still love it.
我与关系数据库的渊源可以追溯到上世纪 90 年代末。它是我接触计算机和编程的第一步，是我作为软件工程师接受正规教育和学习的重要组成部分，并一直伴随着我的职业生涯。我几乎爬过了整个 RDBMS 兔子洞，现在仍然热爱它。
During my career, I touched MySQL, Postgres, Oracle, Microsoft SQL Server, DBase, Access, SQLite, DB2, MariaDB, AWS RDS, Azure SQL, Google Cloud SQL and pretty much any RDBMS I could get my hands on. You can’t love RDBMS without loving SQL which is a rabbit hole of its own. And not all SQLs are the same. You’ve got MySQL with its own jargon, you’ve got Microsoft’s T-SQL and the world famous PL/SQL from Oracle. Probably not necessary to mention that they’re all not compatible with each other.
在我的职业生涯中，我接触过 MySQL、Postgres、Oracle、Microsoft SQL Server、DBase、Access、SQLite、DB2、MariaDB、AWS RDS、Azure SQL、Google Cloud SQL 以及几乎所有我能接触到的 RDBMS。喜欢 RDBMS 就不能不喜欢 SQL，而 SQL 本身就是一个兔子洞。并不是所有的 SQL 都是一样的。MySQL 有自己的行话，微软的 T-SQL 和甲骨文的 PL/SQL 举世闻名。它们之间互不兼容，这一点也许不必多说。
It’s all relational databases? Always has been.
都是关系数据库？一直都是。
Trust me, I’ve seen them all — finance, transportation, hospitality, social media, video streaming services and many others. Regardless of where you go, you’ll probably find a relational database. The world seems to run entirely on relational databases filling the pockets primarily for Oracle, IBM and Microsoft. If you need it big, like really big, you’re calling up Oracle, IBM or Microsoft. Chances are, you’re requirements may also lead you to SAP — especially in the finance sector.
相信我，我见过所有这些领域–金融、交通、酒店、社交媒体、视频流媒体服务和许多其他领域。无论你走到哪里，都可能会发现关系数据库。这个世界似乎完全依靠关系数据库运行，主要是甲骨文、IBM 和微软的腰包鼓起来了。如果你需要的是大型数据库，比如真正的大型数据库，你就会打电话给甲骨文、IBM 或微软。您的需求很可能也会指向 SAP，尤其是在金融领域。
Gartner via Adam Ronthal (@aronthal) on Twitter
The first RDBMS are said to be around since the early 1970s when the Structured English Query Language (SEQUEL, later abbreviated to SQL) was invented. Oracle released its first database in 1979, three years after Honeywell released its Multics Relational Data Store in 1976 — said to be the world’s first relational database. In just a couple of years, we’ll look back at 50 years of relational database management systems (RDBMS). Unsurprisingly, the RDBMS became the backbone of our modern society and economy. Safe to say that everyone has at least one and everyone is in at least one relational database, unless you live in a cave.
据说最早的 RDBMS 早在 20 世纪 70 年代初就出现了，当时发明了结构化英语查询语言（SEQUEL，后缩写为 SQL）。甲骨文公司于 1979 年发布了它的第一个数据库，三年后霍尼韦尔公司于 1976 年发布了它的 Multics Relational Data Store–据说这是世界上第一个关系数据库。再过几年，我们将回顾关系数据库管理系统（RDBMS）50 年的发展历程。不出所料，RDBMS 成为了现代社会和经济的支柱。可以肯定地说，每个人都至少有一个关系数据库，每个人都至少有一个关系数据库，除非你住在山洞里。
Your social security records, your passport, your police records, your birth certificates and all of that happily reside in massive government owned relational database systems — most likely from Microsoft, IBM, SAP or Oracle. Looking for a trip to the beach? Your tickets, reservations and all of that are in relational databases. Whatever data you give to whatever monstrous organization most likely ends up in a relational database.
您的社保记录、护照、警方记录、出生证明以及所有这些信息都被愉快地保存在庞大的政府拥有的关系型数据库系统中–这些系统很可能来自微软、IBM、SAP 或 Oracle。想去海边旅行吗？你的机票、预订单等所有信息都在关系数据库中。无论你向任何畸形组织提供什么数据，最终都很可能会进入关系数据库。
Most database implementations are simple
大多数数据库实现都很简单
The majority of databases however exists, in one way or another, in a form comparable to PHP and MySQL or Microsoft Access and VBA (Visual Basic for Applications). These aren’t complex database management systems, but rather small applications that just use an RDBMS to store data. For many of them, an RDBMS is a massive overkill to begin with. Only the popularity of relational databases has led developers to pick them. Universities, schools, programming courses all teach SQL and relational databases. Most developers probably come with a tendency to use relational databases.
不过，大多数数据库都以这样或那样的形式存在，类似于 PHP 和 MySQL 或 Microsoft Access 和 VBA（Visual Basic for Applications）。这些都不是复杂的数据库管理系统，而是使用 RDBMS 存储数据的小型应用程序。对于其中的许多人来说，RDBMS 一开始就是一个巨大的负担。只是关系数据库的流行导致开发人员选择了关系数据库。大学、学校和编程课程都教授 SQL 和关系数据库。大多数开发人员可能都倾向于使用关系数据库。
You might also agree that most software developers aren’t good database developers. It’s sometimes because they don’t care, but mostly because there are really few learning resources out there that teach you how to build relational databases properly. Most universities, schools, books and courses focus on SQL, normalization and transactions. That’s it and it shows in the relational databases that live out there in the wild.
你可能也同意，大多数软件开发人员都不是优秀的数据库开发人员。这有时是因为他们不关心，但主要还是因为能教你如何正确构建关系数据库的学习资源实在太少了。大多数大学、学校、书籍和课程都侧重于 SQL、规范化和事务。仅此而已，这一点在关系数据库中体现得淋漓尽致。
“An external application shall never even know what tables exist”
“外部应用程序甚至永远不知道存在哪些表”— An experienced DBA that retired in 2012 and wish to stay anonymous
— 一位经验丰富的DBA，于2012年退休，希望保持匿名
The average developer will be shocked at this statement. For experienced database engineers it’s the norm to hide away the entire relational database structure behind views and stored procedures.
普通开发人员听到这句话一定会大吃一惊。对于经验丰富的数据库工程师来说，将整个关系数据库结构隐藏在视图和存储过程之后是一种常态。
Database monsters have become irreplaceable
数据库怪物变得不可替代
In the 1980s all organizations moved into relational databases. By all, I really mean all organizations there are on this planet. Chances are, if you search long enough, you may still find government organizations that haven’t gotten a computer yet. Often, these organizations use custom build databases that reside in mainframe computers for decades, ramping up data and support fees from the manufacturers and vendors.
20 世纪 80 年代，所有组织都开始使用关系数据库。我说的 "所有 "是指地球上的所有组织。如果你搜索的时间足够长，你可能还会发现一些政府组织还没有计算机。这些机构通常使用定制的数据库，这些数据库在大型计算机中驻留了几十年，不断增加数据，并从制造商和供应商那里收取支持费用。
These custom built databases would contain dozens of intertwined tables invisible to the outside world. An endless amount of triggers, functions, procedures and views would not just organize the storage, but run all business processes of that organization. The applications on the application layer provide the interface for the average joe to work with the database. Yet, these applications mostly don’t operate any businesses processes, but merely call stored procedures to execute these.
这些定制的数据库将包含数十个相互交织的表格，外界无法看到。无穷无尽的触发器、函数、过程和视图不仅可以组织存储，还可以运行该组织的所有业务流程。应用层上的应用程序为普通人提供了使用数据库的接口。然而，这些应用程序大多不运行任何业务流程，而只是调用存储过程来执行这些流程。
Since the database consultants from the 80s have retired decades ago, most of these custom built database systems live out there with their SQL application code mostly unmaintained. For many large organizations, these database applications have become blackboxes. They have no clue what they do and how they work in detail, let alone how they should be maintained. Yet, businesses heavily rely on these applications which by now have become irreplaceable. Reverse engineering and rearchitecting these applications has become to only way for an horrendously large amount of organizations. Those “legacy database migration projects” often come at ridiculously high cost in the multiple millions.
由于 80 年代的数据库顾问早在几十年前就退休了，因此这些定制的数据库系统大多还在运行，其 SQL 应用程序代码大多无人维护。对于许多大型企业来说，这些数据库应用程序已成为黑匣子。他们不知道这些系统的具体功能和工作原理，更不用说如何维护这些系统了。然而，企业在很大程度上依赖于这些应用程序，它们现在已经变得不可替代。对这些应用程序进行逆向工程和重新架构已成为大量企业的唯一出路。这些 "遗留数据库迁移项目 "的成本往往高得离谱，高达数百万美元。
Imagine being an insurance company that has absolutely no clue on how the risk for an individual contract is actually calculated on their mainframe. They couldn’t tell their customers what effect a specific claim would have on their premiums. The number of organizations that have no clue how that software runs their business is frightening and hilarious at the same time. Frightening only if you’re a customer and it’s your data in that blackbox.
想象一下，如果一家保险公司完全不知道他们的主机是如何计算单个合同的风险的。他们无法告诉客户具体的索赔会对他们的保费产生什么影响。对软件如何运行业务一无所知的企业数量之多，既令人恐惧，又令人啼笑皆非。只有当你是客户并且你的数据在那个黑匣子里时，你才会感到害怕。
What’s the problem with relational databases?
关系数据库有什么问题？
I personally came across businesses where non-technical employees were referring to the central relational database as “the Oracle” or “the DB2”. Simply because it was such a constraint for the IT department that every change request that affected the RDBMS would become a task for months instead of a few days — with the IT department blaming “the Oracle”. The central database became the central point of failure. Sales promotions would go downhill when the database couldn’t serve them. Adding a column to a table required regular attendance of sunday prayers. Let’s better not start about query performance.
我曾亲身经历过一些企业，非技术人员将中央关系数据库称为 "甲骨文 "或 “DB2”。原因很简单，因为对 IT 部门来说，每一个影响到 RDBMS 的变更请求都是一项长达数月而非数天的任务，而 IT 部门却将责任归咎于 “Oracle”。中央数据库成了中心故障点。当数据库无法为促销活动提供服务时，促销活动就会走下坡路。在表格中添加一列需要定期参加周日祷告。我们最好不要再谈查询性能了。
The problem? A relational database and the principles of designing these push you towards centralization of your data inside that database. Your relational database grows as your business grows with the junk data it produces. You will ultimately arrive at a point where your business becomes economically unable to move off that relational database.
问题出在哪里？关系数据库和设计原则促使你将数据集中到数据库中。您的关系数据库会随着您的业务增长和产生的垃圾数据而增长。最终，您的企业将在经济上无法摆脱关系数据库。
I could quote endless media reports of events when relational databases ruined businesses and our daily lives like examples from aviation with Airline Reservation System Crashes Briefly (2000), Why airlines’ computer systems crash so often (2016), The Shameful Open Secret Behind Southwest’s Failure (2022), examples from finance with TSB Bank fined nearly £50m after botched computer upgrade (2018) or the public sector with Six years, 60 million euros — but no software for the employment agency (2017).
我可以引用无穷无尽的媒体报道来说明关系数据库毁掉企业和我们日常生活的事件，比如航空业的例子有《航空公司订票系统短暂崩溃》（2000年）、《航空公司的计算机系统为何经常崩溃》（2016年）、《西南航空失败背后可耻的公开秘密》（2022年），金融业的例子有《TSB银行因计算机升级失败被罚近5000万英镑》（2018年），公共部门的例子有《6年，6000万欧元–但职业介绍所没有软件》（2017年）。
The relational database is from a different era
关系数据库来自不同的时代
Relational database management systems were invented in an era when the computer looked nothing like what we got today. The use cases were entirely different and the volume these systems had to deal with would fit into anyones pockets today.
关系数据库管理系统发明的时代，计算机与我们今天的计算机完全不同。当时的用例完全不同，而这些系统所要处理的数据量，今天任何人的口袋里都装得下。
I highly recommend Rick Houlihan for his presentations about databases and the thoughts behind the future of database technology. You should definitely check out his various presentation on YouTube: Rick Houlihan on YouTube. The following interview that he gave in the Software Engineering Daily pretty much sums it up.
我强烈推荐 Rick Houlihan 观看他关于数据库和数据库技术未来的演讲。您一定要在 YouTube 上查看他的各种演讲： Rick Houlihan on YouTube。以下是他在《软件工程日报》（Software Engineering Daily）上接受的采访内容。
Interview in Software Engineering Daily Episode 979.
《软件工程日报》第979集专访。Jeff Meyerson (Founder Of Software Engineering Daily):
Jeff Meyerson（《软件工程日报》创始人）：
There are several explanations for why NoSQL rose in popularity after SQL had been the predominant database type. We’ve explored some of those different theories on this show. Give me your historical perspective for why NoSQL became popular.
有几种解释可以解释为什么NoSQL在SQL成为主要数据库类型之后越来越受欢迎。我们在这个节目中探讨了一些不同的理论。请告诉我你为什么NoSQL变得流行的历史观点。
Rick Houlihan (MongoDB, ex-AWS):
Well, sure. I mean, really what it comes down to, again, as people started to process volumes of data, the relational database that we’ve used for so many years turned out to not scale so well. That really points back to the reason why it was invented in the first place, and the relational database came into being because, again, we’re experiencing data pressure,it was the cost of processing data that was preventing us from scaling, and the relational database decreased the pressure on the storage systems, because the normalized data model de-duplicated that data and allowed us to free up storage, so to speak, which was really the most expensive resource in the data center 3 or 4 years ago.
嗯，当然。我的意思是，归根结底，随着人们开始处理大量数据，我们使用了多年的关系数据库的扩展性并不理想。这其实又回到了关系数据库发明的初衷，关系数据库之所以出现，还是因为我们遇到了数据压力，处理数据的成本阻碍了我们的扩展，而关系数据库减轻了存储系统的压力，因为规范化数据模型去除了数据的重复，让我们可以释放存储空间，可以这么说，存储空间在 3、4 年前确实是数据中心最昂贵的资源。
But now, today, fast forward, we pay pennies per gigabyte and we’re paying dollars per our CPU minutes, and really the CPU is no longer just this fixed asset that’s kind of spinning in idle loop when it’s not doing anything else. It’s an asset that we can use to do other things. So joining data and running complex queries is really not something that we’d like to spend our money on, so to speak.
但是现在，快进到今日，我们按每千兆字节支付几分钱，按每分钟 CPU 使用时间支付几美元，实际上 CPU 已不再是闲置循环的固定资产。它是我们可以用来做其他事情的资产。因此，可以说，连接数据和运行复杂查询并不是我们愿意花钱做的事情。
RDBMS are also very strong when you have structured data that requires ACID-compliance. However, a number of use cases do not require ACID compliance at all. These include video streaming, gaming, social media, internet search and many more. All these use cases favour speed and performance over ACID compliance with consistency and atomicity.
当结构化数据需要符合 ACID 标准时，RDBMS 也非常强大。然而，许多使用案例根本不需要 ACID 合规性。这些用例包括视频流、游戏、社交媒体、互联网搜索等。所有这些用例都更倾向于速度和性能，而不是一致性和原子性的 ACID 合规性。
An internet search engine does not need to show every user the latest results and not every user requires the same result. Hence, ACID compliance is totally irrelevant for the use case of an Internet search engine. No one in his right mind would use an RDBMS for a large scale Internet search engine or a social media site.
互联网搜索引擎不需要向每个用户显示最新的结果，也不是每个用户都需要相同的结果。因此，ACID 合规性与互联网搜索引擎的用例完全无关。没有哪个正常人会将 RDBMS 用于大型互联网搜索引擎或社交媒体网站。
The solution? Purpose built systems.
解决方案是什么？专用系统。
It’s obvious that a general purpose database with a “one fits all” attitude hardly achieves superiority in any use case. Trying to use RDBMS for transactions, search, analytics and any other use case will most likely never have the optimal result for any of these. Hence, the obvious elephant in the room are purpose built solutions. These can be databases, even relational ones, but may also be other systems such as dedicated search engines or even custom software.
很明显，具有“一刀切”态度的通用数据库在任何用例中都很难实现优势。尝试将RDBMS用于交易，搜索，分析和任何其他用例很可能永远不会为其中任何一个提供最佳结果。因此，房间里明显的大象是专门构建的解决方案。这些可以是数据库，甚至是关系数据库，但也可能是其他系统，例如专用搜索引擎甚至自定义软件。
The approach of using purpose built data management only works if you strictly adhere to microservice architectures and don’t build “micro serviced monoliths” in which you have micro services all working on a single centralized data management system like a relational database. It’s a common occurence to find micro service architectures paired with monolithic databases which completely render the micro service approach useless.
只有严格遵守微服务架构，不构建 “微服务单体”，即所有微服务都在关系数据库等单一集中式数据管理系统上运行，使用专门构建的数据管理方法才会奏效。微服务架构与单体数据库配对的情况很常见，这使得微服务方法完全失去了作用。
Object-, key-value- and document stores
对象、键值和文档存储
The first choice for data storage of applications should be basic key value stores like Apache Cassandra, AWS DynamoDB, Google Cloud Spanner or Azure Cosmos DB. The key value stores provide high scalibility, durability and simplicity. They work for all basic application use cases where you just need to insert data and access it with at most 3–4 keys.
应用程序数据存储的首选应该是基本键值存储，如Apache Cassandra，AWS DynamoDB，Google Cloud Spanner或Azure Cosmos DB。键值存储提供高可扩展性、持久性和简单性。它们适用于所有基本应用程序用例，在这些用例中，您只需要插入数据并使用最多 3-4 个键访问它。
Should your data require more complex querying, e.g. search or analytics, you can always switch to a dedicated search engine or analytical system by streaming the data from your key-value-store to the other system. If you don’t need querying at all and just require simple data storage, going with an object store such as AWS S3, Azure Blob Storage or Google Cloud Storage is a best practice approach.
如果您的数据需要更复杂的查询，如搜索或分析，您可以随时切换到专用搜索引擎或分析系统，将数据从键值存储流式传输到其他系统。如果您根本不需要查询，只需要简单的数据存储，那么使用 AWS S3、Azure Blob Storage 或 Google Cloud Storage 等对象存储是最佳做法。
Document stores such as MongoDB or AWS DocumentDB try to provide an alternative to relational databases although they often come with the same principles, just not relational. Just moving from tables to documents may still present you with the same issues you had before.
MongoDB 或 AWS DocumentDB 等文档存储试图提供关系数据库的替代方案，尽管它们通常具有相同的原理，只是不具有关系性。从表格到文档的转变可能仍然会带来与以前相同的问题。
Dedicated or custom built search engines
专用或定制的搜索引擎
A common use case for relational databases is search. That’s a use case that relational databases are rarely ideal for. Search functionality, in most cases, does not require ACID compliance at all. Purpose built search engine like Lucene, Solr, OpenSearch or ElasticSearch provide significant better performance and have a lower operating cost.
关系数据库的一个常见用例是搜索。这是关系数据库很少理想的用例。在大多数情况下，搜索功能根本不需要 ACID 合规性。专门构建的搜索引擎，如Lucene，Solr，OpenSearch或ElasticSearch，提供了显着更好的性能，并具有更低的运营成本。
Depending on the use case, the existing offerings from cloud providers such as Google’s Cloud Search may already be more suitable for your requirements. If none of that fits your requirements, building dedicated search software tailored to your needs is not too far fetched considering the speed of development that you have with languages like Go (see Writing Server Software With Go). It is absolutely worth calculating the impact of your choice before jumping head first into your beloved relational database.
根据用例，云提供商（例如Google的Cloud Search）的现有产品可能已经更适合您的要求。如果这些都不符合您的要求，那么考虑到您使用 Go 等语言的开发速度，构建适合您需求的专用搜索软件并不太牵强（请参阅使用 Go 编写服务器软件）。在首先跳入您心爱的关系数据库之前，绝对值得计算您的选择的影响。
Transaction databases or blockchain
交易数据库或区块链
The home turf of relational databases is transaction processing. This area however is currently challenged by blockchain-based database systems like Amazon QLDB. Most key-value-stores also provide ACID compliance options allowing you to store transactions safely in these. It was always recommended to have different database environments for OLTP (on-line transaction processing) and OLAP (on-line analytical processing) anyway. Accessing transactions often is done by no more than 3–4 keys, hence key-value-stores may be ideal for transactions as well.
关系数据库的主场是事务处理。然而，这一领域目前受到亚马逊QLDB等基于区块链的数据库系统的挑战。大多数键值存储还提供 ACID 合规性选项，允许您将事务安全地存储在这些选项中。无论如何，始终建议为OLTP（在线事务处理）和OLAP（在线分析处理）使用不同的数据库环境。访问事务通常由不超过 3-4 个键完成，因此键值存储也可能是交易的理想选择。
I have personally deployed Amazon QLDB in production and would not go back to relational databases. The advantages of a cryptographically verifyable storage for transactions allows for much greater auditability. While anyone can manipulate a transaction in a relational database, QLDB tracks any change to the records using the strain of the transaction. For financial transaction processing, QLDB is my preferred system. However, it depends on the use case and whether you even need the cryptographic verification for your use case.
我个人已经在生产中部署了 Amazon QLDB，再也不会回到关系数据库中去了。可加密验证的事务存储的优势使可审计性大大提高。任何人都可以操作关系数据库中的事务，而 QLDB 则使用事务的应变来跟踪记录的任何更改。对于财务交易处理，QLDB 是我的首选系统。不过，这取决于使用情况，以及您是否需要对使用情况进行加密验证。
I love writing SQL 🐿️ with stored procedures, functions, triggers and views. Designing relational databases with MySQL Workbench is fun for me. The newest features in MySQL 8 with geospatial data is amazing. There’s so much you can do in relational databases — all in one place. To be honest, I sometimes miss the days when you would just write your entire business application inside MySQL, Oracle or SQL Server. But I need to be honest to myself: It was acceptable in the 80s. We are in 2023, compute and storage have changed and so have our data centers and our applications.
我喜欢编写 SQL️，包括存储过程、函数、触发器和视图。用MySQL Workbench设计关系数据库对我来说很有趣。MySQL 8在地理空间数据方面的最新功能令人惊叹。在关系数据库中可以做的事情太多了，而且都在一个地方。老实说，我有时会怀念在 MySQL、Oracle 或 SQL Server 中编写整个业务应用程序的日子。但我必须对自己诚实： 这在 80 年代是可以接受的。现在是 2023 年，计算和存储发生了变化，我们的数据中心和应用程序也发生了变化。
With the vast offering in database systems, key-value and object stores, search engine technology and programming languages, the days of going with a database for decades are over. No more projects with endless debates on whether MySQL, MSSQL, Oracle or Postgres is the right choice. Today’s databases and storage are decided upon on a case by case basis. And quite often, I find myself writing a small custom storage strategy that is based on object or key-value stores.
随着数据库系统、键值和对象存储、搜索引擎技术和编程语言的广泛应用，几十年来一直使用一种数据库的时代已经一去不复返了。再也不会有项目无休止地争论 MySQL、MSSQL、Oracle 或 Postgres 是否是正确的选择。如今，数据库和存储是根据具体情况决定的。很多时候，我发现自己正在编写一种基于对象或键值存储的小型自定义存储策略。
Today, before I implement a software or system, I think about what data is stored and how it is accessed. I then often spent hours and days to find the right approach to data stores. Relational databases are very rarely a part of the solution when I am honest with myself. I’ve just seen the long-term effects of centralized relational databases too often.
如今，在实施软件或系统之前，我会先考虑存储哪些数据以及如何访问这些数据。然后，我往往要花费数小时甚至数天的时间来寻找正确的数据存储方法。说实话，关系数据库很少成为解决方案的一部分。我经常看到集中式关系数据库的长期影响。
【参考文献】
上述译文仅供参考，具体内容请查看⬇️链接，解释权归原作者所有
文章：[Relational Database Systems Are Becoming A Problem — But What To Do About It?]
作者：Jan Kammerath
发布日期：2023.08.15
⚠️：文章翻译上如有语法不准确或者内容纰漏，欢迎各位评论区指正。
【关于TalkX】
TalkX是一款基于GPT实现的IDE智能开发插件，专注于编程领域，是开发者在日常编码中提高编码效率及质量的辅助工具，TalkX常用的功能包括但不限于：解释代码、中英翻译、性能检查、安全检查、样式检查、优化并改进、提高可读性、清理代码、生成测试用例等。
TalkX建立了全球加速网络，不需要考虑网络环境，响应速度快，界面效果和交互体验更流畅。并为用户提供了OpenAI的密钥，不需要ApiKey，不需要自备账号，不需要魔法。
TalkX产品支持：JetBrains (包括 IntelliJ IDEA、PyCharm、WebStorm、Android Studio)、HBuilder、VS Code、Goland.
6694
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
