Reprise du message précédent :

Non, 5, quand même pas, même Access sait faire mieu MSDE c'est fait pour inciter les développeurs à arrêter de distribuer du MSJET dans leurs applis bureautiques, c'est pas pour ajouter des contraintes en plus

Bah, le MSJET est toujours nécessaire si t'utilises un fichier MDB comme fichier de stockage pour ton appli, et qu'il faut pouvoir utiliser ce fichier comme t'utiliserais un fichier word par exemple...

Sinon, pour en revenir au point de vue "serveur", que ce soit MSDE ou MySQL, une machine de récup avec un peu de mémoire (256 au moins si possible) suffit amplament. Ensuite, pour l'OS, Linux pour MySQL, ou Windows 2000 Pro pour MySQL et MSDE semble tout à fait correct.
 
En tout cas, dans un premier temps, l'acquisition d'un serveur dédié à ça me semble superflue. Concentrez-vous plus sur la migration de l'outils. Le vieux Goupil qui faisait tourner votre base Access sera amplement suffisant à coup sûr.

J'ai pas dit le contraire. Juste que M$ juge à juste titre que c'est une hérisie d'utilise un fichier MDB pour stocker des infos, quand on peut utiliser MSDE qui est gratuit, infinimement plus puissant, et surtout remplaçable par un vrai SQL Server installé sur un cluster de 800 machines octo-processeurs sans changer une seule ligne de code de ton programme (même pas la chaîne de connection, c'est pour dire)

Merci de toutes ces precisions je m'envais convaincre mon patron de laisser tomber ce **** de MySQL et cette **** de linux

Voilà, dans une utilisation client-serveur, c'est sûr que c'est mieux

Ceci dit, ça dépends de votre utilisation. MySQL peut être très bien aussi.
Juste que SQL Server selon moi offre la garantie de ne pas passer à côté un truc à la con qui ne serait pas géré par MySQL.

Ben à la limite, même pour une appli locale.
 
Imagine que demain une PME te demande de faire un petit outil de comtpa pour la secrétaire. Etant toute seule, tu lui fait un veux truc merdique avec Access et des macros Excel.
 
Bah le jour où la PME grossi, ou ouvre une seconde agence ou simplement qu'il y a deux personnes à la compta, proutch, t'es emmerdé.
 
Alors que si tu fait un truc avec MSDE, même si le programme se résume à des Macro Excel qui vont interroger/modifier la base MSDE, t'aura pas de problème pour le passage en client/server

Ben si tu dois refiler les données, c'est relou. Vu que MSDE est sous forme de service, y'a de fichier au même titre qu'un MDB ? Et en plus faut installer MSDE en plus ?

Tu peux installer MSDE sous forme de package (et ça fait que 45 Mo donc c'est pas trop merdique à distribuer, même via internet)
Ensuite, ta base, normalement c'est une base vide, donc un simple script de création en SQL (que sait générer SQL Server à partir d'une base existante) est amplement suffisant Sinon, tu peux toujours distribuer un backup d'une base, que tu peux restaurer en ligne de commande à la fin de l'install.
 
Bref, guère plus compliqué qu'une base MDB, avec la garantie de ne pas être emmerdé derrière par les problèmes d'évolution.

Ben genre dans une appli sur laquelle je bosse, j'ai besoin d'un fichier où stocker plein de données. Et on doit pouvoir se refiler le fichier comme on se refilerait un document word. Du coup je passe par un fichier MDB, vu que dans ce cas on est toujours tout seul à bosser sur le fichier...

Bon on dirait que ca avance
Quelqu'un saurait combien couterait Windows Server 2003 + SQL Server 2003 (ou bien un site ou voir combien cela coute)

SQL 2000, y'a pas de 2003, et le 2005 arrive bientot

FlorentG > Pour ce type d'appli (à condition que tout le monde bosse sur un même réseau évidement) il est beaucoup mieu de centraliser les données sur un unique serveur : ça évite les problèmes de versions des données
 
Sinon, pour en revenir au coût de ta demande (ton patron il va avoir mal au derrière, je te conseille de lui acheter un tube de vaseline pour aller avec, ou alors de se contenter de MSDE dans un premier temps sur un serveur plus humble )
 
- Windows 2003 Server Standard Edition : 555 € TTC
http://www.surcouf.com/Catalogue/f [...] ct=9532506
 
- SQL Server 2000 Standard Edition. Il y a trois modes de licences :
http://www.pc21.fr/Developpement2.asp?cat=93
-> 5 licences clients : 1686,36 € TTC
-> 10 licences clients : 2573,46 € TTC
-> 1 processeur (nb clients illimités) : 5645,12 € TTC
 
Attention : un "client" représente une connexion active si mes souvenirs sont bons.
 
Pour le serveur qui va avec, un simple PC avec 512 Mo à 1 Go de RAM suffit amplement pour tirer correctement partie de tout ça.
 
Ensuite, rien ne vous empêche de prendre un Server quadri-processeurs avec 8 Go de RAM par processeur, mais bon...
 
Dans ma boîte, pour des serveurs Web très solicités, on conseille de bi-xéon 3.06 GHz avec 2 Go de mémoire, plus 2 HD SCSI 15trm de 60 Go (un pour le système et le journal des transactions, et un second pour les données). Pour moi, vu votre utilisation actuelle, tout ça est très superflu. Dans un premier temps, utilisez MSDE avec un PC existant sous 2000 Pro, la migration vers un autre serveur avec un "vrai" SQL Server dessus n'étant absolument pas un problème (dans l'appli d'admin de SQL Server, y'a un wizard à 4 écrans pour migrer une base d'un serveur à l'autre, ça prends en tout et pour tout 10 minutes pour une base déjà bien conséquente )

Arjuna -> Mais pour faire l'analogie, tu va pas mettre un fichier word sur serveur... Moi mon besoin est de stocker des données dans un fichier dans le même principe qu'un fichier texte, ou un document word, ou une image jpeg. Le fichier doit pouvoir être redistribué sur CD-ROM facilement par exemple...  
 
Je n'ai pas dans ce cas là une architecture client-serveur...

Voilà un apperçu rapide d'une machine qu'on a préconisé à un de nos clients (setupée en Avril dernier comme en témoigne la date de création de la base )

Ben oui, mais je ne comprends pas bien le principe de distribuer un fichier Word avec une base de données sur un CD.
 
PS: et le fichier word, il n'a rien à faire sur le serveur, y'a que la base qui doit être dessus
Et le fichier Word seul, y'a aucun problème pour le distribuer

il est clair qu'un serveur linux est peut-être plus compliqué à maitriser de base, mais un serveur, c'est pas qqch qui bouge tout le temps : on met en place et après on touche plus (ou plus beaucoup) après c'est pas l'OS mais les applis qui tournent dessus qui sont importantes.
 
Le plus gros défaut de windows est sa gourmandise de base (surtout d'un point de vu graphique) et son manque d'outils de base (faut tout acheter : proxy, mail, ftp ...) et de grosses lacunes en scripting (vital pour un serveur). De plus il est impossible d'avoir une maîtrise fine du système (dès que l'on sort de l'assitant c'est un peu le merdier).
 
Le plus gros défaut de linux c'est sont manque d'assitant pour les non-spécialistes (le mot est faible) mais en contre partie on maitrise finement le système et on a le choix des outils (par exemple pour la gestion des utilisateur on peux le faire via NIS, via LDAP, en local, etc...).
 
Pour conclure, il est certain qu'un serveur orienté perfs (je ne parle pas de web, mais d'applications critiques haute disponibilité ou de centres de calculs) se fera sous un système de type unix pour le reste c'est suivant les gouts, les couleurs.... et les moyens

 
Je vois que t'as pas pigé ce que j'ai dit
Il fallait voir le fichier MDB comme un fichier Word. Pour moi le fichier MDB n'est que le format de fichier utilisé pour mon appli. Comme c'est un truc déjà tout prêt, j'ai réutilisé. J'pourrait aussi essayer à l'occaze de sérialiser un DataSet histoire de voire...

 
Je vois pas en quoi un CLI peut être plus rapide qu'une interface Entre taper des trucs et cliquer sur des trucs, c'est les clicks les plus rapides
 
C'est même pas un débat CLI vs. Clickodrome, c'est de la logique, voilà tout... Genre aujourd'hui encore j'avais une bête requête select à faire, pour générer un bidule (c'est du .NET). Donc deux options s'offraient à moi. Soit taper la requête, soit sélectionner la table et les champs. Ben entre taper "SELECT id, parent, order, name FROM part_hierarchy" et "click double-click click click click click", si on considère qu'une touche frappée et qu'un click prennent le même temps, la série de clicks est effectuée beaucoup plus rapidement

vi, FlorentG, tu parles d'EDI, pas d'OS là... mais je voudrais que tu me retrouve rapidement les lignes d'un fichier de log qui commencent par "Erreur" sous Windows Server avec que des clics et le temps que ça te prendra

 
Ok C'est sûr que dans le cas d'une recherche, c'est pas le waf waf de XP qui fera l'affaire Donc oui dans ce cas là un CLI est nécessaire

non mais même en dehors de la boutade, windows n'offre que trop peu d'outils d'analyse par défaut, il faut installer perl alors que sous un unix du awk, du grep et consort le font par défaut...

Et encore, Windows Server 2003 a arrangé pas mal de truc côté CLI, y'a la race de trucs en plus (genre command FIND pour rechercher)

Donc dans logorhn server, ils vont finir par virer l'interface graphique à force de pomper sur unix  

 
Même qu'il vont révolutionner les CLI. Genre tu pourra avoir faire interagir des objets via CLI

Et toi, dis-moi combien de temps mettre une secrétraire à retrouver un fichier contenant le mot "Erreur" sous Linux (bon, OK, une secrétaire n'a rien à faire dans une salle serveur mais bon, dans les PME on fait avec les moyens du bord

Ceci dit, sous Windows, il y a un truc qui s'appelle WSH, qui est installé de Base et ce depuis Windows 95 IE 3.02
 
Ca permet de faire des scripts VBS, JS, et d'autres langages (suffit d'installer les bons modules) capable de tourner directement sous Windows, appelables depuis une ligne de commande, tout comme un perl, donc le coup du PERL, c'est bidon, y'a juste qu'un admin NT est con, et qu'il ne sait pas se servir de ses outils, alors qu'un admin unix ne peux pas faire autrement que savoir s'en servir.
cqfd.

 
Ben faudrait une formation en CLI pour les secrétaires

c'est vrai que mettre une secrétaire pour analyser les logs... à moins que ce soit l'admin qui fasse de temps en temps le secrétaria... là ça marchera...

Ah ben je vois que j'ai réussi à détourner qqun d'utiliser mySQL en entreprise
mySQL c'est bien pour les forums où les applis non critiques, mais en entreprise faut surtout pas

ha tiens c'est nouveau Google n'est pas une application critique...

ben pas vraiment en terme de contraintes non, google c'est juste du stockage

donc tu peux expliquer ce que tu reproche à MySQL plutôt que de dire "c'est nul, ça marche que pour du stockage" au moins ça pourra aider à peser le pour et le contre de chaque solution. Soit un peu plus constructif stp...

Oui c'est vrai tu as raison
Jdis pas vraiment que c'est nul, plutôt que c'est plus une base de donnée qu'une base de donnée relationnelle quoi. Avec des developpeurs pas toujours à attentifs t'as vite fait à te retrouver avec une base incohérente et ça ça craint à mort en entreprise (tiens on retrouve plus les factures, tiens le produit commandé n'est pas référencé, tiens...)

euh non, et jfais pas vraiment partie des détracteurs de l'open source puisque je m'en sers tous les jours, merci de pas faire d'amalgamme.
Si le dev est une quiche, un SGBD normal l'enverra chier, mySQL bronchera pas et enregistrera des données vérolées, soit pas de mauvaise foi quand même hein
 
Analyse perso qui peut être fausse, mySQL est très répandu surtout pasqu'il a dû être un des premiers gratos, et pasque le couple php + mySql est hyper répandu et hébergé gratos sans problème, mais pas gràce à ses qualités (enfin ça va ptêt changer avec les nouvelles versions), mais maintenant il fait plus le poids face à d'autres produits open source comme firebird, hsql et plein d'autres.

En Open Source, je ne connais que mySQL. J'ai pas mal ouïe-dire à propos de PostGre SQL, et ayant travaillé pendant mes études sur Open Ingre, qui fait partie de ses ayeux, je peux déjà dire, de but en blanc qu'au point de vue des Open Source, mySQL est, d'un point de vue fonctionnel, très très loin derrière 90% des autres SGBD, qu'ils soient payants ou Open Source.
 
La raison du succès de mySQL remonte à l'époque des premiers serveurs mutialisés qui se sont mis à proposer du PHP.
 
mySQL était à l'époque extrêment rapide. Il ne savait pas faire grand chose, mais il était le seul à être capable de le faire aussi rapidement. A cette époque, où Linux n'était pas du tout fiable, et que seuls des serveurs Unix étaient capable de faire tourner convenablement des sites web, s'est donc imposé le produit le plus lite, puisque la différence de prix entre un serveur Alpha et un x86 est loin d'être négligeable.
 
C'est de cette époque que vient mySQL uniquement, tout comme la popularité de MS-DOS (puis Windows) ne vient que du fait qu'ils ont été les premiers OS / Environnement graphiques à fonctionner sur plateformes x86.
 
Ensuite, que ce soient Mirosoft ou la communauté mySQL, chacun à sû exploiter cet avantage afin de perdurer malgré leurs limitations.
 
Encore aujourd'hui, mySQL couvre un domaine fonctionnel très en deçà du premier SGBD de bureautique venu, tel qu'Access. Les dernières avancées de mySQL en ce qui concerne sa couverture fonctionnelle laissent promettre pas mal quant à l'avenir, mais aujourd'hui, il est très largement inadapté à la moitié des utilisations qu'on en fait dans les entreprises.
 
Un moteur de recherche tel que Google est un des seuls type d'application où mySQL a une réelle supériorité par rapport à ce qui existe sur le marché (en gratuit ou non). Pourquoi ?
Parceque d'un point de vue complexité des données, un moteur de recherche reste extrêment simplissime. Par contre, l'immense volume de données à traîter nécessite un SGBD particulièrement léger, et capable d'aller très vite. Un peu à la façon d'une formule 1 qui n'a pas d'essuie-glasse ni de climatisation, mySQL est êtrement rapide, car ne sâchant presque rien faire, il ne perd pas de temps avec les fonctions présentes sur les autres SGBD. Maintenant, aller à un séminaire avec une F1, ça risque de poser un problème, on risque de puer la sueur ou d'arriver mouillé parcequ'il pleuvait sur le chemin.
 
Tout dépends de l'utilisation qu'on veut en faire.
 
mySQL sera par exemple totalement inadapté à des applis critiques (et non pas des données critiques, ou très fortement solicités, ça n'a rien à voir). Dans le domaine de la banque par exemple, mySQL est TOTALEMENT absent. Pourquoi ? Parcequ'il ne dispose d'aucun mécanisme de vérification des contraintes complexes, de transaction et d'optimisations de traîtements lourds.
 
Pour une base simple, à seul but de consultation (forum, moteur de recherche, CMS, etc.), mySQL est très bon, car il est à la fois rapide, et capable de gérer d'énormes volumes de données sans fléchir.
Par contre, pour gérer un ERP, des informations bancaires, ou simplement un outils de vente, mySQL est à proscrire fermement, car il est incapable de garantir qu'un montant débité sur un compte est crédité dans un autre, qu'une ligne de commande traîtée a bien été ventillées dans des lignes de colis, ou que le client a bien été créé avec une adresse de livraison.
 
On peut évidement contourner ces limitations de mySQL via des développement lourds, complexes, immaintenables au niveau applicatif, mais au bout d'un moment on ne peux pas tout garantir.
 
Je suis partisant de déporter les contrôles au niveau de l'applicatif, mais jusqu'à un certain niveau. Tout ce qui peut être fait en PS au sein de transactions notamment DOIT être fait via ce système. Les raisons sont trop nombreuses pour que je perde mon temps à toutes les détailler ici. Chacun d'entre nous qui a fait quelques cours de SI sait de quoi je parle.
 
Bref. mySQL n'est pas à proscrire des entreprises, mais pas non plus à prescrire à tout bout de champ. Je dirais même mieu, il est à éviter par défaut, et si, après étude, on s'apperçoit qu'il fait l'affaire, quelque-soient les évolutions envisagées, alors oui, on peut l'utiliser.
 
Personnellement, je préconnise MSDE qui est gratuit, parceque tournant sur plateforme Windows, et étant du même éditeur qu'Access, il est simple à mettre en place, les migrations simplifiée, et surtout, on n'a pas besoin de nouvelles compétences ni de nouveau matériel : MSDE peut très bien fonctionner sur n'importe quelle machine qui fait habituellement tourner Access.
Second gros avantage de MSDE, c'est que le jour où l'application évolute tellement que MSDE ne suffit plus (un bi-pro n'est plus capable de suivre les traîtements de plus en plus complexes, le nombre de connections dépasse les 25 par défaut, etc.) on peut migrer (oui, ça a un coût) vers SQL Server. Seulement, la migration de MSDE vers SQL Server coûte 0 €, même une secrétaire à qui on donne un post-it ratturé est capable de dupliquer une base MSDE sur un serveur SQL Server. Passer de mySQL à PostGre SQL par exemple, c'est une autre paire de manches. Même si ça ne demande pas de tout réécrire, une grande partie du code sera impactée, sans parler de la récupération des données, qui ne se fera pas en 3 clicks (nien trois lignes de commandes)
 
Deplus, la couverture fonctionnelle de MSDE est d'un niveau très proche d'Oracle, c'est à dire infiniement plus vaste que cette de mySQL. Pour cette raison, il y a 99% de chances qu'une appli évoluant, archtecturé autour de MSDE n'aie pas besoin de changer de SGBD, alors qu'une appli sur mySQL risque fortement de nécessiter un changement de SGBD très rapidement.
 
PS: ceci dit, il faut mieu utiliser mySQL qu'Access. Si ce n'est pas possible (pas de support des vues, fonctions, contraintes complexes, etc.) alors à ce moment, au lieu de rester cloîtrer avec Access, autant passer à MSDE, ou à un autre SGBD de couverture fonctionnelle proche de ce dernier (PostGre SQL pour ne pas le re-re-re-re-citer).

Me suis encore endormi sur mon clavier moi

Sinon, la légende comme quoi Windows et SQL Server c'est lourd, faudra penser à la mettre de côté JoWiLe. Moi je m'en mords encore les droit d'y avoir cru, et investi 20 KF à l'époque pour me faire un serveur béton... pour rien !
 
Voilà mon serveur perso :
Matos :
- Bi-pro Piii 933
- 2 Go de PC133
- 4 HD SCSI 10ktrm
 
Système:
- Windows 2003 Server Enterprise Edition
- SQL Server 2000 Enterprise Edition
 
Bordel:
- 5 sites ASP
- 3 bases de données, dont une (la seule qui soit vraiment solicitée en fait) fait plus de 2.5 Go
- Une série de Jobs tourne à des périodes très régulière et très sérées (certains -et c'est pas les moins lourds-) se lancent toutes les 5 minutes)
 
Je plafonne gentillement à 257 Mo d'occupé, alors que j'ai les outils d'administration de SQL Server ouverts ainsi que toute la panoplie Terminal Services, et à aucun moment je dépasse 30% d'utilisation des CPU.
 
Bref, pas de quoi fouetter un chat.
Pourtant, le site qui repose sur cette base de données (http://buzz.manga-torii.com) ne contient pas une traître ligne de SQL ni de traîtement. Tout se fait via des procédures stockées, des vues et des fonctions au niveau de SQL Server, donc c'est bien ce dernier, qui impacte la consommation de la machine (sauf pour la mémoire, IIS est un goinfre à cause de son cache).
 
Bref, vu le truc, je ne suis pas vraiment sûr que mySQL consomme beaucoup moins... En tout cas, la réputation de la lourdeur de SQL Server est particulièrement excessive. C'est pas Oracle, faut pas confondre
 

 
PS: pour ceux qui voudraient tester la montée en charge de ce serveur, merci de me prévenir avant, parceque j'ai comme qui dirait quelque traffic important sur ma ligne, et vous serez immédiatement bloqués pas ça...

T'as dis ske j'ai dis en 3 lignes en 100 quoi
Sinon si tu t'interresses aux sgbd jte conseille de matter du coté de firebird, extrement léger, rapide, et surtout qui supporte tous les raffinements de SQL
edit : et gratos et open source bien sur

Bof, moi je reste sur SQL Server et Oracle, qui sont les deux seuls sur lesquels je travaille régulièrement.
Dans ma boîte ils font aussi du mySQL, mais chais pas, j'accroche vraiment pas. Trop chiant et limité pour tout