Question

我有一个项目表，在确定的时间段内有一个机架，恰好是一周，我需要制作请求周的排名表，例如：

Items
-----
id 
name

和

Item_in_rank
------------
item_id -> Items.id
year
week
rank

如果我这样做：

SELECT
    r.rank,
    i.*
FROM
    Item_in_rank AS r 
INNER JOIN
    Items AS i
       ON r.item_id = i.id
WHERE
    week = 4 AND year = 1986
ORDER BY
    r.rank ASC

我获得了排名：

rank id  name
1-    4  jhon
2-   76  jorge
3-   21  myriam
4-   92  bety

我可以在不同的周/年内拥有一件物品，但我得到一份清单。我在这个模型中不需要pk，但是，这是正确的吗？

如果我定义为pk（周，年），我不能拥有：

week year item rank
  1  1980   41    1
  1  1980   32    2
etc..

如果我定义为pk（周，年，项）我需要为（周，年）创建一个索引，而pk将毫无用处。

这是正确的吗？或者我错了？

Answer 1

你总是需要一个PK，特别是当你认为不需要时。 PK的目的是确保您可以随时唯一地识别记录。这不是数据库正确执行的可选项（当您没有PK时尝试删除重复项，如果没有PK，则有100％的可能性存在重复项）并不代表您可能不需要其他指数也是如此。

Answer 2

如果我定义为pk（周，年，项目）i 需要为其创建索引（周，年），而pk将是无用的。

向索引添加列会使索引变大（坏事），但不会降低它的实用性。 MySQL可以使用(col1, col2)上的索引来搜索col1。因此，请务必将主键更改为(week, year, item)。

作为不起作用的索引的示例：如果您的主键是(col1, col2)，则MySQL无法使用它来搜索col2。这就像使用在lastname, firstname上排序的电话簿来搜索名字一样。

这是正确的吗？或者我错了？

你错了！：）

Answer 3

在许多数据库中（我不确定mysql）PK更像是对表的约束。换句话说，该表是PK。数据以PK顺序存储，但由于PK而不会显着增大。

尝试添加PK并查看数据存储大小是否增加。添加辅助索引（可能首先需要PK）以帮助您的查询正常执行。

不要过于担心创造无用的PK。自己测试，看看是否值得创建。

表没有PK

3 个答案: