JAVA develops ORACLE's specification
Zu Xianjiao Xiaofan Xianhai Shark Database Architect
Xiaoxian has been engaged in DBA for many years, and also develops database PL/SQL. Encountered many performance problems, various hidden dangers and mine pits.
One prohibits the use of long fields
因为该LONG字段类型BUG多，甲骨文对它彻底放弃了。Two prohibit the use of varchar2 storage time
很简单时间是用来加，减，排序，和范围查找。字符不提供这些，或者精度，准确不够。Three prohibit the use of varchar2 to store numbers
数字用数字字段，这里是说需要进行加工的数字，不是手机的号码。
字符字段里存数字，并且取出来加工，涉及类型转换性能损失。可能导致全表扫描。比如 where money=12000 MONEY字段是字符类型，可存的是数字，开发人员一不小心传入纯数字，就触发隐式转化。Four prohibit the use of select *
* 虽然写得方便，可谁知道后续对该表的字段添加，减少带来的坑呢？What if you add a CLOB field? Your front-end page does not display it, it is still passed from the database to TOMCAT, and then the JAR is filtered, and then thrown to the JSP.
For example, a table has 4 fields, which are
displayed on the user (id, name, money, time) page. Developers come to a
SELECT * FROM USER WHERE ID=:1 when they are in time for the project ;
N months after going online, the business needs to add a person's avatar, and a new field IMAGE CLOB type must be added.
Only after clicking the line, the page that pops up Only show the person's avatar. Of course, the later developer is responsible for the pop-up page statement
SELECT name, money, time, IMAGE FROM USER WHERE ID=:1;
Five prohibit the use of delete
不管任何数据是不能被删除的, 只能更新下状态来标注可删除.The data-side DBA maintains the data and migrates the data according to the time and sign. Then back to delete the migrated data.
Six prohibiting the use of external constraints
外键是个麻烦的事情,在JAVA界有8年的历史,把外键约束放到应用层来处理.Seven prohibit the use of triggers
触发器虽然方便,按照JAVA思想所有业务放在应用层,触发器原来本身就是带有业务特性.另外它会延伸很多SQL出来.在高并发下造成性能下降Eight prohibit the use of stored procedures
业务放在JAVA中,存储过程基本不写业务.存储过程交给DBA去维护数据吧!9. Prohibition of the use of synonyms
同义词,好像我拥有你的表,使用时不写你的名字. 这点便利没啥好处.反而因为基表不在,同义词失效情况贼多,而且与表名相同造成对象以存在.The synonym itself can be read-only account plus payment permission. It is basically OK in today's microservice era
Ten prohibit the use of dblink
DBLINK 会导致查询性能飘忽不定.而且造成被DBLINK的SCN号极大消耗.Eleven prohibits the use of order by except for paging SQL
ORDER BY 排序是消耗内存和CPU的资源操作,数据量大的话,就要到硬盘上排序. 你说你的数量小可以在数据库内存完成排序,可是你知道系统上线以后,要在数据库端排序的SQL有多少吗? 每秒几千总有吧! 这样极大消耗数据库CPU或者IO资源.以及不断膨胀的TEMP空间.大家想一下 ORDER BY 不就是让人看的舒服点啊! 这操作可以放在前端JSP,用IE去排序,消耗客户的CPU. 也可以放在应用端TOMCAT 内存里排序.Do you say that TOMCAT and database sorting are not the same?
In today's era, the application side can be clustered, can be load balanced by NGINX, and can stack servers. There is only one database, or 5-6. These servers exist only for high availability , Most of them are not for performance. Because the application servers are stateless, after being load balanced, each application server has a very light burden. But the database cannot. All SQL has a database service to provide sorting. Of course, some backup databases You can also take on part of the SQL sorting, which is SQL with low time and real-time requirements. In fact, ORDER BY developers play well, which is beneficial to accelerate the development speed.
Twelve prohibit the use of materialized views in OLTP systems
The materialized view is convenient for the reporting system. In the transaction system, the OLTP materialized view log will accumulate a lot, and querying the comparison log for a long time will consume OLTP system resources. It is
recommended to use OGG to dig data from the log and synchronize it to the corresponding table of the reporting system, and then Playing with materialized views on the reporting system.