参数、页面导航与自动刷新
上周我们使用图层布置了 Classic Models 销售仪表板,将三个图表——按产品线的收入、月度销售趋势,以及按订单金额排序的顶级客户——排列成整洁、均匀分布的一排。本周我们将通过该三个商业智能功能让这个仪表板具备交互性并自维护:参数、页面导航与自动刷新。
平铺图层简介
一个优秀的管理层仪表板能让人一眼读懂全局:业务表现如何、该深入查看哪里、数据有多新。Navicat 18 的商业智能(BI)工具新增了若干功能,让这个“故事”更易构建,也更易保持最新。今天我们将搭建一个简单的销售概览仪表板,并使用平铺图层。接下来的几篇文章将介绍全新的参数、页面导航与自动刷新功能。
本教程假定你已经创建了一个连接到 MySQL 示例数据库 classicmodels 的数据源,构建了类似于下文所列的三个图表,并且已经创建了仪表板本身。以下步骤从该状态开始。
写一条简单的查询很容易。但当它膨胀到十五个 join 和好几个别名之后,维护起来就变得枯燥乏味了。一旦重命名某个表别名,你就得手动找出每一个引用。Navicat 18 的 SQL 编辑器正是针对这类摩擦,带来了三项新增功能:重构、实时错误检测和代码洞察。
每个数据库团队最终都会遇到同一个问题:最理想的测试数据就是真实数据,但把真实数据用在生产环境之外,随时可能演变成一场合规噩梦。GDPR、HIPAA 和 PCI-DSS 等法规不会因为你“只是在测试”就网开一面;一旦开发人员的笔记本电脑或预发布服务器泄露了真实的客户姓名、电子邮件或支付信息,就构成了数据泄露事件。Navicat 18 正面解决了这一难题,推出了全新功能“数据脱敏”,可将敏感的生产记录转换为安全且贴近真实的模拟数据,从而让开发、测试与 QA 团队在规避风险的同时持续开展工作。
在《多云数据库经济》一文中,我们探讨了将数据库工作负载分散到 AWS、Azure 和 Google Cloud Platform(GCP)的经济可行性——成本节约从何而来、为何避免供应商锁定具有真实的经济分量,以及如果放任不管,出站流量费用和运维开销会如何悄然吞噬这些节省。那篇文章论证了多云是一种合理的战略选项,而非放之四海皆准的最佳实践;只有当它得到主动管理,而非意外累积时,才能真正产生回报。
本文将承接上一篇文章。如果经济学层面站得住脚,下一个问题就是运维层面:如何在日常运行多云数据库资产时,不让复杂性吞噬掉节省下来的成本?如今,越来越多的组织在多个云服务商上运行数据库——通常同时涉及 AWS、Azure 和 Google Cloud Platform(GCP)。有时这是有意为之,作为一项深思熟虑的弹性策略。但更多情况下,它是日积月累的结果:一个团队在某个项目中以 AWS RDS 为标准,另一个团队为新应用部署了 Azure SQL Database,而数据科学团队则基于 BigQuery 或 Cloud SQL 构建,因为这与他们的工具链集成得更好。无论原因如何,结果都是一样的——数据库资产分散在三个不同的控制台、三种不同的计费模型和三套不同的运维特性之中。
- 2026 (1)
- 2025 (1)
- 2024 (1)
- 2023 (1)
- 2022 (1)
- 2021 (1)
- 2020 (1)
- 2019 (1)
- 2018 (1)
- 2017 (1)

