--注：此文为意译
在你开始思考数据库的Schema或Table之前，你需要先想一想数据本身。数据的类型，取值的范围。
数据库设计的第一步就是数据，但很多程序员没在设计数据上花任何时间，而是先去设计schema。SQL善于操纵解结构化的数据而不是像文本或图片这样的非结构化的数据。RDBMS的一个基本概念是Codd博士所说的信息原则（Information Principle）。这条规则陈述了所有在RDBMS中的数据都被建模为储存在列、行、表里的标量值。这意味着在一个表里的所有行只有一个结构。同样，每一列只有一种数据类型，而且数值范围也是确定不变的。
选择数据类型和数值范围很重要，其关系到该字段如何去其他数据进行计算和比较。这也解释了为什么SQL是一种强类型语言。
使用弱类型语言的人们通常会给数据元素名称加上前缀或后缀，来标识原数据类型。这违反了ISO-11179元数据规则。这一标准提出应根据数据是什么来命名，而不应根据其在一张表中的位置或其如何被使用来命名。
ISO-11179推荐的数据元素命名格式为：[<role>_]<attribute>_<property>（我在下文中把attribute翻译成描述，把property翻译成属性）。一个数据元素在整个schema有且只有一个名字。如果名字在整个企业的系统中有且只有一个那更好。最好名字是在整个宇宙中有且只有一个。
举例来说，“id”显得太模糊和笼统了。它是一个没有描述的属性。一个比较好的名字是"vehicle_id"。最好的名字是"vin"，这一名字在ISO 4030中被定义表示“Vehicle Identification Number”，并被广泛使用。VIN这一名字精确而且容易被理解。
同样，你将看到很多只有描述没有属性的例子。如“sex”，其可以被理解为“sex_code”（在ISO 5218中被定义，其可被表示“性”标识），或“sex_type”（对动物和植物的生物学的选项）等。
可能最愚蠢的错误是使用属性的堆叠作为列名，譬如：“type_code_id”。如果“type_code_id”表示一个标识符（identifier），则它是唯一的而且其在数据模型中属于一个实体（大家可以想想“emp_id”）。如果是用来表示一个代码（code），则其应该有一个外部的权威（大家可以想想“postal code”）。如果是用来表示一个类型（type），则其应该有相应的测试（大家可以想想“blood type”）。属性堆叠就像有一大串形容词，但却没有修饰的名词。
再次需要重申的是定义列名的基本规则是告诉我们“它是什么”。而不是告诉我们
1. 它在哪个表中（不要用表名作为命名的一部分）
2. 它在某个特殊的表中是如何被使用的（例如：不要用pk，fk或vw作为列名的前缀）
3. 它的数据类型（例如：不要用i，str等作为列名的前缀）
4. 不要告诉我们这个数据元素不是什么（要用肯定陈述）
列名中的属性成份应从一个标准列表中选择。这个列表应该成为你的一个字典，并强制使用。
当相同的数据元素在同一个表中充当多个角色时，我们可以加上<role>部分。例如：Organization表中可能会有“supervisor_emp_id”和“subordinate_emp_id”，同时引用Personnel表中的“emp_id”。
查看列名的长度。列名太长或太短都会有坏处。一个太短的名字，除非是标准缩写，否则难于理解，或产生歧义。例如：“std”可能被理解为student或standard。
避免在名字中出现特殊字符。使用Latin-1字母，数字和下划线。避免引用标识符，如Microsoft支持的方括号或ANSI/ISO中的双引号。使用这些引用标识符的唯一理由是为了显示，这对于数据库本身不会带来好处。
强制使用大写的规则来避免大小写敏感问题。