只有一个索引的数据库表…坏主意?

这将是非常有限的。在我处理过的表中,我见过多达11个索引,它们都有一个目的。毫无疑问,有更多的案例。

至少在数据库中,主键和所有外键都将被(或应该)索引。

索引跨越多个列也是常见的。

非关系数据库(目前所有流行的 NoSQL 运动)接近这种情况。许多这样的数据库都是玩具以外的东西,它们被广泛地用作可扩展性极高的生产系统的基础——缺少免费索引和其他限制,使其具有几乎难以置信的可扩展性,特别是对于“大部分是读取”的场景。缺点基本上是必须放弃规范化,以严格依赖于什么查询需要什么程度的优化的方式在各处复制信息。

我不确定您的“单索引”方案是基于什么,但除非它提供了与最佳“NoSQL”存储系统相同的优势(并且您愿意为此付出全部代价),否则它似乎不太可能是一个技术上可行的概念;-。

这要看情况而定。例如,伯克利数据库只有一个密钥,对于其用途非常有用。

另一方面,关系数据库应该让您有机会定义尽可能多的索引(如Cletus所提到的,否则,外键查询的性能会非常差)。

一般:索引是为了加快数据库的查找:就像在书中一样,你搜索“计算机”这个词,你浏览(按字母顺序!)索引并查找所有页码。

如果(非常假设的推理)创建了一个不使用索引而优化查找时间的数据库:那么这样一个只包含一个索引的数据库并不是一个坏主意。

但是如果你说的是主流数据库,那么我会说:取决于内容。

这取决于您将如何处理数据。

如果基于未索引字段搜索和选择,则过程将变慢。同样,如果您基于一个未索引的字段执行联接或合并操作,您会得到一个减速。

如果表中有数百万行,则速度可能太慢,无法接受。

在某些情况下,仅通过一个字段限制自己的访问权限可能太有限。

同样,这取决于您将如何处理这些数据。