LuckyLindy - Je vous encourage à vous arrêter un instant et à vérifier que vous n'avez pas besoin de l'agent SQL. Tu as écrit:
Nous sommes sur le point de déployer une double application transactionnelle web / interne où chaque client dispose de sa propre base de données. Chaque base de données est très petite - moins de 50 Mo chacune, donc nous nous demandions s'il serait judicieux d'utiliser SQL Express 2008 au lieu de SQL Server complet.
Quel est votre plan pour les sauvegardes? Vous n'avez pas besoin d'utiliser l'Agent SQL, mais cela rend la vie d'un DBA plus facile. Vous pouvez écrire des scripts T-SQL / SMO / PowerShell / quels que soient vos sauvegardes, puis les exécuter via sqlcmd ou PowerShell à l'aide d'une tâche planifiée.
Quel est votre plan pour la maintenance de la base de données? Au fil du temps, ces bases de données devront être défragmentées et leur cohérence vérifiée. L'édition standard a toutes sortes de goodies pour rendre cela facile alors que, dans Express, vous devez travailler (encore une fois avec les scripts et les tâches planifiées).
Comment serez-vous informé des problèmes sur le serveur? L'agent aide ici avec les alertes pour vous avertir lorsqu'un journal est plein, un disque se remplit, etc.
Il s'agit de tâches critiques de type DBA SQL Server. C'est une chose que d'exécuter Express pour une application interne, mais une fois que vous commencez à nous dire que vous les hébergez pour des clients, je m'inquiète :)
La partie 2 de ceci vous demande combien de clients vous comptez soutenir à ce sujet - à la fois au lancement et après un an? Si vous dites "100 clients", alors 100 bases de données de 50 Mo ne suffiront pas sur Express - vous n'avez tout simplement pas assez de mémoire. Heck - selon le delta que vous avez, vous pourriez avoir un maximum de 15 DB, je ne sais pas.
Nous n'aurons jamais plus de ~ 200 utilisateurs simultanés, et la plupart des opérations seront plus transactionnelles (ce qui semble favoriser beaucoup de disques à haute vitesse par rapport à la RAM / CPU lourde, non?)
Les opérations transactionnelles telles que les INSERT sont toujours écrites en mémoire, ne vous attendez donc pas à moins de prise en charge de la mémoire. En fait, selon le nombre d'insertions que vous effectuez, vous pourriez avoir des besoins en mémoire plus importants que la plupart avec ce nombre d'utilisateurs. Si vous chargez beaucoup de données que les gens n'utiliseront pas vraiment, cela occupe toujours de la mémoire. Vous pouvez rencontrer des problèmes de contention entre «les données que les utilisateurs interrogent fréquemment» et «les données que les utilisateurs chargent et que personne n'interrogera pendant un certain temps». SQL nous protège en préservant les données que les personnes interrogent plus fréquemment en mémoire plus longtemps, mais vous aurez toujours des conflits.
À ce stade, je divague lol. Et 200 utilisateurs simultanés ne jibe pas avec moi non plus pour Express. Disons que 64k est la mémoire moyenne requise pour la connexion, combien de connexions vos applications feront-elles? Allez-vous utiliser le pool de connexions?
Dans l'ensemble, mon intuition à la lecture de votre description dit: "Non - l'édition Express n'est tout simplement pas assez puissante." Et je déteste l'édition Workgroup - je pense que c'est une mauvaise affaire - donc Standard me semble juste.