zoukankan      html  css  js  c++  java
  • 数据库表的命名规范

    1.表名一般以【模块名称_详细表名】来实现,同一个模块的前缀是一样的。(Oracle大写和小写敏感。在SQL中能够不用"_",由于能够用大写和小写一起的写法。

    这也是能够的)

    2.表名称不应该取得太长(一般不超过三个英文单词。不推荐使用中文拼音,总的长度不要超过30个字符)。表名使用英文的原因,有些项目有英文版的须要。或者这个项目是给外国做的时候,使用英文是主要的要求。应该说这是一个习惯问题,多学一点英文也不是坏事
     
    3.不使用tab或tb作为表前缀(本来就是一个表,为什么还要说明)。

     
    4.一些作为多对多连接的表,能够使用两个表的前缀作为表名:如:用户登录表User_Login。用户分组表User_GroupInfo,这两个表建立多对多关系的表名为:User_Group_Relation(关系统一用Relation)。注意一点,主键在做其它表的外键时,或者在被其它表引用时,字段说明和字段名尽量保持一致。比方发帖表BBS_Topic里的用户字段写成UI_ID,这样跟用户信息表User_Info的主键UI_ID保持一致,看起来舒服,相应关系非常明白,也不easy错,前后不一致时easy令人费解。

      
    5.当系统中有一些少量的。反复出现的值时,使用字典表来节约存储空间和优化查询。

    如地区、系统中用户类型的代号等。这类值不会在程序的执行期变化,可是须要存储在数据库中。

    一般数据库中。都有一个数据字典表,用来保存系统所用到的基础数据,大型的字段表如省份城市区域的字典表,统一以Dictionary_作为前缀。

         
    6. 与字段有关,默认的一些特殊字段, 非常多表中。
      比方一些业务处理表中,除了加入生成的自己主动编号ID(一般作为主键用),该记录创建的时间CreateDate(创建时间),该记录的创建人CreatBy(注意这里。没UI_ID(用户信息表User_Info的主键UI_ID),由于还有改动人),最后改动人LastEditBy。最后改动时间LastEditDate。(这些能够直接使用中文字符,而不使用编码,提高查询的效率)
      同一时候有的时候须要注意,删除的时候并不真的删除该记录,而是加入一个标识位,比方XX_DeleteStaus删除状态。1是有效的,0则是无效的。

     
    7.在命名表时,用单数形式表示名称。

    比如。使用 Employee,而不是 Employees。

     
    8.数据库中应建立这样一个表。就是数据库本身的字段信息。表的说明,也就是数据库设计文档的一个表。方便查询使用,有什么不明的能够直接从数据库查询,数据库文档丢失,凝视丢失,都能够又一次起作用。

     
    9.每一个表都应该有一个主键,这个主键最好是数字。并且是递增的,有非常多表的主键用32位字符编码,这样做的目的很多其它的是从安全考虑的。由于字符多时索引时效率低,而使用自增列也不是非常少,比方加入主表和从表操作时。主表的主键是从表的外键,这个时候还有取返回值,然后再加入,不能够同一时候加入。

    主键能够用自己定义的规则,大部分用MAX(ID)的做法,也能够自己定义一个序列表,有点像序列。或者用时间的年月日秒详细到毫秒。关于列的命名,建议对数据类型也做一些规范,由于非常easy确定。仅仅有四种主要类型:数字,字符,时间,逻辑值,这些在类型上和长度上都能够定好规范,统一起来。

         
    10.操作日志表,登录日志表,这是数据库中必备的两个表。这个记录也须要做进一步的保存。这个有两种情形,一是详细到单个字段的操作日志。二是整个表的操作日志。

    常见的几个表详细说明:操作日志表Sys_OperateLog、登录日志表Sys_LoginLog、

               系统字典表Sys_Dictionary、系统字典表类型Sys_DicType

    操作日志表Sys_OperateLog
    中文名 字段名 凝视
    操作日志编号 OL_ID 索引列。日志的编号
    操作类型 OL_Type 是加入,改动,删除,查询等类容(可放在通用字典表)
    操作模块 OL_Module 操作模块。比方新闻模块,关联的是菜单表编号
    操作内容 OL_Content 操作了什么内容,越详细越好(改动前、改动后)
    操作人 UI_ID 用户的信息
    操作时间 OL_AddDate 日志记录创建时间
    操作IP OL_IP 操作人的IP地址
    备注信息 OL_Remarks 备注信息,一些其它的须要说明的信息

     这种一个操作日志比較笼统,不是能详细到详细的字段值更新,假设要详细到某个详细值的更新。则须要设计新的数据库

    普通情况下须要这样几个表。系统中可能已经有了,可是我们拿到我们自己的数据库中来,一个是数据库列表的表(就是数据库中有几个表)(编号。创建时间。创建人,改动时间,改动人,表名,凝视,是否删除),然后就是数据库表以下的字段类型(编号,创建时间,创建人,改动时间,改动人。字段名,字段类型。字段精度,字段说明,字段凝视,表的编号),也就是字段列表。这时的日志操作表能够这样设计(编号。表名。被改动的字段名,改动前值。改动后值。操作人,操作时间,相关模块,操作IP) 这样的能记录改动记录。可是加入和删除时记录就不是非常方便控制了。

    登录日志表Sys_LoginLog
    中文名 字段名 凝视
    登录日志编号 LL_ID 登录的日志编号
    登录人 UI_ID 登录人
    登录时间 LL_AddDate 登录时间
    登录IP LL_IP 登录的IP地址
    登录状态 LL_Status 登录是否成功的标识位
    登录浏览器 LL_Browser 登录浏览器
    登录分辨率 LL_Resolution 登录的屏幕分辨率

    另一个就是数据字典表。我看过非常多的数据库设计,类型表一个接一个,没有放在一起,还有的干脆写在凝视里,有的根本就没有,这样某个程序猿走了,这个字段就没人知道了,即使没走,自己也有可能时间长了忘掉,所以,见一个基础数据字典表的作用非常重要,其它的比方地区表(Sys_DicArea),汉语拼音表(Sys_DicCharacter)(用来汉字和拼音的转换)由于数据量较大,单独建表。

    这里介绍通用的数据字典表。

    系统字典表Sys_Dictionary
    中文名 字段名 凝视
    字典编号 SD_ID 字典的编号。能够直接使用此主键编码(注意删除时的关联关系)
    字典类型 DY_ID 字典类型的ID,须要建立字典类型表。由于放的是全部的字典表
    字典编码 SD_Code 字典编码,支持自己编码(同一类型是唯一的,通常是整数型
    字典中文名称 SD_Name 字典中文名称(比方男女。比方状态,能够放在字典表里,作为查看根据)
    字典备注 SD_Remarks 字典备注,字典须要一些备注信息
    创建人    
    创建日期    
    改动人    
    改动日期    
    系统字典表类型Sys_DicType
    中文名 字段名 凝视
    字典类型编号 DT_ID 字典的自己主动索引號
    字典类型名称 DT_Name 字典类型的中文名称
    字典的备注说明 DT_Remarks 字典使用的备注说明
    字典状态 DT_Status 字典是否删除,不在使用

    最后补充一些内容,一般设计数据库是这个样子的,可是不排除有些特殊的情形,为了数据的保密性,数据库的表名和字段名都是一些看似毫无意义的字符数字,比方Table1,Col1,可是有一个表是说明表,或者有相应的数据库文档设计。

    补充:一些列说明了单位类型。能够在设计数据库的时候表明,比方HeightIncm, WeightInKg.这样一目了然。

  • 相关阅读:
    flask 中的request
    悲观锁、乐观锁、行级锁、表级锁
    python标准库--functools.partial
    Django Model._meta API
    python中的urlencode与urldecode
    Django模版语言inclusion_tag的用法。
    Django的URL别名
    Django之模板语言
    django-request对象
    Java 基础
  • 原文地址:https://www.cnblogs.com/slgkaifa/p/7245519.html
Copyright © 2011-2022 走看看