2011-12-10 5 views
1

Comment stocker des tableaux dans une base de données?stocker des tableaux dans la base de données

Ce que je fais est la suivante:

// $ data est un tableau

$v = base64_encode(json_encode($data)); 

$todo = 'INSERT INTO table (data) VALUES("' . $v . '")'; 
$sql = mysql_query($todo); 

Aussi pourquoi dois-je appeler base64_encode avant stocker le tableau dans la base de données?

+0

Qui a dit que vous deviez utiliser 'base64_encode' pour le stocker dans la base de données? Qu'y a-t-il de mal à faire un 'json_encode', ou même' serialize'? –

+0

Généralement, il n'est pas bon de stocker un tableau dans une base de données. De quoi vous occupez-vous? – ajreal

Répondre

2

Ce que vous faites est peut-être erroné. Il y a beaucoup de décisions que vous avez prises qui ne sont absolument pas nécessaires, et elles peuvent aussi ne pas être appropriées. D'une part, stocker des tableaux "gelés" dans la base de données est généralement une mauvaise idée car vous ne pouvez rien faire d'autre que de les récupérer (vous ne pouvez pas les modifier ou les interroger en fonction de leur contenu). Les solutions qui "corrigent" ce problème sont orientées base de données et incluent la modification de votre schéma de table. Je ne sais pas ce que vous essayez de faire, donc je ne vais pas aller plus en détail.

Ensuite, si vous ne voulez sérialisation des tableaux dans votre base de données (il y a des cas d'utilisation légitime) (modifier:et seulement l'intention d'y accéder par le biais du code PHP - comme cela a été très correctement signalé), la seule chose que vous devez utiliser est la fonction serialize - pas json_encode ou toute autre chose. C'est la raison même de cette fonction. Lorsque vous récupérez les valeurs de la base de données, utilisez deserialize pour récupérer le tableau.

Enfin, lors de l'injection d'une variable dans une requête SQL, vous devez lui échapper avec mysql_real_escape_string (ce que vous ne faites pas).

Il serait beaucoup mieux à faire:

$sql = sprintf('INSERT INTO table (data) VALUES(\'%s\')', 
       mysql_real_escape_string(serialize($data))); 
$result = mysql_query($sql); 
+0

Ce n'est pas nécessairement faux, c'est très bien si vous ne voulez pas récupérer/rechercher des valeurs individuelles dans le tableau. –

+1

@yi_H: Je dis "habituellement" et "il y a des cas d'utilisation légitimes". – Jon

+0

Je ne suis pas sûr d'être d'accord avec ça. Sans connaître le but derrière ce qu'il fait, dire que c'est beaucoup mieux peut ne pas être exact. Peut-être que ce qui est vraiment nécessaire est un 'split()' du tableau, et le stockage des éléments de données dans les lignes. –

0

Naturellement, vous ne stocke pas des tableaux dans une base de données relationnelle. Obtenir un base64 à partir de votre tableau semble être une astuce pour que vous puissiez stocker une chaîne dans la base de données.

+0

Il existe des raisons légitimes de stocker des tableaux dans une base de données. Pas beaucoup, mais ils existent. –

+0

@George Cummins Je n'ai pas dit qu'il y avait des raisons contre cela. Cependant, les bases de données ne prennent généralement pas directement en charge les types de champs de tableau. –

+0

En effet, les tables * sont des * tableaux de données (lignes), ce qui tend à obtenir un peu de "méta" lors de l'interrogation. Cependant, si les données doivent simplement être stockées et ne sont pas demandées, c'est un cas d'utilisation légitime. –

1

Vous n'avez pas besoin d'appeler base64_encode(). json_encode() sera déjà une chaîne ... bien sûr, vous êtes limité aux valeurs codées UTF-8 dans $data.

Ceci est un moyen légitime de stocker un tableau, bien que vous puissiez considérer une table comme un tableau et stocker une valeur par ligne. De plus, vous pouvez stocker vos données sous forme de chaîne XML, ou même CSV/TSV si le contenu de vos données n'a pas interféré avec les délimiteurs.

En fin de compte, cela dépend vraiment de la situation dans laquelle vous vous trouvez. Du code que vous avez présenté, cela fonctionnera, mais si vous voulez qu'il fonctionne bien/mieux, plus d'informations seront certainement nécessaires.

REMARQUE: Désinfectez vos données avant de les entrer dans la base de données!

Questions connexes