Est-ce la bonne façon d'organiser mes tables de base de données?

Question

Je fabrique donc un site Web qui permet aux utilisateurs de créer des listes de contacts. Donc, ils sont des utilisateurs, les utilisateurs ont des listes, et les listes ont des contacts. Il me semble que j'ai besoin de 3 tables pour ça mais je veux juste m'en assurer.

Il y aurait bien sûr une table User, puis une table "List of Lists" contenant le nom d'utilisateur, et listname, comme clé primaire avec toutes les autres informations que nous voulons joindre à l'ensemble des listes. Enfin, faute d'un meilleur mot, la table List qui aurait à nouveau le nom d'utilisateur/nom de la liste p.k., puis l'ID du contact et les notes et tel que l'utilisateur attache à ce contact sur cette liste spécifique.

J'espère que c'est une explication claire. Pour une raison quelconque, je ne suis pas sûr de cet arrangement. D'une part, si le site devient populaire, la liste peut gonfler en milliards de lignes. Et il se sent aussi un peu bizarre que les infos de la liste de tout le monde soient toutes mélangées dans la même table. Je suppose que je pourrais créer des tables séparées pour chaque utilisateur et même pour chaque liste mais cela semble être une mauvaise idée pour d'autres raisons.

Mon explication db suppose que je peux utiliser des clés étrangères sur mes tables qui actuellement ne sont pas une option. Si je ne peux pas activer les tables InnoDB, j'utiliserai probablement des ID pour les listes au lieu de dépendre d'une clé composée. Peut-être que je devrais le faire de toute façon?

Answer 1

Vous ne souhaitez pas créer de table par utilisateur. Ce sera votre pire cauchemar plus loin sur la route. Je serais allé quelque chose comme ceci:

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] 

Si vous construisez dans une mise en cache des enregistrements, vous n'aurez pas beaucoup d'un problème de performance, même si vous avez des tonnes d'enregistrements dans la base de données. Après tout, tous les utilisateurs ne seront pas sur le système à la fois.

Édition: Modification de la conception pour l'adapter à la table de contacts existante.

Answer 2

C'est une façon de le faire. Vous pouvez également demander aux utilisateurs d'ajouter des contacts, puis d'ajouter des tags à leurs contacts.

Voici ce que je propose:

utilisateur
id
autres champs

Contactez
id =
fk User.id
balises
Note s
autres champs

Vous ne voulez certainement pas pour commencer à créer de nouvelles tables pour chaque utilisateur, alors vous aurez des milliers/millions de tables et je ne pense pas que DB est conçu pour être utilisé comme cette. Je vous recommande de faire appel à quelqu'un qui en sait plus sur le design DB dans votre équipe.

Answer 3

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

Votre table d'utilisateur doit contenir toutes les données de base sur votre utilisateur. Rien de spécial ici.

Ensuite, vous avez une liste d'amis qui se compose d'un id, un user_id (le propriétaire de la liste), et le nom de la liste ("meilleurs amis", "famille", "personnes que je déteste").

Et puis vous avez vos éléments de liste, qui ont encore un ID (tout devrait avoir un ID, il est plus facile à référencer), un ID de liste (qui est une clé étrangère à la liste d'amis, qui à son tour vous donne le propriétaire), puis l'user_id, qui est l'ami.

Donc, si Bob est le meilleur ami avec Sally et Joe, alors vous avez

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))