企业官网建设流程全解析

江阴市建设局网站,wordpress 禁止评论,润和软件是外包公司吗,宁德市人社局文章目录引言#xff1a;Oracle到金仓迁移的痛点及破局KES支持Oracle风格的PL/SQL兼容性痛点#xff1a; 三大高危迁移场景核心语法兼容性验证1\. 集合类型支持2. 控制结构与参数模式系统包兼容性分析迁移实践建议KingbaseES的JSON函数生态与实战KingbaseES的函数生态优化1. …文章目录引言Oracle到金仓迁移的痛点及破局KES支持Oracle风格的PL/SQL兼容性痛点 三大高危迁移场景核心语法兼容性验证1\. 集合类型支持2. 控制结构与参数模式系统包兼容性分析迁移实践建议KingbaseES的JSON函数生态与实战KingbaseES的函数生态优化1. 简洁的函数设计2.实用函数示例3. JSON与JSONB的选型建议功能演进与高级特性总结KES的PL/SQL能力深度解读从语法到性能内置函数、聚集函数、分析函数的对比与迁移实践内置函数对比与迁移要点结论国产数据库迁移的现状与未来引言Oracle到金仓迁移的痛点及破局我发现企业在Oracle迁移过程中应用层简直就是“拦路虎”就像我参加的那个银行项目一样一个存储过程改了三天当时真是让人心疼早年间迁移时最头疼的就是PL/SQL语法不兼容、JSON处理能力弱得可怜等历史遗留问题。回忆国产数据库的以前版本比如V8只能支持点基础语法复杂的业务场景完全扛不住但是现在不一样了我实测KESV9R1C10这个版本对于PL/SQL包和复杂函数的支持非常到位这才真正给迁移问题松了绑。真得吐槽某些迁移工具只顾着把语法转换了事根本不管运行时会出错我就栽在这个坑里上线之后才发现问题一堆好在金仓数据库针对这些痛点给出了实际的解决办法后面我会说。迁移核心痛点 企业在迁移Oracle的过程中应用层的PL/SQL语法不兼容、JSON处理能力差等以及一些迁移工具只做语法转换忽视了运行时错误等问题这些都是导致迁移困难的原因。KES支持Oracle风格的PL/SQL我拿着100多个真实项目存储过程去测发现金仓数据库KES对Oracle风格PL/SQL兼容性真的不错不过复杂场景里还是有一些“坑”我是过来人结合自己代码案例从兼容性痛点、核心语法支持、系统包兼容这三个维度给大家好好唠一唠。兼容性痛点 三大高危迁移场景TYPE … IS TABLE OF迁移风险提示 涉及包含EXECUTEIMMEDIATE的动态SQL需注意KES对绑定变量处理规则与Oracle完全一致但DBMS_SQL包低版本兼容性更佳建议优先使用原生动态SQL语法核心语法兼容性验证1. 集合类型支持Oracle的ASSOCIATIVEARRAY(关联数组)在KES中是完全兼容的下面的代码可以直接跨平台运行:DECLARETYPEemp_salary_typeISTABLEOFNUMBER(10,2)INDEXBYPLS_INTEGER;emp_salaries emp_salary_type;BEGINemp_salaries(100):5000;emp_salaries(200):6000;DBMS_OUTPUT.PUT_LINE(Employee 100 Salary: ||emp_salaries(100));END;/这段代码我Oracle和KES上都运行了结果完全一样连一行都不用改不得不佩服KES在集合类型底层实现上真的用心兼容性做得好。2. 控制结构与参数模式KES对PL/SQL控制语句FORLOOP、CASE以及子程序参数模式IN/OUT/INOUT无差别支持下面存储过程示例展示了完整的参数模式兼容CREATEORREPLACEPROCEDUREupdate_employee_salary(p_emp_idINNUMBER,p_percentINNUMBER,p_new_salaryOUTNUMBER,p_updated_rowsINOUTNUMBER)ASBEGINUPDATEemployeesSETsalarysalary*(1p_percent/100)WHEREemployee_idp_emp_idRETURNINGsalaryINTOp_new_salary;p_updated_rows :SQL%ROWCOUNT;EXCEPTIONWHENOTHERSTHENp_updated_rows :-1;RAISE;END;/IN系统包兼容性分析DBMS_OUTPUTDBMS_SCHEDULER兼容性矩阵✅ 完全兼容DBMS_OUTPUT、DBMS_LOB、UTL_FILE⚠️ 部分兼容DBMS_SCHEDULER基础功能、DBMS_CRYPTO部分算法❌ 暂不支持DBMS_AQ、DBMS_STREAMS迁移实践建议DBMS_SCHEDULERKingbaseES的JSON函数生态与实战搞数据库开发的人都知道JSON处理顺不顺手直接影响干活效率Oracle的JSON函数设计简直反人类路径表达式复杂得要命我早就想吐槽了但是KES在这一点上做的真的很好优化很明显接下来我就以自己“踩坑-解决-总结”的真实经历给大家讲讲KES的JSON函数生态是如何一步步进化的。$.store.book[0].titleOracle对JSON数据的支持路径表达式要加特殊符号前缀比如. s t o r e . b o o k [ 0 ] . t i t l e 得变 成 ′ .store.book[0].title得变成.store.book[0].title得变成′.store.book[0].title’某些函数名称和参数顺序不够直观把JSON数组转换成关系表的时候得一层层套用JSON_TABLE和PATH子句语法结构比较繁杂这种设计加重了学习负担也拖慢了开发速度。KingbaseES的函数生态优化KES这点就很聪明直接兼容PostgreSQL和MySQL的JSON函数体系用起来顺手多了我总结了几个核心优势1. 简洁的函数设计KES的JSON_TABLE函数可以直接把JSON数据转成关系表结构路径表达式不用特别转义解析嵌套的JSON数组可以这样简单地写SELECT*FROMJSON_TABLE([{id:1,name:KES},{id:2,name:PostgreSQL}],$[*]COLUMNS(idINTPATH$.id,nameVARCHAR(50)PATH$.name))ASjt;2.实用函数示例在实际开发中JSON_ARRAY_APPEND与JSON_PRETTY是使用频率较高的函数下面是添加嵌套JSON数组元素并格式化显示的示例-- 启用MySQL兼容JSON扩展CREATEEXTENSION mysql_json;-- 向嵌套数组添加元素SELECTJSON_PRETTY(JSON_ARRAY_APPEND({users:[{name:Alice,hobbies:[reading]}]},$.users[0].hobbies,coding));执行之后就自动格式化成漂亮的JSON添加进去的数组结构一清二楚{users:[{name:Alice,hobbies:[reading,coding]}]}注意事项 在使用MySQL风格的JSON函数之前必须执行 CREATE EXTENSION mysql_json 命令否则会导致“函数不存在”的错误这个扩展包含了JSON_ARRAY_APPEND、JSON_INSERT等兼容函数。3. JSON与JSONB的选型建议KES支持JSON和JSONB两种类型各有各的好我给大家分析分析类型优势场景性能特点JSON批量写入、日志存储写入速度快无索引支持JSONB复杂查询、频繁更新查询性能优异支持GIN索引我做过测试单表JSON数据超过100万行时JSONB查询比JSON快3 - 5倍但是批量插入慢15% - 20%按照业务读写比例来选写多读少用JSON读多写少用JSONB读写差不多就优先JSONB这是我个人的经验。功能演进与高级特性JSON_EXTRACT开发陷阱JSON_SET和JSON_INSERT的区别在于当键已存在时前者会覆盖旧值后者则不会做任何改变如果对已经存在的score字段使用JSON_INSERT就无法更新分数。总结KES的PL/SQL能力深度解读从语法到性能我查了资料金仓数据库(KES)对PL/SQL的支持是分层的想知道KES到底有多兼容可以从基础语法、复杂逻辑处理和系统包依赖这三方面看先说基础语法KES和Oracle的数据类型、控制语句支持得很像特别是集合类型VARRAY的声明和初始化语法跟Oracle一模一样原来怎么定义数组现在还怎么定义一行代码都不用改这种兼容性不但省钱省力而且保证代码逻辑不变我觉得这点很好。在复杂逻辑处理上KES对嵌套子程序、递归函数这些高级功能的支持都很不错动态SQL的表现也让我很惊喜我做了个测试拼接1000行SQL字符串的时候KES比Oracle慢了5%但是长时间运行下来它的错误处理比较稳定没有因为SQL太复杂就崩掉过不过有个小地方要注意PL/SQL11g的CONTINUE语句可以用但是12c的PLS_INTEGER溢出处理机制不一样迁移的时候要单独适配我在这方面踩过坑。系统包依赖以及异常处理都是用来判断兼容性的关键因素KES可以支持大部分的标准异常处理流程但是用户自己定义的异常USER - DEFINEDEXCEPTION的错误码需要手动去修改这一点非常容易忘记我就因为这点而导致了异常捕获逻辑失效大家一定要记住这一点有人问起批量数据处理的能力如何我试过之后发现KES不但支持BULKCOLLECT语法就连LIMIT子句的用法也跟Oracle一模一样大规模的数据迁移完全不用害怕。迁移注意事项 从Oracle迁移到KES时需要注意两点差异一是PL/SQL12c特有的PLS_INTEGER溢出处理逻辑要重新适配二是用户自定义异常的错误码需要手动映射最好借助自动化脚本批量核查异常处理块防止遗漏。KES的PL/SQL实现基本上可以覆盖大部分的业务场景兼容性设计既考虑了语法的一致性也考虑了性能和稳定性如果要迁移一个复杂的企业应用我的建议是先测试核心模块的特性兼容性利用KES提供的兼容性视图和迁移工具这样才有可能顺利过渡少走弯路。内置函数、聚集函数、分析函数的对比与迁移实践从Oracle转到金仓数据库KES函数适配最费劲我是过来人90%的函数报错有固定套路解决办法我把函数分为内置函数、聚集函数、分析函数这三种类型用“函数类别对比示例避坑指南”的方式来分享都是实打实的经验全是干货内置函数对比与迁移要点内置函数在SQL当中是最常用的它们是否兼容直接影响业务逻辑能否顺利迁移我对比了大量高频函数发现KES与Oracle大部分时间语法和行为都是相同的不过有些函数的细微差别非常容易踩坑大家一定要留意NVL2(expr1,expr2,expr3)正则表达式函数REGEXP_SUBSTR在字符串提取方面应用较广基本语法REGEXP_SUBSTR(source_str,pattern,position,occurrence,match_param)在KES与Oracle中一致第三个参数即起始位置的处理逻辑亦相同但match_param参数支持情况不同Oracle中使用’i’标志表示不区分大小写匹配KES暂无此支持需借助NLS_LOWER函数转换达成类似效果如下例所示Oracle 语法REGEXP_SUBSTR(‘AbC123’, ‘[a-z]’, 1, 1, ‘i’)KES 等效实现REGEXP_SUBSTR(NLS_LOWER(‘AbC123’), ‘[a-z]’, 1, 1)说明通过 NLS_LOWER 将源字符串统一转换为小写后再进行匹配达到不区分大小写的效果。DATE类型函数迁移简直是“雷区”TRUNC(DATE)把我坑惨了非标准格式的日期字符串像’YYYY/MM/DD’或者’DD-MON-YYYY’KES和Oracle解析方式差远了Oracle靠NLS_DATE_FORMAT参数暗中转换KES可不这么干格式不对直接报错我用血泪教训总结出来迁移之前一定要用函数校验工具把所有DATE类型函数调用扫描一遍别等到数据出问题才追悔莫及user_name很多人对COUNT函数的性能有误解我查了执行计划在KES里COUNT()和COUNT(1)一模一样都是扫描聚簇索引统计行数不存在谁快谁慢的问题听我的别再传“COUNT(1)比COUNT()快”这种话了SQL语义正确比乱优化强多了而且AVG函数处理NULL值的方式跟Oracle一样都是排除NULL值计算这个可以直接迁移不用改。分析函数(窗口函数)是复杂报表查询的关键KES对窗口函数的语法支持与Oracle完全一致PARTITIONBY、ORDERBY以及窗口框架定义等重要子句均被支持只是在NULL值排序行为方面存在不同之处需特别注意。ORDER BY create_time窗口函数语法兼容给迁移带来方便不过函数嵌套情况也要重视起来分析函数在做子查询条件或者和聚集函数一起用的时候得查证执行计划是否一样保证KES能准确识别窗口框架并选出合适的执行路线最好针对包含多层嵌套的复杂分析函数查询做单独测试如果必须的话就重新写SQL或者加hint来提升性能。迁移校验建议 函数虽“即插即用”但仍要构建三层校验机制语法兼容性校验利用迁移工具批量扫描函数调用语法功能等效性测试对比相同输入数据的输出结果性能基准测试保证迁移后查询性能符合业务要求DATE类型和窗口函数最好实施全量用例测试。总的来讲金仓数据库的函数兼容性还是不错的大多情形下都能够顺利迁移按照我的经验来看迁移的时候要重点关注DATE函数的格式处理NULL值排序以及JSON聚合函数这三个地方有针对性地作出调整再好好做一番测试这样就能少碰上不少麻烦从而保证业务系统平稳过渡。结论国产数据库迁移的现状与未来我感觉金仓数据库(KES)在Oracle迁移这块已经从“能跑起来”进步到“跑得很好”了它不但PL/SQL语法兼容得好而且通过性能改良和生态营造渐渐缩小同Oracle的差距讲个真实例子我知道有个项目300万行代码的系统迁到KES之后运维费用下降40%这显示国产数据库在企业级应用当中真的成熟起来。迁移实践建议 金仓技术博客https://kingbase.com.cn/explore有迁移实战技巧、函数对比表等资源可供参考想找低风险Oracle替代方案的企业可以考虑KES的兼容性与性能。从行业发展来说国产数据库不再只是语法兼容了现在更重视性能改进与生态完善企业数字化转型时对自主可控的数据库需求会越来越大KES这些国产数据库的技术发展和经验积累能够给企业提供更为可靠的迁移方案我想对那些想要做数据库国产化的企业说一句按照业务场景的需求多用现成的迁移工具和社区资源可以避开很多弯路削减转型的风险。