首页 app开发 正文

数据库索引命名规则(数据库的命名规则)

app开发 104
今天给各位分享数据库索引命名规则的知识,其中也会对数据库的命名规则进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!sql server的对象命名规则是什么 自己搜索一下就是了,我给你copy一段:为了提供完善的数据库管理机制,SQL Server 设计了严格的命名规则。在创建或引用数据库实体,如表、索引、约束等时,必须遵守SQL Server 的命名规则,否则有可能发生一些难以预料和检查的错误。

今天给各位分享数据库索引命名规则的知识,其中也会对数据库的命名规则进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!

sql server的对象命名规则是什么

自己搜索一下就是了,我给你copy一段:

为了提供完善的数据库管理机制,SQL Server 设计了严格的命名规则。在创建或引用数据库实体,如表、索引、约束等时,必须遵守SQL Server 的命名规则,否则有可能发生一些难以预料和检查的错误。

本文将讲述:标识符的分类和格式规定;数据库对象的命名规定与使用原则。希望对您会有所帮助。

标识符分类

SQL Server的所有对象,包括服务器、数据库以及数据库对象,如表、视图、列、索引、触发器、存储过程、规则、默认值和约束等都可以有一个标识符。对绝大多数对象来说,标识符是必不可少的,但对某些对象如约束来说,是否规定标识符是可选的。对象的标识符一般在创建对象时定义,作为引用对象的工具使用。

例如下面的SQL语句:

Create table student

(

id int primary key,

name varchar(20)

)

这个例子创建了一个表格,表格的名字是一个标识符:student;表格中定义了两列,列的名字分别是id,name,他们都是合法的标识符。这个例子还定义另外一个未命名的主键约束。

SQL Server一共定义了两种类型的标识符:规则标识符(Regular identifier)和界定标识符(Delimited identifier)。

规则标识符

规则标识符严格遵守标识符有关格式的规定。所以在T-SQL语句中凡是规则标识符都不必使用界定符,如[]和‘’,来进行界定。

如上述例子中使用的表名student 就是一个规则标识符,在student上不必添加界定符。

界定标识符

界定标识符是那些使用了如[]和‘’等界定符号来进行位置限定的标识符,使用了界定标识符,既可以遵守标识符命名规则,也可以不遵守标识符命名规则。

Select * from [student] 是要从student 表格中查询出所有的数据与

Select * from student 等效。

为什么呢?因为在“[]”中的标识符遵守标识符命名规则,“[]”被忽略不计。

但如果是不遵守标识符命名规则的标识符,那么在T-SQL语句中必须使用界定符号加以限定,如:

Select * from [my table]

Where [order]=10

在这个例子中,必须使用界定标识符,因为在from子句中的标识符my talbe中含有空格,而where子句中的标识符order 是系统保留字(在查询分析器里“order”变蓝色)。这两个标识符都不遵守标识符命名规则,必须使用界定符,否则无法通过代码编译。

标识符格式

标识符格式的规定,其具体内容如下:

标识符的首字母必须是以下两种情况之一:

所有在统一码(Unicode)2.0标准规定的字符,包括26个英文字母a-z和A-Z,以及其他一些语言字符,如汉字。例如可以给一个表格命名为“学生基本情况”。下划线“-”、“@”或“#”。

标识符首字母后的字符可以是:

所有在统一码(Unicode)2.0标准规定的字符,包括26个英文字母a-z和A-Z,以及其他一些语言字符,如汉字。下划线“-”、“@”、“$”或“#”。

0,1,2,3,4,5,6,7,8,9。

标识符不允许是T-SQL的保留字。

由于T-SQL不区分大小写,所以无论是保留字的大写还是小写都不允许使用。

标识符内部不允许有空格或特殊字符。

Select * from stu[de]nt –编译器将返回错误信息。因为在标识符stu[de]nt中包含了特殊字符“[”和“]”,所以在编译上述语句时出错。

?

以某些特殊符号开头的标识符在SQL Server系统中具有特定的含义。如“@”开头的标识符表示这是一个局部变量或是一个函数的参数;以“#”开头的标识符表示这是一个临时表或存储过程;一个以“##”开头的标识符表示这是一个全局的临时数据库对象。T-SQL的全局变量以标志“@@”开头。为避免同这些全局变量混淆,建议不要使用“@@”作为标识符的开始。

无论是界定标识符还是规则标识符都最多只能容纳128个字符,对于本地的临时表最多可以有116个字符。

对象命名规则

SQL Server 2000 的数据库对象名字由1-128个字符组成,不区分大小写。在一个数据库中创建了一个数据库对象后,数据库对象的全名应该由服务器名、数据库名、拥有者名和对象名这四个部分组成,格式如下:

[[[server.][database].][owner_name].]object_name 命名必须都要符合标识符的规定。

在实际引用对象时,可以省略其中某部分的名称,只留下空白的位置。

实例的命名习惯

在SQL Server 2000中默认实例的名字采用计算机名,实例的名字一般由计算机名字和实例名字两部分组成。

总之,正确掌握数据库的命名和引用方式是用好SQL Server 2000的前提,也有助于用户理解SQL Server 2000中的其他内容。

数据库命名规则

对于数据库的设计中,尽量不用汉字,最好用英文,如果用汉字,有时会产生不必要的麻烦,可能产生插入,删除等等异常,而且在写存储过程或触发器等等也许会产生错误,以下对设计表和字段的一些规则,可能对提问者用帮助:

1. 检查各种变化

我在设计数据库的时候会考虑到哪些数据字段将来可能会发生变更。比方说,姓氏就是如此(注意是西方人的姓氏,比如女性结婚后从夫姓等)。所以,在建立系统存储客户信息时,我倾向于在单独的一个数据表里存储姓氏字段,而且还附加起始日和终止日等字段,这样就可以跟踪这一数据条目的变化。

2. 采用有意义的字段名

有一回我参加开发过一个项目,其中有从其他程序员那里继承的程序,那个程序员喜欢用屏幕上显示数据指示用语命名字段,这也不赖,但不幸的是,她还喜欢用一些奇怪的命名法,其命名采用了匈牙利命名和控制序号的组合形式,比如 cbo1、txt2、txt2_b 等等。

除非你在使用只面向你的缩写字段名的系统,否则请尽可能地把字段描述的清楚些。当然,也别做过头了,比如 Customer_Shipping_Address_Street_Line_1,虽然很富有说明性,但没人愿意键入这么长的名字,具体尺度就在你的把握中。

3. 采用前缀命名

如果多个表里有好多同一类型的字段(比如 FirstName),你不妨用特定表的前缀(比如 CusLastName)来帮助你标识字段。

时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。

4. 标准化和数据驱动

数据的标准化不仅方便了自己而且也方便了其他人。比方说,假如你的用户界面要访问外部数据源(文件、XML 文档、其他数据库等),你不妨把相应的连接和路径信息存储在用户界面支持表里。还有,如果用户界面执行工作流之类的任务(发送邮件、打印信笺、修改记录状态等),那么产生工作流的数据也可以存放在数据库里。预先安排总需要付出努力,但如果这些过程采用数据驱动而非硬编码的方式,那么策略变更和维护都会方便得多。事实上,如果过程是数据驱动的,你就可以把相当大的责任推给用户,由用户来维护自己的工作流过程。

5. 标准化不能过头

对那些不熟悉标准化一词(normalization)的人而言,标准化可以保证表内的字段都是最基础的要素,而这一措施有助于消除数据库中的数据冗余。标准化有好几种形式,但 Third Normal Form(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说,3NF 规定:

* 表内的每一个值都只能被表达一次。

* 表内的每一行都应该被唯一的标识(有唯一键)。

* 表内不应该存储依赖于其他键的非键信息。

遵守 3NF 标准的数据库具有以下特点:有一组表专门存放通过键连接起来的关联数据。比方说,某个存放客户及其有关定单的 3NF 数据库就可能有两个表:Customer 和 Order。Order 表不包含定单关联客户的任何信息,但表内会存放一个键值,该键指向 Customer 表里包含该客户信息的那一行。

更高层次的标准化也有,但更标准是否就一定更好呢?答案是不一定。事实上,对某些项目来说,甚至就连 3NF 都可能给数据库引入太高的复杂性。

为了效率的缘故,对表不进行标准化有时也是必要的,这样的例子很多。曾经有个开发餐饮分析软件的活就是用非标准化表把查询时间从平均 40 秒降低到了两秒左右。虽然我不得不这么做,但我绝不把数据表的非标准化当作当然的设计理念。而具体的操作不过是一种派生。所以如果表出了问题重新产生非标准化的表是完全可能的。

6. Microsoft Visual FoxPro 报表技巧

如果你正在使用 Microsoft Visual FoxPro,你可以用对用户友好的字段名来代替编号的名称:比如用 Customer Name 代替 txtCNaM。这样,当你用向导程序 [Wizards,台湾人称为‘精灵’] 创建表单和报表时,其名字会让那些不是程序员的人更容易阅读。

7. 不活跃或者不采用的指示符

增加一个字段表示所在记录是否在业务中不再活跃挺有用的。不管是客户、员工还是其他什么人,这样做都能有助于再运行查询的时候过滤活跃或者不活跃状态。同时还消除了新用户在采用数据时所面临的一些问题,比如,某些记录可能不再为他们所用,再删除的时候可以起到一定的防范作用。

8. 使用角色实体定义属于某类别的列[字段]

在需要对属于特定类别或者具有特定角色的事物做定义时,可以用角色实体来创建特定的时间关联关系,从而可以实现自我文档化。

这里的含义不是让 PERSON 实体带有 Title 字段,而是说,为什么不用 PERSON 实体和 PERSON_TYPE 实体来描述人员呢?比方说,当 John Smith, Engineer 提升为 John Smith, Director 乃至最后爬到 John Smith, CIO 的高位,而所有你要做的不过是改变两个表 PERSON 和 PERSON_TYPE 之间关系的键值,同时增加一个日期/时间字段来知道变化是何时发生的。这样,你的 PERSON_TYPE 表就包含了所有 PERSON 的可能类型,比如 Associate、Engineer、Director、CIO 或者 CEO 等。

还有个替代办法就是改变 PERSON 记录来反映新头衔的变化,不过这样一来在时间上无法跟踪个人所处位置的具体时间。

• 采用常用实体命名机构数据

组织数据的最简单办法就是采用常用名字,比如:PERSON、ORGANIZATION、ADDRESS 和 PHONE 等等。当你把这些常用的一般名字组合起来或者创建特定的相应副实体时,你就得到了自己用的特殊版本。开始的时候采用一般术语的主要原因在于所有的具体用户都能对抽象事物具体化。

有了这些抽象表示,你就可以在第 2 级标识中采用自己的特殊名称,比如,PERSON 可能是 Employee、Spouse、Patient、Client、Customer、Vendor 或者 Teacher 等。同样的,ORGANIZATION 也可能是 MyCompany、MyDepartment、Competitor、Hospital、Warehouse、Government 等。最后 ADDRESS 可以具体为 Site、Location、Home、Work、Client、Vendor、Corporate 和 FieldOffice 等。

采用一般抽象术语来标识“事物”的类别可以让你在关联数据以满足业务要求方面获得巨大的灵活性,同时这样做还可以显著降低数据存储所需的冗余量。

• 用户来自世界各地

在设计用到网络或者具有其他国际特性的数据库时,一定要记住大多数国家都有不同的字段格式,比如邮政编码等,有些国家,比如新西兰就没有邮政编码一说。

• 数据重复需要采用分立的数据表

如果你发现自己在重复输入数据,请创建新表和新的关系。

• 每个表中都应该添加的 3 个有用的字段

* dRecordCreationDate,在 VB 下默认是 Now(),而在 SQL Server 下默认为 GETDATE()

* sRecordCreator,在 SQL Server 下默认为 NOT NULL DEFAULT USER

* nRecordVersion,记录的版本标记;有助于准确说明记录中出现 null 数据或者丢失数据的原因

• 对地址和电话采用多个字段

描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和 Address_Line3 可以提供更大的灵活性。还有,电话号码和邮件地址最好拥有自己的数据表,其间具有自身的类型和标记类别。

过分标准化可要小心,这样做可能会导致性能上出现问题。虽然地址和电话表分离通常可以达到最佳状态,但是如果需要经常访问这类信息,或许在其父表中存放“首选”信息(比如 Customer 等)更为妥当些。非标准化和加速访问之间的妥协是有一定意义的。

• 使用多个名称字段

我觉得很吃惊,许多人在数据库里就给 name 留一个字段。我觉得只有刚入门的开发人员才会这么做,但实际上网上这种做法非常普遍。我建议应该把姓氏和名字当作两个字段来处理,然后在查询的时候再把他们组合起来。

我最常用的是在同一表中创建一个计算列[字段],通过它可以自动地连接标准化后的字段,这样数据变动的时候它也跟着变。不过,这样做在采用建模软件时得很机灵才行。总之,采用连接字段的方式可以有效的隔离用户应用和开发人员界面。

• 提防大小写混用的对象名和特殊字符

过去最令我恼火的事情之一就是数据库里有大小写混用的对象名,比如 CustomerData。这一问题从 Access 到 Oracle 数据库都存在。我不喜欢采用这种大小写混用的对象命名方法,结果还不得不手工修改名字。想想看,这种数据库/应用程序能混到采用更强大数据库的那一天吗?采用全部大写而且包含下划符的名字具有更好的可读性(CUSTOMER_DATA),绝对不要在对象名的字符之间留空格。

• 小心保留词

要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突,比如,最近我编写的一个 ODBC 连接程序里有个表,其中就用了 DESC 作为说明字段名。后果可想而知!DESC 是 DESCENDING 缩写后的保留词。表里的一个 SELECT * 语句倒是能用,但我得到的却是一大堆毫无用处的信息。

• 保持字段名和类型的一致性

在命名字段并为其指定数据类型的时候一定要保证一致性。假如字段在某个表中叫做“agreement_number”,你就别在另一个表里把名字改成“ref1”。假如数据类型在一个表里是整数,那在另一个表里可就别变成字符型了。记住,你干完自己的活了,其他人还要用你的数据库呢。

• 仔细选择数字类型

在 SQL 中使用 smallint 和 tinyint 类型要特别小心,比如,假如你想看看月销售总额,你的总额字段类型是 smallint,那么,如果总额超过了 $32,767 你就不能进行计算操作了。

• 删除标记

在表中包含一个“删除标记”字段,这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据程序而且要仔细维护索引整体性。

• 避免使用触发器

触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器,你最好集中对它文档化。

• 包含版本机制

建议你在数据库中引入版本控制机制来确定使用中的数据库的版本。无论如何你都要实现这一要求。时间一长,用户的需求总是会改变的。最终可能会要求修改数据库结构。虽然你可以通过检查新字段或者索引来确定数据库结构的版本,但我发现把版本信息直接存放到数据库中不更为方便吗?。

• 给文本字段留足余量

ID 类型的文本字段,比如客户 ID 或定单号等等都应该设置得比一般想象更大,因为时间不长你多半就会因为要添加额外的字符而难堪不已。比方说,假设你的客户 ID 为 10 位数长。那你应该把数据库表字段的长度设为 12 或者 13 个字符长。这算浪费空间吗?是有一点,但也没你想象的那么多:一个字段加长 3 个字符在有 1 百万条记录,再加上一点索引的情况下才不过让整个数据库多占据 3MB 的空间。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。身份证的号码从 15 位变成 18 位就是最好和最惨痛的例子。

• 列[字段]命名技巧

我们发现,假如你给每个表的列[字段]名都采用统一的前缀,那么在编写 SQL 表达式的时候会得到大大的简化。这样做也确实有缺点,比如破坏了自动表连接工具的作用,后者把公共列[字段]名同某些数据库联系起来,不过就连这些工具有时不也连接错误嘛。举个简单的例子,假设有两个表:

Customer 和 Order。Customer 表的前缀是 cu_,所以该表内的子段名如下:cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前缀是 or_,所以子段名是:

or_order_id、or_cust_name_id、or_quantity 和 or_description 等。

这样从数据库中选出全部数据的 SQL 语句可以写成如下所示:

Select * From Customer, Order Where cu_surname = "MYNAME" ;

and cu_name_id = or_cust_name_id and or_quantity = 1

在没有这些前缀的情况下则写成这个样子(用别名来区分):

Select * From Customer, Order Where Customer.surname = "MYNAME" ;

and Customer.name_id = Order.cust_name_id and Order.quantity = 1

第 1 个 SQL 语句没少键入多少字符。但如果查询涉及到 5 个表乃至更多的列[字段]你就知道这个技巧多有用了。

在Access中,字段的命名规则是( )

在Access中,字段的命名规则:

1、字段名长度为1~64个字符。

2、字段名可以包含字母,汉字,数字,空格,和其他字符。

3、字段名不能以空格开头,不能包含句号,感叹号,方括号和单引号。

4、字段名不能使用ASCII为0-32的ASCII字符。

注意:虽然说字段名可以加上空格,但是开头不能使用空格,为了以后查询数据比较方便,中间也最好不要加上空格。

扩展资料

常用的数据库字段类型

CHAR:固定长度字符串,最大长度2000bytes。

VARCHAR2:可变长度的字符串,最大长度4000bytes,可做索引的最大长度749。

NCHAR:根据字符集而定的固定长度字符串,最大长度2000bytes。

NVARCHAR2:根据字符集而定的可变长度字符串,最大长度4000bytes。

DATE:日期(日-月-年),DD-MM-YY(HH-MI-SS),经过严格测试,无千虫问题。

LONG:超长字符串,最大长度2G(231-1),足够存储大部头著作。

RAW: 固定长度的二进制数据, 最大长度2000bytes, 可存放多媒体图象声音等。

INTEGER:整数类型,小的整数。

FLOAT:浮点数类型,NUMBER(38),双精度。

REAL:实数类型,NUMBER(63),精度更高。

sql建视图索引

你试下 去掉 where 条件的 [dbo] , 如果不行 参考下 下面的,方法 ~ 希望对你有用同学 在视图上创建索引的另一个好处是:查询优化器开始在查询中使用视图索引,而不是直接在 FROM 子句中命令视图。这样一来,可从索引视图检索数据而无需重新编码,由此带来的高效率也使现有查询获益。在视图上创建的第一个索引必须是唯一聚集索引。在创建唯一聚集索引后,可创建其它非聚集索引。视图上的索引命名规则与表上的索引命名规则相同。唯一区别是表名由视图名替换。(Sql Server联机帮助)

没研究过,说不出什么东西来,现在只把方法记下来。

语句:

Create VIEW vXXX WITH SCHEMABINDING AS……

Create UNIQUE CLUSTERED INDEX idxXXX ON vXXX(cXXX)

一个标准视图转换为一个索引视图必须遵守以下规则:

A.视图必须使用With Schemabinding选项来创建;

如果创建视图时没有with Schemabinding,试图创建视图时就会报错:……因为该视图未绑定到架构

B.在这个视图中不能使用其他视图、导出表、行集函数或自查询,也就是说只能使用表;

C.视图所用到的基本表必须和视图属于同一个所有者;

D.视图只能链接同一个数据库中的表;

E.视图不能包含一个外部链接或自链接,也就是说在链接表时只能使用INNER JOIN并且INNER JOIN前后不能使同一个表,不能使用LEFT(RIGHT) JOIN 或者 LEFT (RIGHT) OUTER JOIN ;

F. 视图不能包含UNION子句、TOP子句、ORDER BY子句、Having子句、Rollup子句、Cube子句、compute子句、Compute By子句或Distinct关键字;

G. 视图不允许使用某些集合函数,如:Count(*)可以使用count_big(*)代替、avg()、max()、min()、stdev()、stdevp()、var()或varp()等;

H. 视图不能使用Select * 这样的语句,也就是说视图的所有字段都必须显示指定;

I. 视图不能包含Text、ntext、image类型的列;

J. 如果视图包含一个Group By子句,那么他必须在Select列中包含count_big(*);

K. 视图中的所有标和用户自定义的函数都必须使用两段式名来引用,即所有者.表或函数名称;

L. 所有的基本表和视图都必须使用 Set Ansi_Nulls On 创建;

M. 在创建索引时或创建索引后执行IUD时,必须显示或隐式地执行:

Set ANSI_NULLS ON

SET ANSI_PADDING ON

SET ANSI_WARNINGS ON

SET ARITHABORT ON

SET CONCAT_NULL_YIELDS_NULL ON

SET QUOTED_IDENTIFIER ON

SET NUMERIC_ROUNDABORT OFF

各个选项的有关信息或意义,可以查阅SQL Server的联机丛书,这里就不再介绍了;

N. 索引视图只有在SQL Server2000的企业版或开发版或者更高的版本中才能创建。

在一个表上创建了索引视图后,对其执行delete操作时报错:Delete 失败,因为下列 SET 选项的设置不正确: 'CONCAT_NULL_YIELDS_NULL, ANSI_PADDING,ARITHABORT',删除这个视图问题就解决了

mysql中数据库名字分大小写吗?

分大小写。

MySQL在Linux下数据库名、表名、列名、别名大小写规则是这样的:数据库名与表名是严格区分大小写的;表的别名是严格区分大小写的;列名与列的别名在所有的情况下均是忽略大小写的;变量名也是严格区分大小写的;MySQL在Windows下都不区分大小写。

不区分大小写在MySQL中,数据库和表对就于那些目录下的目录和文件。因而,操作系统的敏感性决定数据库和表命名的大小写敏感。这就意味着数据库和表名在Windows中是大小写不敏感的,而在大多数类型的Unix系统中是大小写敏感的。

应用环境

与其他的大型数据库例如 Oracle、DB2、SQL Server等相比,MySQL自有它的不足之处,但是这丝毫也没有减少它受欢迎的程度。对于一般的个人使用者和中小型企业来说,MySQL提供的功能已经绰绰有余,而且由于 MySQL是开放源码软件,因此可以大大降低总体拥有成本。

索引是一种特殊的文件(InnoDB 数据表上的索引是表空间的一个组成部分),它们包含着对数据表里所有记录的引用指针。索引不是万能的,索引可以加快数据检索操作,但会使数据修改操作变慢。

以上内容参考:百度百科-mySQL

“oracle”的命名规范是什么?

标准命名规则要满足如下要求:以字符开头,30个字符以内,只能包含A-Z,a-z,0-9,_,$,#,不能和同一个用户下的其他对象重名,不能是oracle服务器的保留字

还有一类是非标准命名,可以使用任何字符,包括中文,oracle中的保留字,空格等等都是可以的,但是需要将对象名用双引号引起来。

命名规范

一、基本原则:规范的命名能使对象更易阅读,可以提供一些标识功能方面的信息,有助于更好的理解其用途。特别是加前缀的命名方式可以为数据库对象的管理和浏览带来极大便利,同时也能清晰地与其他工具建立的对象进行区别。

1、表(Table)1)表的命名采用英文与下划线组合的命名规则:

表名的长度一般不允许超过20个字符。要求使用英文,不能使得拼音,英文单词的字母要求大写,多个单词间用下划线连接,"_";关联表命名规则为:前缀_RELA_表A_表B。采用的英文单词应尽量为常用单词,英文单词过长时,可以采用适当的简写(一般是前4个字符),如果CODE仅有一个单词,要求不使用缩写,而是采用完整的单词。一般下划线不应多于四个;

2、词意准确性,要尽可能采用专业词汇和国际标准词汇:

包括:IEC通用电力标准、中国电力行业标准、国际会计标准协会 IASB 国际会计准则等通用行业术语。

3、高频词汇优先原则:

如遇多个单词均可反映表的内容,要求采用 GOOGLE 的标准译法,也就是使用频率最多的单词优先选用原则。

二、索引(Index)

1、B-TREE索引命名:IDX_表名_字段组合,如命名太长则:IDX_表名_首字段。

2、BITMAP索引命名:BIT_表名_字段组合,如命名太长则:BIT_表名_首字段。

3、分区NORMAL索引命名:LOC_表名_字段组合,如命名太长则:LOC_表名_首字段。

4、分区BITMAP索引命名:BLOC_表名_字段组合,如命名太长则:BLOC_表名_首字段。

5、主键索引和唯一性索引的命名同约束命名。

关于数据库索引命名规则和数据库的命名规则的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。

数据库索引命名规则 数据库字段名称命名规则数据库标识符的命名规则数据库名称的命名规则数据库列名的命名规则数据库变量名命名规则数据库命名规则不允许出现MySQL数据库名称命名规则关于数据库命名规则下列哪些说法符合索引的命名规则
扫码二维码