Discussion :

[haxball47]

Bonjour, étant à la base développeur Web, je ne parvient pas à savoir comment stocker des données pour que celle ci soient utilisables par le plus grand nombre.

Après quelques recherches, je me retrouve avec du Mysql, du Oracle, des fichiers Json, Access et bien sur tout les documents structurés comme les .ini .xml etc

L'idéal pour moi serait Mysql, seulement pas tout le monde n'a un serveur Sql local (en cas de déploiement de l'application), ou une connexion internet à proximité.

Lors de l'installation, je ne me souviens plus du nom, mais il y avait la possibilité d'installer un système de Bdd (Microsoft Sql Server ?), je présume qu'en cas de déploiement de l'application sur un poste n'ayant que le Net Framework installé, celui-ci ne fonctionnera pas ?

Et vous comment manipulez vous vos données ?
Quels sont les problèmes ou les avantages que vous avez rencontrés ?

Merci par avance pour vos retours d’expérience et vos avis et désolé si j'ai posté au mauvais endroit.

[DotNetMatt]

Au niveau du format de stockage, tout dépend de ce que tu as comme données à stocker, et de ce que tu veux en faire. Un fichier INI n'a pas la même finalité qu'une base de données quelle qu'elle soit.

Concernant l'utilisation d'une DB SQL, rien ne t'empêche d'embarquer l'installateur du serveur et de le lancer en mode silencieux lors de l'installation sur le poste client. Sinon, tu peux aussi faire en sorte d'avoir ton propre serveur de base de données, et de créer une base par client. Ainsi pas besoin d'installer le serveur sur les postes clients.

Attention avec MySQL car même s'il s'est fortement amélioré ces dernières années, il reste encore en-deçà de ce que l'on peut obtenir d'un SQL Server ou d'un Oracle par exemple. Donc il faut bien analyser les besoins avant de sélectionner le moteur de base de données.

Pour SQL Server, tu as la version Express qui est gratuite, avec quelques limitations, mais en principe ce n'est pas bloquant pour de petits projets. Il existe aussi la LocalDB.

Access est clairement à éviter. C'est bien pour bidouiller dans son coin, ou pour les non-informaticiens, genre le fiscaliste qui veut accélérer une partie de son travail quotidien et qui n'a pas le budget pour le faire faire à l'IT...

Donc si tu veux qu'on t'aiguille un peu plus, il faudrait qu'on en sache un peu plus sur ton projet et sur ce que tu veux faire de tes données

[haxball47]

Merci DotNetMatt pour ta réponse claire et limpide

Pour le moment pas de type de données particulières en tête, je me fais la main, en concevant de petites applications sans grand but précis.

Actuellement je suis sur un logiciel qui permet de gérer mes Snippets, il me permet de classer mes fonctions, dans différents langages, avec possibilité de recherche en temps réel via mot clef.

Il est à ce stade fonctionnel, mais utilise de simples fichiers .txt pour les Snippets, et des répertoires pour les langages.

Jusqu’à la tout va bien, mais j'ai peur qu'a force d'ajouts le programme se révèle être long à ouvrir les fichiers un à un, à chaque modification de ma TextBox(champ de recherche), pour chercher si l’occurrence entré se trouve dans le fichier ou non.

Entre temps j'ai un peu regardé dans Visual Basic et si j'ai bien compris lors de mon essai, Microsoft SQL Server est utilisable sans installation préalable sur les postes clients hormis le NetFramework.

La LocalDB, au vu du nom, devrait déjà bien me convenir, je vais creuser de ces 2 cotés.

[Pol63]

tout dépend du volume de données et de l'utilisation : mono utilisateur mono poste / mutli utilsateur multi poste

en mono utilisateur pour 3 ou 4 info, un fichier type .ini
pour un peu plus de données l'xml est pratique (il y a la sérialisation xml qui évite de taper trop de code) rien n'empeche derrière d'avoir le contenu dans des fichiers txt via la description et le chemin dans du xml (l'xml ca prend de la place et ce n'est pas spécialement performant)

pour un peu de plus de données (entre 5 et 50 tables par exemple) et un peu plus de performances il y a les bases de données fichiers
ces bases de données ne nécessitent en général aucune installation (ou un truc silencieux et simple)
access pour ceux qui aime (il en reste ...) sql server CE pour un peu plus de robustesse et de performances
néanmoins il manque pas mal de chose qu'il y a sur les vraies bases de données

après on a donc les vraies bases de données réseaux, là on ne tape pas directement dans le fichier mais ca passe par du tcp/ip, sql server express est parfait et gère jusqu'à 10Go depuis 2008R2
c'est stable, performant, ca ne craint rien (mysql je pense qu'on en voit vite les défauts quand on a l'habitude de mieux)
normalement pour ce genre de base de données on passe par une installe manuelle sur un serveur dédié à ca, ca peut s'automatiser si on doit en installer souvent

il y a aussi les hébergements de base de données sur le net, tel SQL Azure (l'équivalent d'une vraie base de données donc on ne gère pas la sauvegarde ni la gestion du serveur)

par défaut dans le framework il y a ce qu'il faut pour access, sql server, et odbc
pour access on a le choix entre jet (x86 seulement) et ace ole db
pour oracle, mysql, sqlite et autre il faut une dll tierce à installer ou à mettre à côté de l'exe

après les bases de données c'est un monde aussi, avec quelques Go de données si on fait la structure en improvisant et les requetes au hasard ca fini par ralentir fortement et parfois bloquer tout ...

[haxball47]

Merci Pol63 pour tes explications,

Je pense que je vais me tourner vers du sql server, il semble à vous lire que se soit une bonne pratique, qui convienne dans bien des cas.

Encore un grand merci à tous les deux