数据库新手常犯的5个错误 (数据库初学)

技术教程 2025-05-05 07:53:42 浏览次

刚做开发人员的时候，需要掌握的东西非常多。首先是编程语言本身，还有所有你用到的框架的的特定用法，之后(也可能是之前)，前端开发的东西也会混进来，在开发过程中你还要考虑数据存在哪的问题。

起初，由于你有太多东西需要迅速掌握，在应用设计的过程中，会倾向于把数据库放在后面考虑(大概因为它对用户的使用体验没什么影响)。结果就是在处理数据库的时候，会发现很多不好的实践。这里举几个例子。

1. Storing images 储存图片

数据库里不应该放图片。你可以做的事情并不代表你就应该去做。图片会占用数据库里相当大的空间，吃掉不必要的 IO 资源从而拖慢应用。这个错误最常出现的情况，就是新人将图片用 base64 编码，然后将其储存在很大的 text/blob 字段当中。

更好的办法是直接将图片上传至像 Amazon S3 这样的云服务上，然后用数据库里用 text 字段储存图片的 URL。每次要加载一张图片的时候，只要把图片的 URL 输出到有效的标签里就可以了。这会极大地提升网页的响应速度，对大规模 Web 应用非常有帮助。

2. Limit/Offset

分页在很多应用中都非常常见。从你开始学习 SQL，(你就该知道)最直接的分页方法就是先用 ORDER BY 对数据库的一些列进行排序，然后 LIMIT 返回的结果数，对除***页外的每一页使用 OFFSET。这看起来很符合逻辑，直到你处理中等规模应用时才意识到：

不幸的是：分页非常复杂，目前还没有一个万全之策。

3. 用整数做 primary key

在创建 primary key 的时候，几乎所有的 ORM(Object Relational MAPPing 对象关系映射)的默认做法都是创建一个串行字段，它是按顺序自动生成的，然后你就可以用它(这些自动生成的数字)作为你的 primary key。在管理员看来，这是非常直观的，因为可以由用户 1 到用户 2 这样依次查看。对大多数的应用来说，这种做法通常是不错的。但是随着这些整数 primary key 不断变大，你很快就会意识到处理他们会让人筋疲力尽。对于大规模系统，这是很不理想的处理方法。此外，你还会依赖生成这些 key 的那个系统，在你必须要扩大规模的时候，会非常痛苦。更好的解决办法是从一开始就利用好 UUID (Universally Unique Identifier 通用唯一识别码)的优势。

(UUID)还有其它的好处，那就是它不会无形中暴露给用户(数据库中)有多少用户、列表、或是这些 key 所指代的任何东西。

4. 新列中的默认值

无论你做这个工作有多久，都不会一次就创建出一个***的 schema。***是将数据库 schema 视为一个持续演化的文档。不幸的是：向数据库中添加一列是件很容易的事，这也就意味着在添加列的时候把工作搞砸同样很容易。默认情况下，如果你新添加了一列，通常是允许有 NULL 值的。这个操作速度很快，但大多数应用实际上不太想让他们的数据里有 null 值，他们会想要设置默认值。

如果你在表里添加设置了默认值的新列，会对这张表触发一次完全的重写。注意：这对应用中的任何(数据量)很大的表都非常不利。(正确的方法)恰恰相反，***是先允许 null 值存在，这样操作就是即时的，接下来再设置默认值，再用后台进程去回溯更新数据。

实际操作比我所说的要更复杂，幸好已经有一些便利的指南可以为我们提供帮助。

5. 过度标准化

开始学习数据库的标准化的时候，(标准化)感觉就像是很正确的事。你创建了一个 posts 的表，里面包含 authors，每篇文章(post)都属于一个条目(category)，所以你又创建了一个 categories 的表，然后再创建一个把它们俩 join 在一起的表，post_categories。从根本上来说，这样做标准化也没什么原则上的错误，但是某种程度上，标准化的收益正在递减。

在上述实例中，categories 可以简单地作为 post 里的一个 varchar 字段。标准化是件很有意义的工作，但是每次处理包含多对多关系的表时都要深思熟虑，想想你是不是真的需要在关系的两边都各用一个单独的表。

修正：值得一提的是，欠标准化也是个问题。这里并不存在“一刀切”的解决方案。有时完全不做标准化和完全标准化也行得通。像 @fuzzychef 说的那样：“适度标准化，即金发姑娘原则(The Goldilocks principle，意为适度的是***的)”。

总结

在 Twitter 上问到这个问题的时候，我得到了很多非常棒的回应，但是这些回应五花八门。从“从不查看 ORM 生成的查询”这样的基本问题，到像事务隔离这样的进阶话题。有一点我并没提到，但是对于所有构建 app 的人来说都非常值得注意的一点就是索引。了解索引的工作原理，知道你需要创建什么样的索引，是获得良好的数据库性能的关键。除了用 Postgres 分析性能的实践步骤以外，还有很多关于索引的基础知识的文章。

通常我会鼓励大家把数据库当做你工具箱中的另一个工具，而不是什么非学不可的恶魔。但我希望，以上的提示可以帮助初学者避免一些基本错误。

Access与 Excel区别

一、对象不同Excel只有一种对象——Sheet。 Acesss（2003）有七种对象：表、查询、窗体、报表、宏、模块和数据页。 Excel一个工作簿中可以有多个工作表，工作表之间基本是相互独立，没有关联性或者有很弱的关联性。 Access在各种对象之间不是独立的，是存在着关联性。一种对象的多个子对象，例如各个表之间、查询之间、窗体之间、报表之间也存在关联性。这种关联性造就了Access强大处理能力。二、使用方式不同Access在处理大量数据上是比Excel具有更强的能力。但是使用Access完成数据处理的任务，在实现起来要比Excel复杂很多。这种复杂性的回报就是更强的能力。 Access是一种规范的，各个对象之间存在严格的关联。这个规范性和关联性都是Access强大数据处理功能的基础。因此在设计表过程中，必须遵守这种规范性。可以把Access处理数据的方式比作一个大公司的管理。 Excel是一种自由的，表之间的关联性任意的。可以把Excel处理数据的方式比作一个小公司的管理。一个小公司的管理模式是不能直接套用到大公司的管理上。所以Excel表必须按照规范模式改造，才能在Access中使用并完成预想的任务。三、Access表和Excel表从外观上看Access与Excel表似乎相同，实际上两者有很大的。 1.主题：对于一个主题Access只有一个表，而Excel可以有多个表。例如工资表，在很多财务人员使用Excel是月创建工资表，例如1月工资、2月工资，…。而Access则所有的工资部分月份都放在一个表。 2.多表关系：Access表各个表间存在严格的关联。 Excel表各个表间的关系随意。 3.数据计算：Excel表中单元格中可以存储数据，也可以存储公式，可以进行计算。 Access表只能存储数据，不能存储公式，没有计算功能。 Excel这种计算能力，使得Excel具有灵活的强大的计算能力（但计算能力受到数据量大小的限制）。 Access计算功能是由查询和程序来完成的。 Access的特点正好发挥计算能力的强大作用。 4.数据容量：Excel表处理数据的容量有限，数据量大时速度较慢；Access表可以存储2GB数据。 5.索引：Access表有索引，Excel表没有索引。这种索引使得Access在查找筛选数据时，具有Excel不可比拟的速度。 6.数据类型：Access表设计时首先定义数据类型，Eexcel表没有这样的要求。 7.数据格式：Excel表中每个单元格都可以定义自己的格式。 Access表每一列的数据格式一致。数据格式显示特性由窗体和报表实现。 8.其他差异：数据筛选、排序等方面在实现起来有很大的差别。

请高手帮忙解决我的数据库原理与技术这个问题谢谢

这个太好做了。不过要打很多字。这里我教你方法，每个实体建立一个关系，然后多对多联系建立关系，一对一和一对多都建议你合并到实体所在的关系中。你这个设计中，每个实体关系的主键通常就是编号，关系的主键可以自己别建，也可以是联系两边的实体的主键，至于外键等你把关系和主键建好后就自然出来了！！因为这个设计不复杂