Stockage optimal des données - triple magasin/relationnel db/autre?

Question

Je construis une application web avec PHP sur un serveur Apache.

L'application contient beaucoup de données facultatives sur les personnes. Selon la catégorie de la personne (une personne peut être dans les catégories mai), ils peuvent choisir de spécifier ou non des données: adresse du domicile (== 5 champs pour la rue, la ville, le pays, ...), adresse professionnelle (encore 5 champs), âge, numéro de téléphone, .... L'application stocke aussi des données supplémentaires, bien sûr (créé, dernière mise à jour, nom d'utilisateur, mot de passe, userlevel, ...).

La version actuelle/obsolète de l'application dispose de 86 champs dans la table "users", et est (selon la catégorie de la personne), étendu avec un tableau supplémentaire avec 23 autres champs (relation 1-1).

Tout cela est stocké dans une base de données Postgresql. Je me demande si c'est la meilleure façon de gérer ce type de données. La plupart des enregistrements ont (beaucoup) de champs vides, ce qui augmente la taille de la base de données et ralentit les requêtes. Cela vaut-il la peine de se pencher sur une autre solution comme un Triple Store, ou est-ce que je m'inquiète trop à ce sujet et devrais-je simplement garder la configuration actuelle? Cela semble bizarre et il est difficile de simplement ajouter des champs à une table pour chaque nouveau but du site. D'un autre côté, j'ai l'impression que les magasins triples ne sont pas encore si communs. Des pointeurs, ou des suggestions comment aborder cela? J'ai lu "Programmation du web sémantique" par Toby Segaran et d'autres, mais à partir de ce livre, j'ai l'impression que le principal avantage des magasins triple et RDF est l'échange d'informations sur le web (ce qui n'est pas le cas). objectif de mon application)

Answer 1

la plupart des dossiers ont (beaucoup) champs vides

Cela implique que vos données sont loin d'être normalisée. La version actuelle/obsolète de l'application a 86 champs dans la table "users", et est (selon la catégorie de la personne), étendue avec un tableau supplémentaire avec 23 autres champs (relation 1-1)). En fait, oui, c'est très loin d'être normalized.

Si vous avez une bonne raison de vous éloigner de ce que vous venez de faire maintenant, la première étape consisterait à mieux structurer vos données. Même si vous choisissez de passer à un autre type de SGBD par ex. noSQL ou objet db. Cela permet non seulement d'économiser de l'espace dans votre SGBD, mais aussi de récupérer les données plus rapidement et de réduire la quantité de code à écrire (par exemple, vous pouvez réutiliser le même code pour conserver une adresse de domicile si vous avez une seule table pour 'adresse' avec un champ signalant le type d'adresse).

Il y a beaucoup de ressources sur le web (en plus du lien wikipedia ci-dessus) décrivant comment appliquer les règles de normalisation (il commence à être un peu impliqué après 1,2 et 3 - mais si vous pouvez maîtriser ces vous êtes bien équipé pour assumer la plupart des tâches).