2013-06-09 2 views
0

Bon, voici une table d'utilisateurs standard;Stockage - Logique/Performance - PHP/MySQL

Nom au complet | Anniversaire | E-Mail | Nom d'utilisateur | Mot de passe | Facebook | MySpace | Twitter | LinkedIn

Rien d'inhabituel à ce sujet, c'est assez standard et livre de texte. Cependant, au lieu de plusieurs colonnes de réseaux sociaux pour chaque réseau, il pourrait être stocké comme tel;

Nom au complet | Anniversaire | E-Mail | Nom d'utilisateur | Mot de passe | La

La différence étant l'information serait stockée dans la colonne sociale comme un tableau implosé plutôt que dans des colonnes séparées. C'est tout à fait sensé, donc s'il y a des milliers d'utilisateurs, il serait sûrement plus rapide de traiter via un script et moins touché sur la base de données.

Quelqu'un peut-il penser à des désavantages de l'utilisation de la méthode suggérée au lieu de la méthode du livre de texte?

+2

pas mal, créez une table séparée 'social_affiliations' –

Répondre

0

Les deux inconvénients que je peux penser:

  1. Il sera plus difficile d'interroger pour plus de détails sociaux spécifiques à un utilisateur. Si vous saviez que leur nom d'utilisateur Facebook était fbuser123, vous devrez peut-être demander quelque chose comme SELECT * FROM users WHERE social LIKE '%fbuser123%'.
  2. Il sera légèrement plus difficile d'utiliser l'information une fois qu'elle a été sélectionnée dans la base de données, par exemple: Exiger que le champ soit json_decode avant de pouvoir être utilisé.

À part ça, je ne peux penser à rien d'autre.

J'imagine que si vous avez fait cela, le moyen le plus efficace de stocker les données serait au format texte et json_encode les données.