[C# inside]
Bonjour tous,
voilà le problème: je suis en train de développer une appli en C# (qui tournera en local).
Cette appli se log sur une BD qui comprends des images…
The question: sachant que c’est une appli qui ne tournera qu’en local, vaut-il mieux que je stocke les images sur le HDD indépendament de la bd; bd dans laquel je mettrais un champs qui contiendra le chemin vers l’image; ou puis-je me permettre de mettre les images directement dans la BD (type blob).
Je sais que la première solution est meilleure, mais pour des questions de gestion de la bd, je préfèrerais de loin la seconde. Donc, la VRAI question est: faut-il absoluement proscrire l’insertion d’images dans la BD dans le cadre d’une exécution locale ?
Autre question, dans cette appli, l’utlisateur peut modifier la luminosité et le contraste de l’image. J’y suis parvenu en restant absoluement en mode safe. Le problème, c’est que ça rame à mort…
En mode unsafe (avec pointeurs donc); ça turbine à donf… The question: si je ne met QUE la portion de code qui se charge de la modif de la luminosité / contraste en unsafe, est-ce que seul cette partie sera en unsafe et le reste en safe; ou c’est toute l’appli qui sera compilée en unsafe ?
edit: orthographe…
Bon, désolé si mon post parait passablement confus Ce message a été édité par aristidi le 02/06/2004
Ca depend surtout de la taille et du nombre de tes images, de la db que tu utilise et de la quantite d’acces que tu veux y faire. La comme ca on peut pas dire
Sinon y a pas de mal a faire une portion de code “unsafe” c’est meme encourage pour que ca trace dans ce cas, mais ne compte pas faire tourner ton app en “partial trust” (sur le reseau ou en “no touch deploymnent” sur le net). C’est le seul inconvenient. Tu dois aussi utiliser le switch unsafe pour compiler, mais bon unsafe, c’est un mot clef pour te faire peur surtout Si tu sais exactement ce que tu fais et que tu code proprement c’est pas plus unsafe que du C++ … surtout si tu te limite a une portion de code qui manipule des donnees et ne fait pas d’allocation memoire…
J’ai souvent implémenté les deux. J’aime pas trop les images en base de données parce que c’est plus difficile à administrer (tu es obligé de passer par de l’applicatif pour voir et manager les images). Le problème avec les images dans le système de fichiers est le couplage avec la base de données: tu peux être sûr qu’au bout d’un moment, les deux seront désynchronisés. Il faut donc un mécanisme de nettoyage.
Si tu as beaucoup d’images, il faut aussi créer des sous-dossiers à la volée (par exemple sur un critère de date) pour éviter d’avoir tout sous le même répertoire (ce qui est horrible au-delà de quelques centaines d’images) alors que en base, no problemo.
Donc effectivement comme dit GloP, ça dépend du nombre d’images et de tes besoins en termes d’admin.
Merci pour vos réponses.
Après avoir lu vos post et mure réflexion, je me décide à ne pas mettre les images dans la bd (il devrait il y en avoir au bas mot environ 2000 en 320 x 200; voir 640 x 400).
Ca va être un peu plus pénible au niveau de la gestion de la db; mais c’est vrai que je n’avais pas encore pensé à implémenter un mécanisme de nettoyage.
Pour la partie unsafe, je suis rassuré; même si j’aime autant le C++ que d’aller chez le dentiste (pardon aux défenseurs de ce langage, et je sais qu’ils sont nombreux )