数据库字段名和数据库关键字冲突

 

没有什么技术可言,自己为难自己的‘bug’!


之前设计了一个数据库,其中某表中包含字段‘desc’(当时想的是description的简写)。

 

没想到在后来的java代码中始终无法为该表添加记录或者是更新记录,由于其它表使用该java代码是没有问题的,自己就懵了无法理解。。。

 

今天晚上做了一个尝试,就是一个一个字段的添加,最后发现只要添加的字段里包含了‘desc’就会报错,然后仔细一想desc是数据库逆序的关键字,改成‘description’OK了。


基础不扎实,从网上找了mysql的关键字,下次设计数据库的时候就不会忘了!

 

以下转自http://zhaozhi-1983.iteye.com/blog/159044

 

 

 

ADDALLALTER
ANALYZEANDAS
ASCASENSITIVEBEFORE
BETWEENBIGINTBINARY
BLOBBOTHBY
CALLCASCADECASE
CHANGECHARCHARACTER
CHECKCOLLATECOLUMN
CONDITIONCONNECTIONCONSTRAINT
CONTINUECONVERTCREATE
CROSSCURRENT_DATECURRENT_TIME
CURRENT_TIMESTAMPCURRENT_USERCURSOR
DATABASEDATABASESDAY_HOUR
DAY_MICROSECONDDAY_MINUTEDAY_SECOND
DECDECIMALDECLARE
DEFAULTDELAYEDDELETE
DESCDESCRIBEDETERMINISTIC
DISTINCTDISTINCTROWDIV
DOUBLEDROPDUAL
EACHELSEELSEIF
ENCLOSEDESCAPEDEXISTS
EXITEXPLAINFALSE
FETCHFLOATFLOAT4
FLOAT8FORFORCE
FOREIGNFROMFULLTEXT
GOTOGRANTGROUP
HAVINGHIGH_PRIORITYHOUR_MICROSECOND
HOUR_MINUTEHOUR_SECONDIF
IGNOREININDEX
INFILEINNERINOUT
INSENSITIVEINSERTINT
INT1INT2INT3
INT4INT8INTEGER
INTERVALINTOIS
ITERATEJOINKEY
KEYSKILLLABEL
LEADINGLEAVELEFT
LIKELIMITLINEAR
LINESLOADLOCALTIME
LOCALTIMESTAMPLOCKLONG
LONGBLOBLONGTEXTLOOP
LOW_PRIORITYMATCHMEDIUMBLOB
MEDIUMINTMEDIUMTEXTMIDDLEINT
MINUTE_MICROSECONDMINUTE_SECONDMOD
MODIFIESNATURALNOT
NO_WRITE_TO_BINLOGNULLNUMERIC
ONOPTIMIZEOPTION
OPTIONALLYORORDER
OUTOUTEROUTFILE
PRECISIONPRIMARYPROCEDURE
PURGERAID0RANGE
READREADSREAL
REFERENCESREGEXPRELEASE
RENAMEREPEATREPLACE
REQUIRERESTRICTRETURN
REVOKERIGHTRLIKE
SCHEMASCHEMASSECOND_MICROSECOND
SELECTSENSITIVESEPARATOR
SETSHOWSMALLINT
SPATIALSPECIFICSQL
SQLEXCEPTIONSQLSTATESQLWARNING
SQL_BIG_RESULTSQL_CALC_FOUND_ROWSSQL_SMALL_RESULT
SSLSTARTINGSTRAIGHT_JOIN
TABLETERMINATEDTHEN
TINYBLOBTINYINTTINYTEXT
TOTRAILINGTRIGGER
TRUEUNDOUNION
UNIQUEUNLOCKUNSIGNED
UPDATEUSAGEUSE
USINGUTC_DATEUTC_TIME
UTC_TIMESTAMPVALUESVARBINARY
VARCHARVARCHARACTERVARYING
WHENWHEREWHILE
WITHWRITEX509
XORYEAR_MONTHZEROFILL

 

MySQL允许部分关键字用做未引起来的识别符:

  • ACTION

  • BIT

  • DATE

  • ENUM

  • NO

  • TEXT

  • TIME

  • TIMESTAMP

<think>首先,用户的问题是关于在数据库建表时,如何确定一个字段是否应该设置为唯一关键字。我需要基于系统指令用户可见层的要求来构建回答。 系统级指令: - 所有行内数学表达式用 $...$,但我看用户的问题中没有数学内容,所以可能不需要。 - 独立公式用 $$...$$ 并单独成段,同样,可能不适用。 - LaTeX语法正确:确保任何数学格式正确。 - 使用中文回答。 - 生成相关问题:在回答后添加相关问题。 - 回答中引用的段落末尾添加引用标识,如 [^1]。 用户可见层: - 回答结构清晰,帮助用户逐步解决问题。 - 保证回答真实可靠。 参考站内引用: - 引用[1]:关于使用反引号避免关键字冲突。 - 引用[2]:加双引号或修改参数来区分关键字。 - 引用[3]:MySQL中用反引号解决字段名关键字的问题。 - 引用[4]:JPA中使用注解处理关键字字段。 用户的问题核心是:如何判断字段是否应设为唯一关键字。这里的“唯一关键字”可能指的是唯一约束(UNIQUE constraint)或主键(PRIMARY KEY)。我需要澄清概念。 在数据库中: - **主键(Primary Key)**:唯一标识表中的每一行,不能有NULL值,自动唯一。 - **唯一约束(Unique Constraint)**:确保字段的值唯一,但可以有NULL值(除非指定NOT NULL)。 用户说“唯一关键字”,可能指的是唯一约束或主键。我将覆盖两者。 步骤结构: 1. **理解唯一关键字的概念**:解释什么是唯一约束主键。 2. **判断标准**:列出何时应该设置字段为唯一。 3. **实际考虑因素**:如业务需求、数据完整性等。 4. **如何实现**:简要提及SQL语法,参考引用。 5. **注意事项**:如避免关键字冲突(参考引用)。 生成相关问题:在回答后添加。 使用中文回答。 确保引用:在引用的内容末尾添加标识。参考引用是关于关键字冲突的,但用户的问题是判断是否设置唯一,不是冲突。所以,我需要整合相关信息。 用户的问题:“判断某个字段是否应设为唯一关键字”——这是决策过程,不是语法问题。 构建回答: - 引言:简要介绍。 - 步骤1:定义唯一关键字(唯一约束)。 - 步骤2:判断标准(业务逻辑、数据唯一性等)。 - 步骤3:实际例子。 - 步骤4:实现时注意事项(如字段名关键字时处理)。 - 结论。 - 相关问题。 参考引用: - 引用[1]:关于SQL关键字冲突,使用反引号。 - 引用[2]:加双引号或修改参数。 - 引用[3]:MySQL反引号解决。 - 引用[4]:JPA注解处理。 在回答中,当谈到实现唯一约束时,可以提到如果字段名关键字,需要用反引号或双引号,并引用[^1], [^2], [^3], [^4]。 核心是判断是否设置唯一,不是如何写SQL。 最终回答结构: 1. 解释唯一关键字。 2. 判断因素。 3. 如何设置(简要)。 4. 注意事项(包括关键字冲突)。 5. 总结。 6. 相关问题。</think>### 数据库建表时如何确定字段是否应设置为唯一关键字数据库设计中,设置字段为“唯一关键字”(通常指唯一约束或主键)是确保数据完整性查询效率的关键步骤。唯一约束(UNIQUE Constraint)要求字段值在表中必须唯一(但允许 NULL 值),而主键(PRIMARY KEY)是特殊的唯一约束,且不能为 NULL。以下我将基于业务逻辑、数据特性实际需求,逐步解释判断标准。回答结合了数据库最佳实践,并参考相关引用以避免常见错误。 #### 步骤1: 理解唯一关键字的作用类型 在判断前,需明确唯一关键字的核心目的: - **唯一约束**:保证字段值不重复(例如,用户邮箱或身份证号),常用于非主键字段。如果字段值必须全局唯一,但允许部分行为空,则适合此约束。 - **主键**:作为表的唯一标识符(例如,订单ID或用户ID),要求非空且唯一,通常用于快速检索关联其他表。 关键区别:主键是隐式唯一的,而唯一约束是显式添加的选项;选择取决于字段是否承担“标识行”的角色[^1]。 #### 步骤2: 判断字段是否应设置为唯一关键字的因素 基于业务需求数据特性,通过以下标准决策: 1. **业务唯一性要求**: - 如果字段值在业务逻辑中必须唯一(如用户名、手机号、产品序列号),则需设置唯一约束。例如: - 在用户表中,`username` 字段应设为唯一,避免重复注册。 - 在订单表中,`order_number` 字段应设为主键或唯一约束,确保每个订单号唯一。 - **判断方法**:与业务分析师确认该字段是否代表“实体标识”。如果多个记录共享相同值会导致错误(如重复支付),则必须设置唯一。 2. **数据分布稳定性**: - 字段值是否天然唯一且稳定?例如: - 自增ID(如`id INT AUTO_INCREMENT`)适合主键,因为值由系统生成且不重复。 - 可变字段(如`email`)可能需唯一约束,但需评估是否可能变更(如用户修改邮箱)。 - **避免过度使用**:如果字段值重复率高(如性别字段),设置唯一会浪费资源;反之,高基数字段(如哈希值)更适合唯一约束。 3. **数据完整性外键关联**: - 如果字段被其他表引用为外键,必须设置为主键或唯一约束,以维护引用完整性。 - 例如,在部门表与员工表中,`department_id` 在部门表中应为主键,确保员工表的外键关联有效。 4. **性能影响**: - 唯一约束自动创建索引,加速查询(如`WHERE`条件或`JOIN`操作),但会增加插入/更新时的检查开销。 - **测试建议**:在开发环境模拟数据负载。如果字段经常用于搜索且数据量大,设置唯一可提升性能;否则,可能拖慢写入速度。 5. **NULL 值处理**: - 唯一约束允许单个 NULL 值(除非结合`NOT NULL`),而主键禁止 NULL。如果字段可能为空但需唯一(如可选的自定义编码),则选择唯一约束而非主键。 #### 步骤3: 实际示例实现注意事项 - **示例场景**: 假设创建用户表,需判断`email`字段是否唯一。 - 业务需求:每个邮箱只能注册一个账号 → 应设唯一约束。 - SQL 实现示例(MySQL): ```sql CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, -- 主键,自动唯一 username VARCHAR(50) UNIQUE, -- 唯一约束 email VARCHAR(100) UNIQUE, -- 唯一约束 phone VARCHAR(20) -- 普通字段,无需唯一 ); ``` 这里,`username``email`设为唯一,因业务要求唯一性;`phone`未设置,因允许重复(如家庭共享号码)。 - **注意事项(避免关键字冲突)**: 如果字段名数据库关键字(如`order`或`group`),在设置唯一约束时,需用反引号(MySQL)或双引号(PostgreSQL)转义,否则会导致语法错误。参考引用示例: - MySQL:使用反引号,如 `` `order` VARCHAR(20) UNIQUE ``,确保字段被正确识别[^1][^3]。 - PostgreSQL:加双引号或修改参数,如 `"order" VARCHAR(20) UNIQUE`[^2]。 - JPA 等ORM工具:用注解处理,如 `@Column(name = "[order]")` 来定义唯一字段[^4]。 #### 步骤4: 决策流程图 为简化判断,使用以下逻辑: ```mermaid graph TD A[字段是否在业务中必须唯一?] -- 是 --> B[是否作为行标识?] A -- 否 --> C[无需设置唯一] B -- 是 --> D[设为主键] B -- 否 --> E[设为唯一约束] D --> F[检查字段名是否关键字?是则转义] E --> F F --> G[测试数据完整性] ``` #### 总结 判断字段是否应设为唯一关键字,核心是业务需求数据特性:优先考虑值唯一性、关联需求及性能。设置后,能提升数据质量,但需注意语法细节(如关键字转义)。实践中,建议在数据库设计阶段与团队评审,避免遗漏。例如,如果字段名是SQL关键字,务必使用转义符,参考引用[^1][^2][^3][^4]的解决方案。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值