Discussion :

[Guillaume56]

Bonjour à tous,

Mon entreprise, une fois que j'avais développé un programme en VBA, m'a annoncé que la suite Office serait retiré d'une partie des postes. J'ai donc pris le parti de convertir mon travail en une application VB.NET voire ASP.NET si je suis pas trop mauvais.
Mon problème est le suivant : j'ai créé les WindowsForms assez facilement, mais je m'interroge sur la gestion de mes données. En fait, je récupére mes données d'Excel sous forme de fichier CSV. Je lis ce fichier et je place les données dans un tableau à deux dimensions. L'utilisateur se sert alors du programme. Il faut ensuite que je réécrive les données modifiées dans le fichier.
Et c'est à ce moment précis qu'arrivent mes ennuis : je n'arrive pas à passer de mon tableau à deux dimensions à un fichier CSV. De plus, je me dis que si plusieurs personnes souhaitent se servir de l'application en même temps, cela peut poser problème de travailler sur le même fichier.

- Est-ce-que à votre avis je me suis mal orienté en passant par un fichier CSV, peut-être aurais-je du passer par une BDD ?
- Si non, comment faire pour passer d'un Tab(x,y) à un fichier CSV ?
- Si oui, est-il possible d'envoyer un tableau Excel vers une BDD et récupérer les données d'une BDD pour Excel ensuite ?

Merci à ceux qui répondre à une ou plusieurs de ces questions !

Guillaume56

[mactwist69]

Hello,

En effet, le défaut de la gestion des données par fichier (Access inclu) est bien l'accès concurrent qu'il faut gérer... Une vrai galère.

Normalement, il faut donc utiliser un SGBD, même gratuit (Microsoft SQL Server Express, MySQL...)

Une fois que tu auras chargé tous tes fichiers en BDD, tout le monde travaillera en BDD.

Ce qui n’empêche pas que ton application puisse offrir la possibilité d'exporter les données dans un fichier excel, à la demande.

[DotNetMatt]

D'accord avec toi mactwist, par contre ceci me pique un peu les yeux :

Normalement, il faut donc utiliser un SGBD, même gratuit (Microsoft SQL Server Express, MySQL...)

MySQL n'est pas gratuit
Je ne sais pas si on peut réellement le classer dans la catégorie des SGBD vu la pauvreté des fonctionnalités fournies.
==> Il vaut mieux se tourner vers PostGreSQL plutôt que vers MySQL.

Voir ici : MySQL ? Un SGBDR poudre aux yeux !

[mactwist69]

Lol, j'avais oublié qu'il n'était pas de "bon ton" de proposer MySQL.

En lisant l'article, effectivement on vois des défauts, mais bon, c'est quand même hyper technique comme critique (voir carrément rigide), en tout cas à charge.

Pour un mec qui fait une petite application avec 50 tables, est ce qu'il en a quelque chose à faire de la moitié des critiques formulées ??

Je ne prends qu'un exemple par chapitre :

- pas de possibilité de donner la priorité à certains threads
- pas de process unique d’allocation mémoire : chaque moteur à le sien
- MySQL n’a pas de méta données statiques (tables systèmes)
- des index sur des colonnes calculées ou des expressions sont impossibles
- gestion du cache des procédures peu évolué (la paramétrisation semble inexistante)
- aucune possibilité d’utiliser un langage externe (sauf pour coder les UDF)
- pas d’outil pour vérifier la consistance des données répliquées
- du fait que les tables sont stockées chacune dans un fichier différent, leurs noms peut être sensible ou non à la casse
- pas de requêtes récursives
- le niveau d’isolation snapshot n’est pas implémenté
- indexation full texte (recherches textuelle) plus que limitée
- pas de stockage compressé des données
- pas d’authentification possible par certificats
- aucun parallélisme possible pour la sauvegarde (sur plusieurs fichiers, à plusieurs destination, par plusieurs threads…)


Dans le même temps, cet article l'auteur fait (aussi) la pub à PostGReSQL... (Vous avez des actions là-bas ?)

Sauf que les défauts (impardonnables) de MySQL... PostGreSQL à parfois les mêmes :


1 – Aucune gestion des espaces de stockage
2 – Une gestion des transactions « curieuse »
3 – Un partitionnement plus que léger
4 – Pas de tag (hint) pour forcer les plans de requête
5 – un optimiseur très limité
6 – Une indexation à la traine
7 – Pas de parallélisme des requêtes
8 – Une administration couteuse
9 – pas de pooling des connexions
10 – Pas de vision d’un plan en cours d’utilisation
11 – Un processus de sauvegarde peu performant
12 – Pas de compression ni de cryptage des données
13 – Pas de réplication des données

Source : http://blog.developpez.com/sqlpro/p1...resql_ou_com_2


C'est pas que j'ai envie d'être désagréable, mais j'ai du mal à avaler les idées toute rondes.

[DotNetMatt]

En lisant l'article, effectivement on vois des défauts, mais bon, c'est quand même hyper technique comme critique (voir carrément rigide), en tout cas à charge.

Effectivement cet article est à charge, mais à juste titre. C'est une daube et il faut bien se rendre à l'évidence. Youtube est souvent cité en exemple, ils ont fait le choix de MySQL au début en se disant "bof, on migrera plus tard vers un SGBD plus robuste". Résultat impossible de migrer car aucune norme n'est réellement suivie, et ils ont aussi essuié les platres de nombre de fonctionnalités manquantes. Ils ont ensuite décidé de collaborer fortement sur le projet afin de faire partager leurs améliorations au grand public. A côté de ca, il faut voir aussi ce que ca leur a coûté au niveau maintenance et scalabilité (serveurs, backups, etc.).

Pour un mec qui fait une petite application avec 50 tables, est ce qu'il en a quelque chose à faire de la moitié des critiques formulées ??

Il s'en cogne certainement au début de son projet parce qu'il n'a pas conscience de tout ca. Un jour il va revenir te voir et tu vas lui dire que ce qu'il cherche à faire n'est pas supporté sur MySQL Cas déjà vécu à l'époque où je le recommandais... Bref, en même temps il va prendre de mauvaises habitudes entre autre parce que MySQL est très permissif au niveau SQL, sans compter les bidouilles pour essayer d'obtenir le résultat escompté. Enfin, il va vouloir migrer mais impossible, du moins pas facilement.

Dans le même temps, cet article l'auteur fait (aussi) la pub à PostGReSQL... (Vous avez des actions là-bas ?)

Non, c'est juste le seul gratuit qui soit recommandable. Si tu as l'occasion de faire un tour sur le forum SQL tu verras que PostGreSQL est plus populaire que MySQL, et il est (presque) toujours recommandé lorsque l'OP hésite entre MySQL et PGSQL.

Sauf que les défauts (impardonnables) de MySQL... PostGreSQL à parfois les mêmes :

Oui mais disons que PGSQL ne souffre "que" d'environ une vingtaine de défauts, contre à vue d'oeil (pas compté) une centaine pour MySQL

C'est pas que j'ai envie d'être désagréable, mais j'ai du mal à avaler les idées toute rondes.

Pas de soucis, on ne t'oblige pas à avaler ces idées, libre à toi de continuer à recommander MySQL, mais si on peut éclairer l'OP pour qu'il fasse un choix judicieux et en son âme et conscience, pourquoi s'en priver ?


A l'occasion passe un coup sur le forum SQL tu verras le nombre d'inepties qu'on peut lire parce que les OP ont démarré avec MySQL et pris de mauvaise habitudes - que ce soit en terme de syntaxe SQL ou en terme d'administration.

[Pol63]

je ne connaissais pas trop mysql, mais le peu de ligne que j'ai lu sur l'article fait en effet très peur ^^

pour en revenir au sujet principal, la question à se poser c'est
les données doivent elles être accessibles par plusieurs utilisateurs => sql server express sur un "serveur"
ou par un seul => n'importe quoi ira (sauf excel bien sur ^^) (et le choix dépend de la taille de données nécessaire, access/sqlite/...)

par contre vba => vb.net c'est un bon, donc ca peut prendre un peu de temps pour se former, surtout avec le passage à une vraie bdd
un cours utile : http://plasserre.developpez.com/cours/vb-net/

[Guillaume56]

Bonjour à tous,

Merci pour vos réponses.

J'ai dans un premier temps refait une partie de mon application en VB.net avec des WindowsForms, qui fonctionne bien sur fichier, il faut maintenant que je passe à la BDD !

Guillaume