只有一个索引的数据库表...这是一个坏主意吗？
如果一种编程语言允许创建数据库表，但只允许一个字段用作索引……那会有多大限制？我不是一个真正的数据库程序员，所以我想知道这样的系统是否可以用作严肃数据库的基础，或者只是一个玩具。
If a programming language allowed the creation of database tables, but only allowed one field to be used as an index ... how limiting would that be? I am not a real database programmer, so I'm wondering if such a system could be used as the basis for serious databases, or would be only a toy.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这将是极其有限的。我在我处理过的表上看到了多达 11 个索引，它们都有一个目的。毫无疑问，还有更多的案例。
数据库中至少主键和所有外键将被（或应该）索引。
索引跨越多个列也很常见。
That would be extremely limiting. I've seen as many as 11 indexes on tables I've dealt with, all of them having a purpose. No doubt there are cases out there with substantially more.
At a minimum in a database the primary key and all foreign keys will be (or should be) indexed.
Also it's common for indexes to span multiple columns.
非关系数据库（目前随着 NoSQL 运动而风靡一时）近似于这种情况。许多这样的数据库绝非玩具，并且被广泛用作可大规模扩展的生产系统的基础——缺乏免费索引和其他限制赋予了几乎令人难以置信的可扩展性，特别是对于“大多数读取”场景。缺点基本上是必须放弃规范化，并以严格依赖于哪些查询需要何种程度的优化的方式到处复制信息。
我不确定你的“单一索引”场景是基于什么，但除非它提供与最好的“nosql”存储系统相同的优势（并且你愿意为此付出全部代价），否则似乎不太可能是一个技术上可行的概念；-)。
Non-relational databases (currently all the rage with the NoSQL movement) approximate such a situation. Many such databases are anything but toys, and are intensely used as the basis of hugely scalable production systems -- the lack of free indexing and other limitations empower almost unbelievable scalability, especially for "mostly-read" scenarios. The downside is basically in having to give up normalization, and duplicating information all over the place in ways that are strictly dependent on what queries need what degree of optimization.
I'm not sure what your "single index" scenario is based on, but unless it offers the same kinds of advantages as the best "nosql" storage systems (and you're willing to fully pay the price for that), it seems unlikely to be a technically viable concept;-).
这取决于。 Berkeley DB 例如只有一个密钥，并且对于其目的非常有用。
另一方面，关系数据库应该让您有机会定义任意数量的索引（正如 cletus 提到的，否则外键查询的性能将非常差）
It depends. Berkeley DB e.g. only has a single key and is very useful for its purposes.
A relational DB on the other hand should give you the opportunity to define as many indices as you like (as cletus mentioned, foreign key queries would suffer from very poor performance otherwise)
一般来说：索引用于加速数据库查找：就像在书中一样，您搜索“计算机”一词，浏览（按字母顺序！）索引，并找到所有页码。
如果（非常假设的推理）创建一个在不使用索引的情况下优化查找时间的数据库：那么这样一个仅包含一个索引的数据库并不是一个坏主意。
但如果你谈论的是主流数据库，那么我会说：取决于内容。
Generally: an index is for speeding up database lookup: like in a book, you search the word "computer", you browse the (alphabetical!) index, and find all page-numbers.
If (very hypothetical reasoning) one creates a database which optimized lookup times without using indices: then such a database containing only one index is not a bad idea.
But if you're talking about a mainstream DB, then I'd say: depends on the content.
这取决于您要如何处理数据。
如果您根据未索引的字段进行搜索和选择，则过程会很慢。同样，如果您基于未索引的字段执行联接或合并操作，速度也会变慢。
如果表有数百万行，这可能会太慢而无法接受。
在某些情况下，将自己限制为仅通过一个字段进行访问可能会过于受限。
同样，这取决于您要如何处理数据。
It depends on what you are going to do with the data.
If you search and select based on an unindexed field, the process is going to be slow. Likewise, if you perform join or merge operations based on an unindexed field, you get a slow down.
If the table has millions of rows, this could be too slow to be acceptable.
Limiting yourself to access by way of just one field can in certain situations be too limiting.
Again, it depends on what you are going to do with the data.