在《多云数据库经济》一文中，我们探讨了将数据库工作负载分散到 AWS、Azure 和 Google Cloud Platform（GCP）的经济可行性——成本节约从何而来、为何避免供应商锁定具有真实的经济分量，以及如果放任不管，出站流量费用和运维开销会如何悄然吞噬这些节省。那篇文章论证了多云是一种合理的战略选项，而非放之四海皆准的最佳实践；只有当它得到主动管理，而非意外累积时，才能真正产生回报。
本文将承接上一篇文章。如果经济学层面站得住脚，下一个问题就是运维层面：如何在日常运行多云数据库资产时，不让复杂性吞噬掉节省下来的成本？如今，越来越多的组织在多个云服务商上运行数据库——通常同时涉及 AWS、Azure 和 Google Cloud Platform（GCP）。有时这是有意为之，作为一项深思熟虑的弹性策略。但更多情况下，它是日积月累的结果：一个团队在某个项目中以 AWS RDS 为标准，另一个团队为新应用部署了 Azure SQL Database，而数据科学团队则基于 BigQuery 或 Cloud SQL 构建，因为这与他们的工具链集成得更好。无论原因如何，结果都是一样的——数据库资产分散在三个不同的控制台、三种不同的计费模型和三套不同的运维特性之中。
Navicat 17 凭借重新设计的模型工作区、数据分析和数据字典，树立了新的标杆。而计划于八月中旬发布的 Navicat 18，则有望成为一次更大的飞跃。从 AI 辅助数据编辑到完全统一的建模体验，这次更新几乎触及了应用的每一个角落。一篇文章远不足以详尽介绍所有内容，但你可以提前了解即将带来的新功能。
零信任安全基于一个简单的前提：绝不要基于网络位置假设信任，并且将每个请求都当作来自开放网络来验证。几十年来，数据库安全高度依赖于边界防御，即防火墙、VPN，以及企业网络内任何东西都是安全的假设。零信任完全否定了这一假设。每一次连接、每一次查询和每一次用户会话都必须经过认证、授权和加密，无论请求来自办公室的笔记本电脑还是远程承包商。本文解析了 DBA 在实际中这种转变的具体表现，以及日常工具如SSH隧道、SSL/TLS连接和基于角色的访问管理如何融入零信任方法。
每个应用都需要被测试，而每次测试都需要数据。然而，生成高质量的测试数据往往是一项被低估的工作，直到它演变成棘手的问题。团队要么使用生产数据，结果陷入隐私和合规困境；要么手工拼凑少量数据行，这些数据几乎无法触及应用在实际生产环境中真正会遇到的情况。两种方式都无法扩展，而且都会在测试覆盖中留下漏洞，而这些漏洞往往在最不合适的时刻暴露出来。本文将阐述为何应投资于专业的测试数据生成方案，并展示 Navicat 的内置工具如何让这一过程变得更快、更可靠。
数据库团队在管理 MySQL 环境时比以往拥有更多选择，但选择往往归结为一个根本问题：你应该在每台机器上安装桌面客户端，还是让团队通过浏览器访问集中式平台？答案不取决于个人偏好，而更多取决于团队的工作方式、数据的存储位置，以及你对访问权限和安全控制的需求程度。
- 2026 (1)
- 2025 (1)
- 2024 (1)
- 2023 (1)
- 2022 (1)
- 2021 (1)
- 2020 (1)
- 2019 (1)
- 2018 (1)
- 2017 (1)
