企业官网建设流程全解析

建筑公司网站董事长致辞,头像设计制作网站,湖南建设教育网站,软文推广发稿平台国产化替代浪潮之下#xff0c;金仓数据库#xff08;即 KingbaseES#xff0c;业内又常称之为 KES#xff09;有着一项独门绝技#xff0c;那就是出色的 Oracle 兼容能力和强大的内核实力#xff0c;于是它渐渐成为诸多企业执行核心系统迁移时的优先选择。 KES 的设计思…国产化替代浪潮之下金仓数据库即 KingbaseES业内又常称之为 KES有着一项独门绝技那就是出色的 Oracle 兼容能力和强大的内核实力于是它渐渐成为诸多企业执行核心系统迁移时的优先选择。KES 的设计思路很有趣其底层依靠先进的开源内核上方则紧密契合 Oracle 的语法及行为这对于开发者而言颇为周到如此一来开发者便能够收获云原生时期新技术带来的好处而且可以把老旧系统迁移所耗费的成本减小到最低限度。不过要说回来把 Oracle 或 MySQL 移植到 KES 的时候各个数据库对标准 SQL 的执行细节存在一些差别所以难免会遭遇“水土不服”的技术难点。遇到这种情况不要慌这并非产品有 Bug更多的是由于不同数据库的设计理念产生冲突只要深入了解这些机制不但眼前的难题能够得到解决而且对于数据库原理的认识也会提升。本文整理了4个技术场景分别是对象命名空值处理JSON数据处理以及序列管理经由原理分析并重现代码带领大家一起避开这些陷阱从而更好地掌握KingbaseES。文章目录案例一明明表存在为什么报 relation does not exist案例二写入的空字符串凭空消失了空串与 NULL案例三JSON 函数返回 NULLJSON 路径匹配规则案例四迁移后插入数据报错 Duplicate key序列同步机制总结与更多资源案例一明明表存在为什么报 “relation does not exist”现象描述大家可能遇到过这种情况明明刚建了个表叫UserInfo结果用SELECT * FROM UserInfo一查直接报错ERROR: relation userinfo does not exist。这时候你可能会怀疑人生表呢我刚建的表呢复现代码-- 1. 创建一个包含大写字母的表未加双引号KES默认会转为小写CREATETABLEUserInfo(idINT,nameVARCHAR(20));-- 2. 尝试查询此时表名在内部存储为 userinfoSELECT*FROMUserInfo;-- 成功因为 UserInfo 也会被自动转为 userinfo-- 3. 如果我们在特定的 Schema 下创建表且使用了双引号保持大小写CREATESCHEMAapp_v1;CREATETABLEapp_v1.UserInfo(idINT,nameVARCHAR(20));-- 4. 此时直接查询或者不加双引号查询SELECT*FROMapp_v1.UserInfo;-- 报错relation app_v1.userinfo does not exist原因分析这是由于KES处于PG模式或者默认设置时要遵循SQL标准所致标准表明如果未给标识符加上双引号系统就会自动将其转换为小写。在创建表时如果你用上了双引号譬如说 “UserInfo”那么系统就会严格按照你所写的大小写来进行存储等到执行查询的时候假使你嫌麻烦没有加上双引号而系统又把表名转换成小写来实施比对这样必然就查不到相关内容。search_path搜索路径常会陷入一些问题你的表若既未处于public也未在当前用户的 Schema 下就务必明确指定 Schema。解决方法统一规范最省心的办法就是表名、字段名全用小写别用双引号大家都轻松。检查search_pathSHOWsearch_path;-- 如果你的表在 app_v1 模式下需要设置SETsearch_pathTOapp_v1,public,sys;精准查询实在搞不清表名到底存成啥样了直接查系统表一看便知SELECTschemaname,tablenameFROMsys_tablesWHEREschemanameapp_v1;案例二写入的空字符串凭空消失了空串与 NULL现象描述很多从 MySQL 转过来的兄弟习惯用空字符串代表“没东西”。结果写入数据后用WHERE content 死活查不到数据换成IS NULL反倒查出来了。这就很迷我的空字符串去哪了复现代码CREATETABLEt_str_test(idINT,contentVARCHAR(50));-- 插入一条空字符串INSERTINTOt_str_testVALUES(1,);-- 尝试查询空字符串SELECT*FROMt_str_testWHEREcontent;-- 结果0 条数据在 Oracle 模式下-- 尝试查询 NULLSELECT*FROMt_str_testWHEREcontentISNULL;-- 结果1 条数据原因分析这是 KES 为适配Oracle 模式所专门设计的在 Oracle 系统当中空字符串和NULL实际上是相同概念二者可以相互替代。KES 有一个名为ora_input_emptystr_isnull的参数用于控制相关行为该参数处于开启状态默认值为on时向其中插入空字符串时系统会自动将其在底层转换为NULL这样做主要是方便那些习惯使用 Oracle 的用户在迁移过程中更为顺畅。解决方法入乡随俗既然用了 KES 的 Oracle 模式咱们最好就按 Oracle 的规矩来用IS NULL判断空内容习惯了也挺好。改参数特殊情况如果你非得保留空字符串的语义比如为了兼容 MySQL 的老业务那也可以在会话级或者系统级把这个参数关掉-- 查看当前参数SHOWora_input_emptystr_isnull;-- 关闭自动转换仅当前会话生效SETora_input_emptystr_isnulloff;-- 再次测试INSERTINTOt_str_testVALUES(2,);SELECT*FROMt_str_testWHEREcontent;-- 此时能查到 id2 的记录案例三JSON 函数返回 NULLJSON 路径匹配规则现象描述现在业务里用 JSON 的情况越来越多了KES 对这块支持也不错。但经常有兄弟抱怨用JSON_VALUE或JSON_QUERY取数据时明明看着数据就在那儿怎么取出来全是 NULL复现代码-- 假设表中有一条 JSON 数据{Name: Kingbase, Version: V8R6}CREATETABLEt_json(info jsonb);INSERTINTOt_jsonVALUES({Name: Kingbase, Version: V8R6});-- 尝试提取 Name 字段SELECTJSON_VALUE(info,$.name)FROMt_json;-- 结果NULL原因分析这也真不是系统出 Bug 了通常是因为咱们写的路径匹配规则太严格。大小写敏感JSON 标准表明Key键名属于大小写敏感范畴前面例子中的数据含有 “Name”大写N而查询路径却是$.name小写n二者显然无法对应所以默认情形下相关函数会默默给出 NULL。路径层级要是路径层级搞错了比如少写了一层对象嵌套那肯定也摸不到值。解决方法对齐大小写写 SQL 的时候细心点JSON 路径必须跟数据里的 Key 一模一样。-- 正确写法使用 NameSELECTJSON_VALUE(info,$.Name)FROMt_json;-- 结果Kingbase用ON EMPTY查因为了搞清楚到底是“没找到”还是“值本身就是 NULL”可以用DEFAULT ... ON EMPTY这个语法来探探底。SELECTJSON_VALUE(info,$.nameDEFAULTPath Not FoundONEMPTY)FROMt_json;-- 结果Path Not Found案例四迁移后插入数据报错 “Duplicate key”序列同步机制现象描述数据刚从别的库导进 KES表里明明已经有 100 条数据了ID 从 1 到 100。这时候应用发起一条INSERT不指定 ID想用自增结果崩了直接报主键冲突duplicate key value violates unique constraint。这啥情况新来的数据还能跟旧数据打架复现代码-- 1. 创建序列和表CREATESEQUENCE seq_user_idSTART1;CREATETABLEt_user(idINTDEFAULTnextval(seq_user_id)PRIMARYKEY,nameVARCHAR(20));-- 2. 模拟数据迁移显式插入 IDINSERTINTOt_user(id,name)VALUES(1,Alice);INSERTINTOt_user(id,name)VALUES(2,Bob);-- 3. 此时序列 seq_user_id 的当前值last_value依然是 1或者未定义-- 4. 应用尝试隐式插入依赖默认值INSERTINTOt_user(name)VALUES(Charlie);-- 错误键值 (id)(1) 已经存在原因分析这其实是数据库序列Sequence的标准行为没啥好奇怪的。导数据时以迁移工具为例一般会显式指定ID执行插入操作此情形下并不会自动推动相关联的序列。等到后面自己跑起来开始依赖default nextval(...)的时候序列还是会从初始值譬如说 1开始发放这必然会造成与表里已有的 ID 冲突。解决方法迁移搞定后千万别忘了重置序列把它拨到当前表里最大 ID 的位置。-- 修正序列值SELECTsetval(seq_user_id,(SELECTMAX(id)FROMt_user));-- 再次插入成功INSERTINTOt_user(name)VALUES(Charlie);-- ID 将变为 3总结与更多资源看了上面这几个例子大家应该也发现了很多看似“奇葩”的现象其实是 KingbaseES 为了在标准化和兼容性之间找平衡而做的精心设计。只要把这些技术细节摸透你在数据库开发和迁移的时候就能游刃有余少踩很多坑。KingbaseES 毕竟是成熟的企业级数据库诊断工具和文档支持都挺全的。如果你对它的底层原理、更多高级玩法像读写分离、集群高可用这些感兴趣或者真在项目里碰到了硬骨头欢迎来咱们的官方技术社区逛逛金仓数据库官方博客站https://kingbase.com.cn/explore在这里你可以找到更多资深专家的技术干货、原理解析和最佳实践文档。