Version imprimable
Salut,
Quelle solution est la plus rapide et la plus avantageuse entre stoker toutes les données utilisateurs dans un fichier propre à eux (.inc.php), et tout stoker dans plusieurs tables d'une bdd?
Ce qui entraine pour la bdd une éventuelle atteinte à la limite autorisée et beaucoup de requêtes SQL, et pour le fichier texte des fopen() et des traitement de chaines...
Merci
la bdd non ?
C'est quand même très pratique pour les recherches, les séléctions, etc.
Sur ce point oui mais mes données à enregistrées sont "spéciales" et se n'est pas extremement pratique de les ajouter... Le mieux ce serait une table par utilisateur mais ma base serait saturée au bout de 5 membres ^^
Tu est sur qu'il n'y à pas un aute shcéma n'utilisant pas une table par user ?Citation:
Le mieux ce serait une table par utilisateur mais ma base serait saturée au bout de 5 membres ^^
Si tu donnais un tout petit peu plus d'infos on pourrait peut être essayer de te proposer une alternative, car pour moi la bdd c'est bien plus rapide, bien plus optimisé, bien plus pratique que les fichiers texte.
Choisir l'option du fichier texte me parait être une regression.
Enfin, si ce n'est pas extremement pratique à insérer dans la bdd, ne l'est il pas tout autant dans le fichier texte ?
Bonne question je sais pas...
Dans mon cas j'ai une table avec 20 produits et un id de 0 à 19.
Chaque utilisateur possède x produit, mais je n'ai pas trouvé la façon de l'insérer dans la table.
En fait je dois enregistrer en une ligne ces infos. Mais j'ai fais des array serialisés() dans deux colonnes différentes mais je me dis que ce n'est pas propre :?
Genre: Array(0=>produit1) et Array(0=>7)
Salut,
Les données sérializées dans les tables, c'est pas "sale" :)
mais c'est peu pratique pour les recherches et d'autre part
sa consomme du CPU pour sérialiser / deserializer.
J'ai pas bien compris ce que tu dois stoquer exactement pour un
utilisateur ? c'est juste une liste d'id de produits qu'il possede ?
ou c'est plus complèxe ?
A+
Marc
Oue, c'est pas très bdd tout sa :/Citation:
En fait je dois enregistrer en une ligne ces infos
Même question, et si c'est bien cela, pourquoi ne pas faire un tabl iduser/idproduit qui te servirait pour créer ta contrainte multiple.Citation:
J'ai pas bien compris ce que tu dois stoquer exactement pour un
utilisateur ? c'est juste une liste d'id de produits qu'il possede ?
ne pas oublier que si on a inventé les bases de données c'est justement car le stockage sur fichier etais lourd, ne garantissait pas l'atomicité .....
Comme l'a dis ePoX, donne nous plus de détails et on t'aidera pour la structure à utiliser.
Quand on y réfléchit une base de données stocke les données dans des fichiers forcément mais c'est beaucoup mieux d'en utiliser une!
avec une base de données, tu as 40 ans de reflexion et d'optimisation sur le stockage d'informations dans un fichier.
Si tu utilise des index, tu aura ainsi des hashtable automatiquement crées pour parcourir tes index, etc... chose que tu peux implementer dans une solution "orientée fopen", mais bon... tu fera pas mieux que 40 ans de developpement
Si tu as besoin de stocker plusieurs informations differentes en une lignes de code, je suppose que c'est pour en garantir l'atomicité. Tu peux faire ca avec un LOCK TABLE et travailler sur plusieurs tables
En fait je dois enregistrér en une ligne id_client/id_produits/nombre_produits. Donc mon problème c'est s'il a plusieurs produits je dois quand même le faire tenir en 1 enregistrement d'où les array().Citation:
J'ai pas bien compris ce que tu dois stoquer exactement pour un
utilisateur ? c'est juste une liste d'id de produits qu'il possede ?
Je veux bien faire seulement id_client/id_produit/nomre_produit, mais dans ce cas vu que j'ai 20 produits, ça me fera peut être 20 enregistrements pour 1 persone :?
Je ne connais même pas la taille limite de la bdd chez Free.
Cela semble être la voie normal de modélisation de ta contrainte.Citation:
Je veux bien faire seulement id_client/id_produit/nomre_produit, mais dans ce cas vu que j'ai 20 produits, ça me fera peut être 20 enregistrements pour 1 persone
Et si la personne à besoin d'avoir 20 produits associé à son user, elle aura 20 lignes. Si un autre user n'à besoin que de 2 produits, il n'aura que deux lignes.
Pour ce qui est de la taille de la bdd tu as interets à avoir sacrément plein d'user et de produits pour que cela pose problème.Citation:
Je ne connais même pas la taille limite de la bdd chez Free.
De plus, le poids final en l'enregistrant dans la bddd, ou dans les fichiers ne risqent t'ils pas dêtre à peu près équivalent ?
De toute facon la question reste en suspend car je n'ai pas pu trouvé non plus la limite de la bdd chez free.
J'en profite pour revenir la dessus, je ne sais pas de quoi tu as besoin comme informations dans ta base de données. Mais la selection des produtis associés à un user peut se faire en une requete en SQL. Pour le fopen.... C'est possible, cela depends de ton d'organisation.Citation:
Ce qui entraine pour la bdd une éventuelle atteinte à la limite autorisée et beaucoup de requêtes SQL, et pour le fichier texte des fopen() et des traitement de chaines...
Je rajouterai que si tu veux obtenir les descriptions produits associé à l'user X, tu vas lire le fichier, puis selectionné les descriptions. en SQL, cela se règle en une requete.
Enfin, dernière petite chose auquel je viens de penser. Le poids semble être pour toi une contrainte dans ce cas précis. Comment vas tu faire le jour ou tu auras 4 millions d'user ?
Tu vas ouvrir un ficher de 4 millions de lignes sérialisés ?
Et pour une recherche :s
4 millions c'est un peu extrême, je te l'accordes, mais au moins on voit bien ici que tu vas te soulever de nouvelles problèmatiques qui ne sont pas liée intrinsèquement à ton projet, mais plutot au choix de conception.
Et dans ce cas précis ces problèmes sont des pertes de temps inutile pour toi comme pour le client final.
En bref, je suis partisan du passage en bdd.
bye
Merci pour ton avis. Juste un truc sur:
Justement étant donné que j'ai plusieurs table, je fais plusieurs requêtes pour récupérer l'ensemble des données. En local sur EasyPhp pas de problème c'est rapide, mais je me dis que sur Free ça sera plus long. Enfin je verrai.Citation:
J'en profite pour revenir la dessus, je ne sais pas de quoi tu as besoin comme informations dans ta base de données. Mais la selection des produtis associés à un user peut se faire en une requete en SQL.
Merci
Tu peux faire des requetes en cross table (che pas si sa existe ce mot).
Mais bon encore une fois je me demande en quoi tu as absolument besoin d'une table par user :s
Cela doit pouvoir se modéliser autrement.
Tbl_user : iduser , nom
Tbl_usr_desc : iduser, ect
Tbl_user_produit : iduser , idproduits
Tbl_produit : idproduit, nom, ect
Les notations sont pas mon fort, mais sa ressemblerait à cela.
Après il y à surement des choses dont je ne suis pas au courant et qui rendent ce modèle inutilisable dans ton projet.