Question

所以我正在建立一个允许用户建立联系人列表的网站。所以他们是用户，用户有列表，列表有联系人。在我看来，我需要3个表，但我只是想确定。

当然会有一个User表，然后是一个“List of Lists”表，其中包含用户名和listname作为主键以及我们想要附加到列表整体的任何其他信息。最后，由于缺少一个更好的单词，List表将再次具有用户名/ listname p.k.，然后是联系人ID和备注，以及用户在该特定列表上附加到该联系人。

我希望这是一个明确的解释。出于某种原因，我对这种安排感到不确定。一方面，如果网站变得流行，List表可能膨胀到数十亿行。每个人的列表信息都在同一个表格中混乱，这也感觉有点奇怪。我想我可以为每个用户创建单独的表，甚至可以为每个列表创建单独的表，但出于其他原因这似乎是一个坏主意。

我的数据库解释假设我可以在我的表上使用外键，目前这些外键实际上不是一个选项。如果我无法启用InnoDB表，我可能会使用ID作为列表，而不是依赖于复合键。也许我应该这样做？

Answer 1

您不希望为每个用户创建一个表。这将是你在未来的最糟糕的噩梦。我会选择这样的东西：

User Table
----------
User_ID - Integer - Indexed
Username - VarChar[8]
First_Name - VarChar[30]
Last_Name - VarChar[40]

List Table
-----------
List_ID - Integer - Indexed
User_ID - Integer - Indexed
List_Name - VarChar[30]

List_Contact Table
--------------
List_ID - Integer - Indexed
Contact_ID - [whatever data type it is in the existing Contact table]

User.User_ID=List.User_ID
List.List_ID=List_Contact.List_ID
List_Contact.Contact_ID=Contact.Contact_ID [Linking to the existing Contact table]

如果您构建了一些记录集的缓存，即使数据库中有大量记录，也不会有太多的性能问题。毕竟，所有用户都不会立即进入系统。

修改：更改设计以适应现有的联系人表格。

Answer 2

Users(id, username, first_name, last_name)
FriendLists(id, user_id, name)
ListItems(id, list_id, user_id)

您的用户表应包含有关您用户的所有基本数据。这里没什么特别的。

然后你有一个朋友列表，其中包含一个id，一个user_id（列表所有者），以及列表的名称（“最好的朋友”，“家人”，“我讨厌的人”）。

然后你有你的列表项，它们再次有一个id（一切都应该有一个id，它只是让它更容易引用），一个列表id（这是朋友列表的外键，它反过来给出了你的所有者），然后是user_id，这是朋友。

所以，如果鲍勃是莎莉和乔的最好的朋友，那么你会有

Users: (0, bob, Bob, Bobberson), (1, sally, Sally, Sallerson), (2, joe, Joe, Joeman)
FriendLists: (0, 0 (bob), "Best Friends")
ListItems (0, 0 (best friends list), 1 (sally)), (0, 0, 2 (joe))

Answer 3

这是一种做法。您还可以让用户添加联系人，然后将标签添加到他们的联系人。

这是我的建议：

用户
ID
其他字段

与
ID
fk = User.id
标签
笔记
其他字段

你绝对不想为每个用户开始创建新表，那么你将拥有数千/数百万个表，我不认为任何数据库的设计都是这样使用的。我建议你找一个更了解你团队数据库设计的人。

这是组织我的数据库表的正确方法吗？

3 个答案: