还剩10页未读,继续阅读
本资源只提供10页预览,全部文档请下载后查看!喜欢就下载吧,查找使用更方便
文本内容:
SQL编码样式书写规范指南(全)SQL是数据库查询语言,MIMIC.eICU数据库等数据提取可以使用SQL语言来提取,今天分享一篇文档,主要介绍SQL编程需要注意的事项以下是正文目录
1.Overview综述
2.General一般原则
2.1D应该做的事情
2.2Avoid应避免的事情
3.Namingconventions命名惯例
3.1General一般原则
3.2Tables表名
3.3Columns歹U名
3.4Aliasingorcorrelations别名与关联名
3.5Storedprocedures存储过程名
3.6Uniformsuffix统一的后缀
4.Querysyntax查询语句
4.1Reservedwords保留字
4.2Whitespace空白字符
4.3Indentation缩进
4.4Preferredformalisms推荐的形式
5.Createsyntax创建语句
5.1Choosingdatatypes选择数据类型
5.2Specifyingdefaultvalues指定默认类型
5.3Constraintsandkeys约束和键
5.4Designtoavoid应该避免的设计6附录
6.1Columndatatypes列的数据类型这篇文档翻译自以署名-相同方式共享
4.0国际协议发布的sqlstyle.guide译文以与原文同样的协议发布bySimonHolywell-@TreffynnonTranslatedby:wontoncoder-penghou
6205.4Designtoavoid应该避免的设计在关系型数据库的设计中应用面向对象设计思想(原则)一一面向对象设计思想(原则)并不能很好地适用于关系型数据库的设计,避免这个陷阱.将值存入一列并将其单位存在另一列一一列的定义应该让自己的单位不言自明以避免在应用内进行合并使用CHECKQ来保证插入的数据是合法的EAV(EntityAttributeValue)表应该用专门的产品来处理这样的无模式数据因为某些原因(如为了根据时间归档、为了划分跨国组织的区域)将本应该放在一个表中的数据分到多个表中一一这样的设计导致以后必须使用UNION操作而不能直接查询一个表
6.附录Columndatatypes列的数据类型出于在数据库引擎之间达到最大程度兼容的目的,下面是一些建议使用的列数据类型Charactertypes字符型CHARCLOBVARCHAR
6.
1.2Numerictypes数值型精确数值类型BIGINTDECIMALDECFLOATINTEGERNUMERICSMALLINT近似数值类型DOUBLEPRECISIONFLOATREAL
6.
1.3Datetimetypes日期时间类型DATETIMETIMESTAMPBinarytypes二进制类型BINARYBLOBVARBINARYAdditionaltypes其他类型BooleanINTERVALXML原文链接:sqlstyle.guide/zh/SQL样式指南•SQLStyleGuideOverview综述General一般原则D应该做的事情°Avoid应避免的事情Namingjonventi”命名惯例°General一般原则oTables表名oColumns歹j名oAliasingorcorrelations另!J名与关联名oStoredprocedures存储过程名oUniformsuffix统一的后缀Querysyntax查询语句Overview综述你可以直接使用这些指导方针,或者fork后创建自己的版本——最重要的是选择一套方针并严格遵守它欢迎通过在GitHub上提交issue或pullrequest来提交建议或修复bug0为了让阅读了JoeCelko的《SQLProgrammingStyle^的团队能更容易采用这套规则,这套原则被设计成与该书兼容的形式本指南在某些领域严一些,在另一些领域松一些当然本指南比Celko的书更简洁一些——因为Celko的书包含了一些趣闻和每一条原则后的理由将该文档的Markdown格式添加到项目代码库中或将该页面的链接发送给项目的所有参与者要比传阅实体书容易得多SimonHolywell所著的《SQL样式指南》以署名-相同方式共享
4.0国际协议发布改编自sqlstyle.guideGeneral一般原则Do应该做的事情使用一致的、描述性的名称.合理地使用空格和缩进来增强可读性存储符合ISO-8601标准的日期格式YYYY-MM-DDHH:MM:SS.SSSSS为了提高可移植性,最好仅使用标准SQL函数而不是特定供应商的函数保证代码简洁明了、没有多余的SQL——比如非必要的引号或括号,或者可以推导出的WHERE子句必要时在SQL代码中加入注释优先使用C语言式的以/*开始以*/结束的块注释或使用以一开始的行注释,并在末尾换行file_hashfile_syste*Updatingthefilerecordafterwritingtothefile*/|JPDATEfile_systeSETfile[modified_date=1980-02-2213:19:
01.00000filename=」Avoid应避免的事情驼峰命名法,它不适合快速扫读描述性的前缀或匈牙利命名法比如sp_或tblo复数形式,尽量使用更自然的集合术语比如,用“staff”替代“employees,或用people替代individuals被引号包裹的标识符quotedidentifier如果你必须使用这样的标识符,最好坚持用SQL92的双引号来提高可移植性你可能需要配置你的SQL服务器以支持此特性,具体取决于供应商面向对象编程的原则不该应用到SQL或数据库结构上Namingconventions命名惯例General一般原则保证名字独一无二且不是保留字保证名字长度不超过30个字节,实际上,如果你不使用多字节字符集,就是30个字符名字要以字母开头,不能以下划线结尾只在名字中使用字母、数字和下划线不要在名字中出现连续下划线,这样很难辨认在名字中需要空格的地方用下划线代替(firstname变为first_name)0尽量避免使用缩写词使用时一定确定这个缩写简明易懂JELECfirst_nameFROMTables表名使用集合名称,或在不那么理想的情况下使用复数形式如staff(建议使用)和employeeSo不要使用类似tbl或其他的描述性的前缀或匈牙利命名法表不应该同它的列同名,反之亦然尽量避免连接两个表的名字作为关系表(relationshiptable)的名字与其使用cars_mechanics做表名不如使用servicesColumns列名总是使用单数形式避免直接使用id做表的主标识符避免列名和表名同名,反之亦然总是使用小写字母,除非是特殊情况,如专有名词Aliasingorcorrelations别名与关联名别名应该与它们所指的对象或表达式相关联一般来说,关联名应该由对象名中每一个单词的首字母组成如果已经有相同的关联名了,那么在关联名后加一个数字总是加上AS关键字,因为这样的明确声明易于阅读为计算出的数据(SUMQ或AVGQ)命名时,用一个将这条数据存在表中时会使用的列名SELECTfirst_nameASfn|FROMstaff—ASsstudentss2ONs
2.mentor_id=sl7staff_numj^^^^^HSELECTSUMs.monitor_tallyASmonitor_totalFROMstaffASs;Storedprocedures存储过程名名字一定要包含动词不要附加sp_或任何其他这样的描述性的前缀或使用匈牙利表示法Uniformsuffix统一的后缀下列后缀有统一的意义,能保证SQL代码更容易理解在合适的时候使用正确的后缀・Jd——独一无二的标识符,如主键.status标志值或任何表示状态的值,比如publication.statuSo.total——总和或某些值的和num——表示该字段包含数值.name表示名字,例如first_nameo_seq包含一系列值.date表示该列包含日期.tally计数值.size一一大小,如文件大小或服装大小_addr地址,有形的或无形的,如ip_addr
4.Querysyntax查询语句Reservedwords保留字关键字总是大写,如SELECT和WHERE最好使用关键字的全称而不是简写,用ABSOLUTE而不用ABS当标准ANSISQL关键字能完成相同的事情时不要使用数据库服务器特定的关键字,这样能增强可移植性model__nuFROMphonesWHEREp.release_date2014-09-30Whitespace空白字符正确地使用空白字符对清晰的代码十分重要不要把代码堆在一起或移除自然语言中的空格Spaces空格用空格使根关键字都结束在同一列上在代码中间形成一个从上到下的〃川流,这样帮助读者快速扫视代码并将关键字和实现细节分开川流在排版时应该避免,但是对阅读SQL语句是有帮助的SELECLspecies_nameAVGf.heigtASaveragn_heightAVGf.diameterASaverage_diameteHFROMfloraf.species_name二■■翁.愚.矍....鬻翼f.specics_name二,■■■■♦■■■..♦.■■♦■■■■■■■.f.species_name=Wattle■号,f.spucies_namejf.UNIONAL.species_nameAVGb.height_ASaverage上eightAVrb.diamvteaASavnragjdiametarFROMbotanic_garden_florab.species__name二..■■♦♦•■■.♦b.species_name=b.species_name二Wattle1b.species_naiYie』b.注意SELECT和FROM等关键字都右对齐,而实际的列名和实现细节都左对齐注意下列情况总是加入空格在等号(=)前后在逗号(,)后成对的单引号(’)前后,除非在括号中或后面是逗号/分号a.titlea.release_datearecording_date|albumsCharcoaa.title=TheNewDanger三,期,„豫炎,
4.
2.2Linespacing换行总是换行的情况在AND或OR前在分号后(分隔语句以提高可读性)在每个关键字定义之后将多个列组成一个逻辑组时的逗号后将代码分隔成相关联的多个部分,帮助提高大段代码的可读性让所有的关键字右对齐、所有的值左对齐,这样就能在查询语句中间留出一个空隙有助于快速扫读整个查询的定义INSERTINTOalbumstitlerelease_daterecording_dateVALUESCharcoalLane1990-01-0101:01:
01.000001990・01・0101:01:
01.00000|TheNewDanger2008-01-0101:01:
01.000001990-01-0101:01:
01.00000j;albumreleasjdate二二TheNewDanger1iELECTaltitlea.release_datearecording_dateaproduction_date——将所有的II期放在——起albumsa.title二三整.番Indentation缩进为确保SQL的可读性,一定要遵守下列规则JoinsJoin语句Join语句应该缩进到J11流的另一侧并在必要的时候添加一个换行r.last_name:INNERJOIN而/ONr.bike_vin_num=b.vin_num||ANDb.engine_tallyINNERJOINcrewASONr.crew_chief_last_name=c.last_name|ANDYSubqueries子查询子查询应该在J11流的右侧对齐并使用其他查询相同的样式有时候将右括号单独置于一行并同与它配对的左括号对齐是有意义的一一尤其是当存在嵌套子查询的时候SELECT「.lastname■嬲^SELECTMAXYEARchampFROMchampionsASc-MMMU|||||l||||||||||m||WHEREc.last_name=ANDc.confirmed=YASlast_championship_year|r1ast_nameWHEREYEARchampionship_date1;1;ANDc.confirmed二1Y;,■■■§毅—Preferredformalisms推荐的形式尽量使用BETWEEN而不是多个AND语句同样地,使用INQ而不是多个OR语句当数据输出数据库时需要处理时,使用CASE表达式CASE语句能嵌套形成更复杂的逻辑结构尽量避免UNION语句和临时表如果数据库架构能够不靠这些语句运行,那么多数情况下它就不应该依靠这些语句iELECTCASEpostcodWHENBN1THENBrightonWHENEH1THEN1Edinburghoffice_locationscountryt:edK—AND^opening_timeBETWEEN8ANDpostcodA工NEHlBN1‘NN1:[KW1;Createsyntax创建语句声明模式信息时维护可读代码也很重要所以列定义的顺序和分组一定要有意义在CREATE定义中,每个列定义要缩进4个空格Choosingdatatypes选择数据类型尽量不使用供应商相关的数据类型一一这些类型不可移植甚至有可能不能在相同供应商的旧版本系统上使用只在真的需要浮点数运算的时候才使用REAL和FLOAT类型,否则使用NUMERIC和DECIMAL类型浮点数舍入误差是个麻烦Specifyingdefaultvalues指定默认类型默认值一定与列的类型相同一一如果一个列的类型是DECIMAL那么就不要使用INTEGER类型的值作为默认值默认值要紧跟类型声明并在NOTNULL声明前Constraintsandkeys约束和键约束和键是构成数据库系统的重要组成部分它们能很快地变得难以阅读和理解,所以遵从指导方针是很重要的Choosingkeys选择键设计时应该谨慎选择构成键的列,因为键会影响性能和数据完整性键在某种程度上应该是独一无二的该值在不同表中的类型应该相同并且尽量不会更改该值能否通过某种标准格式(如ISO发布的标准)?鼓励与前面第二点一致尽量让键保持简单,但在适当情况下不要害怕使用复合键以上是定义数据库时合乎逻辑的平衡做法当需求变更时,键也应该根据情况更新
5.
3.2Definingconstraints定义约束确定键后,就可以用约束和字值段验证来定义它们General概述表至少需要一个键来保证其完整性和可用性・除了UNIQUE、PRIMARYKEY和FOREIGNKEY之外(数据库供应商会提供相应的检查),约束应该有名字Layoutandorder布局和顺序在CREATETABLE语句后先定义主键约束的定义应该紧跟它相应的列的定义后如果该约束与多个列相关,那么让它离相关的列越近越好实在不行就将它放在表定义的最后如果是应用于整个表的表级别的约束,那么就将它放在表定义的最后按照字母顺序安排定义,ONDELETE排在ONUPDATE前有道理的话,把所有相关的语句对齐比如,把所有NOTNULL定义对齐到同一列这样做并不难,但是能提高可读性
5.
3.
2.3Validation校验当字符串的格式已知时,用LIKE和SIMILARTO约束来保证它们的完整性当数值的范围可以确定时,用范围CHECKQ来防止错误的值进入数据库或在没有提示的情况下截断大部分情况下至少要确认数值大于零CHECKQ约束应该在单独的子句中以便debugostaffPRIMARYfirst二nameVARCHAR100CONSTRAINIpens_in_draCHECKpens_in_drawerBETWEEN1AND99Efl。