IvorySQL 4.0 之 Invisible Column 功能解析
前言
随着数据库应用场景的多样化,用户对数据管理的灵活性和隐私性提出了更高要求。IvorySQL 作为一款基于 PostgreSQL 并兼容 Oracle 的开源数据库,始终致力于在功能上保持领先和创新。在最新发布的 4.0 版本中,IvorySQL 新增了 Oracle 兼容特性 Invisible Column(不可见列),这一功能由社区贡献者 Imran Zaheer 提供,体现了开源社区协作的力量。
Invisible Column 的引入,为开发者提供了在不影响现有应用的情况下动态调整数据库结构的新选择,进一步提升了 IvorySQL 在数据灵活性管理上的能力,为用户在数据库升级、兼容性优化等方面提供了更大的便利性。
本文将详细介绍这一特性的功能、使用场景以及使用方式。
什么是 Invisible Column?
在现代数据库开发中,列的可见性管理在一定程度上影响了应用程序的灵活性与迁移效率。Oracle 12c 提供了一项强大的功能:Invisible Column(不可见列)。这是一种隐藏数据列的特性,用于增强数据安全性和实现业务逻辑。这一功能为开发者提供了灵活性和控制能力,特别是在应用程序迁移或版本升级的场景中。
在 Oracle 中,Invisible Column 是指那些对大多数 SQL 查询和工具不可见的列。通过将列设置为不可见列:
- 它不会出现在常规的
SELECT * FROM
查询结果中。 - 它不会在
SQL*Plus
或OCI
的描述操作中显示。 - 它不会包含在基于
%ROWTYPE
属性的记录定义中。
然而,不可见列仍然存在于表中,可以通过显式指定列名来访问或引用。另外,不可见列在使用时也有限制,要注意在外部表(External Tables)、聚簇表(Cluster Tables)、临时表(Temporary Tables)中无法使用不可见列。
Invisible Column 的应用场景
1. 应用程序迁移
不可见列在应用程序迁移过程中非常有用。当我们向现有表中添加新列时,不可见列可以避免影响旧应用程序的功能。旧的应用程序不会察觉新列的存在,而新的应用程序可以显式引用这些列。从而使应用程序的在线迁移变得更加简单顺畅。
2. 敏感数据保护
某些敏感数据可以通过不可见列存储,避免被大多数默认查询工具访问,从而降低意外暴露的风险。
3. 数据模型优化
在数据模型调整或调试过程中,可以临时将一些列设置为不可见列,确保它们不会影响常规查询,避免查询结果混淆。
在 IvorySQL 中使用 Invisible Column
Invisible Column 为 IvorySQL 4.0 版本中新增加的兼容特性,使用前请先确保您的版本为 4.0。
1. 创建不可见列
可以在创建表时直接将列定义为不可见列:
CREATE TABLE employees ( emp_id NUMBER, emp_name VARCHAR2(50), emp_salary NUMBER INVISIBLE );
在此示例中,emp_salary
是不可见列,对默认查询不可见:
select*from employees ; emp_id | emp_name --------+---------- (0 rows)
2. 向不可见列插入数据
在向表中插入数据时,可以通过显式指定列名的方式向不可见列插入数据:
INSERT INTO employees(emp_id,emp_name,emp_salary) VALUES(1,'Jack',20000); INSERT 0 1 INSERT INTO employees(emp_id,emp_name,emp_salary) VALUES(2,'Lucy',30000); INSERT 0 1;
不带命名列的插入不能包含不可见列:
INSERT INTO employees VALUES(3,'Peter'); INSERT 0 1
3. 显示/修改现有列为不可见列
通过 VISIBLE
关键字,可以将不可见列改回普通列:
ALTER TABLE employees MODIFY emp_salary VISIBLE; ALTER TABLE
如果需要将现有列设置为不可见列,可以使用 INVISIBLE
:
ALTER TABLE employees MODIFY emp_salary INVISIBLE; ALTER TABLE
注意,不能将所有的列设置为不可见列。
4. psql \d 元命令
在 psql 中使用 \d
元命令时不会显示该表的不可见列信息:
\d employees Table "public.employees" Column | Type | Collation | Nullable | Default ------------+--------------+-----------+----------+--------- emp_id | number | | | emp_name | varchar2(50) | | | emp_salary | number | | |
可以使用含有更多表信息的 \d+
元命令查看该表的不可见列信息:
\d+ employees Table "public.employees" Column | Type | Collation | Nullable | Default | Invisible | Storage | Compression | Stats target | Description ------------+--------------+-----------+----------+---------+-----------+----------+-------------+--------------+------------- emp_id | number | | | | | main | | | emp_name | varchar2(50) | | | | | extended | | | emp_salary | number | | | | invisible | main | | | Access method: heap
5. 访问 Invisible Column
在使用 SELECT*
查询表数据时,不会显示不可见列的数据:
SELECT * FROM employees ; emp_id | emp_name --------+---------- 1 | Jack 2 | Lucy 3 | Peter (3 rows)
虽然不可见列对默认查询不可见,但开发者仍然可以通过显式指定列名来访问它:
SELECT emp_name,emp_salary FROM employees ; emp_name | emp_salary ----------+------------ Jack | 20000 Lucy | 30000 Peter | (3 rows)
结语
不可见列功能是一项设计精妙的特性,为数据库开发和管理提供了更高的灵活性和安全性。通过合理利用不可见列,开发者可以轻松应对复杂的应用迁移场景,同时保持系统的稳定性和可扩展性。
如果您有正在使用 IvorySQL 数据库的项目,不妨尝试将此功能集成到您的解决方案中,提升整体效率和可靠性。 > 本文由博客一文多发平台 OpenWrite 发布!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
七步定位 OceanBase 登录报错
本文将为大家总结 OceanBase 集群登录时常见报错“Access denied”的排查步骤。 > 作者:何文超,爱可生南区交付服务部 DBA 团队成员。主要负责 MySQL 故障处理,MySQL 高可用架构改造,OceanBase 相关技术支持。爱好足球,羽毛球。 > > 爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 > > 本文约 600 字,预计阅读需要 3 分钟。 问题背景 近期,生产环境通过客户端工具可正常连接 OceanBase 集群,但通过黑屏连接登录报错。 报错信息如下: ERROR 1045 (42000): Access denied for user 'root'@'xxx.xxx.xxx.xxx' (using password: NO) 本文以上述案例为例,为大家总结 OceanBase 集群登录时常见报错“Access denied”的排查步骤。 排查步骤 以下将按照常见原因的发生概率,排序逐一列举。 一、确认用户的密码正确性 请再次确认您使用的用户密码是否正确。 二、检查网络连通性 确保不同...
- 下一篇
果断抛弃try catch!业界大佬力荐的异常优雅处理方案
背景 在软件开发的日常工作里,大家都知道,处理各种各样的异常情况是躲不开的必修课。就我个人的切身体会而言,我仔细回想了一下,好家伙,我投入到处理异常当中的精力,保守估计得占了开发总时长的一半还多。 这直接后果就是,我手头代码里频繁冒出大量的 try {...} catch {...} finally {...} 代码块,一眼望去,它们就跟杂乱无章的补丁似的。 一方面,这里面存在着大量重复、冗余的代码,仿佛在无声地消耗着代码库的 “整洁度”,另一方面,这些代码块还严重影响了代码整体的可读性,每次我想要深入理解或者修改某段代码逻辑时,都得在这堆乱糟糟的异常处理代码里 “跋涉” 半天,别提多费劲了。 现在呢,咱们来看看下面两个代码模块,对照一下,瞧瞧我目前编写的代码更贴近哪种风格。说实在的,我心里也犯嘀咕呢,到底哪种编码风格才是更优解?要是大家有什么高见,欢迎畅所欲言,帮我指点一二。 丑陋的代码模块 declare(strict_types=1);namespaceapp\controller;useapp\common\service\ArticleService;usesupport\R...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Linux系统CentOS6、CentOS7手动修改IP地址
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS关闭SELinux安全模块
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Hadoop3单机部署,实现最简伪集群
- CentOS6,7,8上安装Nginx,支持https2.0的开启