Bonjour,
 
je vais tenté de vous expliquer mon "dilemme".  
 
J'ai prévu de récupérer un quantité importante de données dans un but d'étude statistiques.
Je pense faire mes études via excel ou tout logiciel similaire permettant notamment la création de graph....
Est-il à votre avis préférable, lors de la récupération de ces données, de les stocker en BDD et de générer un excel depuis les données qui m’intéressent (donc de faire la sélection avant l'ouverture dans le logiciel choisi)  ou de récupérer mes données directement dans un énorme fichier json ou xml (que je mettrai à jour au fur et à mesure) qu'il me suffirait d'ouvrir ensuite directement en excel ? Je tiens à préciser que je n'ai aucun problème avec la programmation. Mon problème viens plus du fait de savoir comment traiter cette importante masse de données.
 
Suis-je assez clair dans ma demande ? J'avoue que c'est pas facile à expliquer.
 
Je suis bien sûr preneur de toutes remarques, idées ...
 
Merci d'avance

A mon avis le choix de la base de données va s'imposer pour une raison simple : la performance. D'autant que tu parles d'une quantité importante de données.
 
Si tu parses un énorme fichier plat à chaque ouverture de ton fichier excel ce sera difficile à gérer au niveau perf.
 
Par contre tu perds un peu en portabilité, puisqu'il faut installer la base.

Je dois avouer que je pensais un peu comme toi mais comme je prévois d'utiliser scrapy et que celui-ci permet l'export en json, csv ou xml, je me disais que plutot que de traiter toutes mes données pour les enregistrer en BDD (+ création de la bDD, de sa structure, des différentes tables....)
 
Je pensais gagner un peu de temps mais c'est sur que si c'est pour en perdre au final a chaque utilisation

Ca vaut peut-être le coup d'essayer. Je pense que le parser peut-être rapide, mais c'est plus comment tu manipules tes données après le souci. Ce sera difficile d'être plus rapide qu'une base de données correctement indexée.
 
En fait tout va dépendre du volume de tes données et de leur organisation.

Tout ceci confirme bien mon premier choix (BDD + export des données nécessaires en csv).
 
Y'a plus qu'à coder tout ça.
 
Merci en tout cas pour vos réponse et à bientôt

+1 pour une BD plus une extraction en csv qui viendra alimenter un onglet d'un fichier Excel. Sur un autre onglet, t'auras tes graphiques qui se mettront à jour en conséquence (au besoin, à l'aide de qq macros VBA). Je fais ça depuis 10 ans pour produire des docs de reporting : ça marche très bien.

Je me permets de revenir vers vous car après réflexion, j’arrive pas à me décider sur le choix d'une BDD (SQL ou noSQL). Je vais essayer de vous expliquer plus en détails.
 
Concernant les données à traiter, je récupère un json ou un csv (scrappy permet d'exporter les 2 formats). Il va s'agir de données sportives. Pour donner un exemple, un club de foot avec des joueurs, un entraineur, un stade, des matchs, des données météo suivant le match, le résultat....
 
Le but de tout ça est de faire des études de stats pour un match à venir. Comparaison des équipes suivant la météo, le stade (domicile ou extérieur), l'entraineur qui a changé, les performances sur les derniers matchs , la date dans la saison... Je peux avoir aussi envie de voir tout ce qu'a fait un entraineur (tous ces matchs tout club confondus), idem pour un joueur, pour un type de temps donnée...
 
Globalement, je vais avoir bcp de données, toutes structurées de la même manière (quasiment   ), que j'ai besoin d'écrire une seule fois mais de lire plusieurs fois (extraction vers mon excel).
 
Je tiens à préciser que je suis dans la vie développeur php/mysql/css. J'ai donc des connaissances en SQL mais aucune en NoSQL.
 
Qu'est ce qui d'après-vous serait le plus logique ? Apprendre le NoSQL car je risque d'avoir rapidement bcp de données ? Passer du temps à structurer mes tables parfaitement et parser mes json ou csv avant insertion. Insérer le json directement dans une table NoSQL orientée documents ? orientée graphe ?....
 
Merci à tous pour vos pistes de réflexion
 
ps : si vous pensez que ce serait mieux que j'ouvre un autre topic, n'hésitez pas.

Une BD Mysql en MyIsam (vu qu'il y a plus de lecture que d'écriture) bien structurée et surtout, bien indexée, ça devrait le faire sans pb. Faudra surtout bien la structurer par rapport aux traitements (stats) que tu voudras faire. Pour info, j'ai déjà fait des tables de plusieurs millions de lignes, ça passe sans pb

J'etais plus parti sur du inno_db car je ne pensais garder des stats que sur 5 ans maxi. Donc quand je voudrais en supprimer, je me disais qu'une bonne structure en inno_db serait plus facile et plus efficace.
 

 
bien indexée c'est a dire ?
 

 
c'est à dire bis ?    
 

bien choisir quels champs indéxer, voire créer des index portant sur plusieurs champs. Ca dépendra de tes requêtes et des jointures que tu feras. Le choix des index n'est pas définitif : à coup de EXPLAIN sur tes requêtes, tu verras quels index sont prix et si c'est ce qui te paraît pertinent. Si c'est pas le cas, tu change les index, tu refais du EXPLAIN et tu vois les temps d'exécutions. Tu fais ça jusqu'à avoir trouvé soit des perfs satisfaisantes, soit la meilleure combinaison d'index qui t'offre le meilleur temps d'exécution.
Au passage, un tuning du fichier de conf de Mysql ne sera probablement pas du luxe, notamment pour augmenter la taille de certains buffers et caches
 
Pour la structuration, difficile de t'en dire plus ne connaissant pas les données que tu manipules ni précisément les stats que tu vas faire dessus. En gros faudra construire tes tables et les liaisons entre-elles de manière à ce que les jointures ne soient pas trop complexes et les calculs sur certains champs minimisés.
Edit : ça veut dire que tu respectera peut-être pas forcément scrupuleusement la forme 3NF de Codd
http://fr.wikipedia.org/wiki/Forme [...] me_normale

Je dois avouer que je n'ai jamais utilisé les index (honte à moi   ) mais d'après le peu que je viens d'en lire, ça va m'être utile sachant que je ne vais principalement faire des recherches et extraction sur un nombre restreint de champs (nom du joueur, de l'entraineur...).
 
Concernant la structuration, ce qui me fait peur, c'est mes tables de liasions. Je pense que je vais en avoir un paquet avec pas mal de champs liés à la liaison... à voir, je ne sais pas encore trop

T'as jamais utilisé d'index dans tes BD C'est à coup à te pourrir grave les perfs !
Je te conseille vivement de bien prendre ton temps pour faire le MCD. Sinon, c'est mort...

Autant pour moi, j'ai déjà utilisé des index    mais jamais dans le cadre d'une consultation. C'était plus dans le sens d'une suppression d'un champ avec suppression en cascades des enregistrement liés.
 
J'ignorais complétement que cela augmenté les perfs en cas de consultation. Pour moi c'était plus une histoire de cascade des MAJ ou suppression

Tu confondrais pas avec les clés étrangères voire avec les triggers, là Parce qu'un index trouve son intérêt principalement dans les requêtes de type SELECT ou d'autres types de requêtes contenant des clauses WHERE (je pense au UPDATE ou DELETE)...

Au boulot je m’embête pas, pour les BDD j'utilise phpmyadmin et dedans, quand je fais référence à une clé étrangère, je la signale comme Index et après je défini le comportement en cas d'Update ou Delete dans la gestion des relations de la table; c'est dans ce contexte là que je parles d'index. Mais j'ignorais que cela avais une valeur en terme de Select et de gestion des ressources/vitesse...
 
Donc en gros j'ai l'impression que l'on parle de la même chose non ?    
 
Par contre, j'ignorais que tu pouvais définir un Index sur une colonne qui n'est pas une clé étrangère et que cela accélère la remontée de données si tu fais une recherche sur cette colonne

Ca accélère la recherche si l'index est bien utilisé. C'est pas aprce que tu définis un index qu'il est utilisé par l'optimiseur de requêtes, en particulier quand tu définis plusieurs index sur une même table, d'où l'utilité de la commande EXPLAIN pour voir comment Mysql traite ta requête (ordre de jointure des tables, index utilisés...).
 
Quasi systématiquement, la clé primaire est un index. Les clés étrangères, en général aussi, mais dans le cas où y'en beaucoup dans une même table, c'est pas forcément judicieux de définir un index sur chacun d'elle.
 
Il me semble que l'optimiseur de requête a une règle qui considère que si un index oblige à parcourir plus du 1/3 du nb de lignes d'une table, il ne l'utilise pas car l'index est considéré comme pas efficace.
C'est pour ça que dans certains cas, ça peut être utile de définir des index composés de 2 ou 3 champs (index composés).

Ok Ok, reste plus qu'à s'y mettre. Je passerais peut-être te poser un aperçu de ma base de données et de mes MVC si ca te dérange pas.
 
En tout cas, merci pour ton aide.
 
A bientôt peut-être

Pas de quoi

Bonjour,
 
Juste comme ça...
 
Vous parlez d'une base de données : pourquoi utiliser MySQL alors qu'on est en environnement Microsoft -Excel- et donc que SQL Server Express est disponible ?
 
Ensuite, vous parlez d'extraire les données en CSV (ou autre ignominie) avant de les ouvrir dans Excel... Pourquoi ?
Excel est capable de charger des données directement depuis n'importe quelle base de données, du moment qu'il existe un pilote ODBC.
Et même mieux, on peut charger des données à partir d'une requête (et non une simple lecture séquentielle table par table).
 
Bref, vous vous compliquez pas un peu la vie là ?
 
1/ Un DSN sur la machine client.
2/ Un fichier Excel tout bête, configuré pour utiliser le DSN.
3/ 5 minutes de formation pour expliquer à l'utlisateur comment charger des données dans Excel à partir d'une source de données distante
 
Et vous faite des heureux (autant qu'il y a d'utilisateurs).