SQL Server FTS sera plus facile à gérer pour un petit déploiement. Étant donné que FTS est intégré à la base de données, le RDBMS gère automatiquement la mise à jour de l'index. L'inconvénient ici est que vous n'avez pas de solution de mise à l'échelle évidente à moins de répliquer les bases de données. Donc, si vous n'avez pas besoin d'évoluer, SQL Server FTS est probablement "plus sûr". Politiquement, la plupart des magasins seront plus à l'aise avec une solution purement SQL Server.
Du côté de Lucene, je préférerais SOLR à Lucene. Avec l'une ou l'autre solution, vous devez faire plus de travail vous-même en mettant à jour l'index lorsque les données changent, ainsi qu'en mappant vous-même les données à l'index SOLR/Lucene. Les avantages sont que vous pouvez facilement évoluer en ajoutant des index supplémentaires. Vous pouvez exécuter ces index sur des serveurs Linux très légers, ce qui élimine certains coûts de licence. Si vous empruntez la route Lucene/SOLR, mon objectif serait de mettre TOUTES les données dont vous avez besoin directement dans l'index, plutôt que de remettre des pointeurs vers la base de données dans l'index. Vous pouvez inclure des données dans l'index qui ne sont pas interrogeables, par exemple vous pouvez avoir du code HTML ou XML pré-construit stocké dans l'index et le servir comme résultat de recherche. Avec cette approche, votre base de données peut être en panne, mais vous êtes toujours en mesure de fournir des résultats de recherche en mode déconnecté.
Je n'ai jamais vu de comparaison de performances directe entre SQL Server 2008 et Lucene, mais j'aimerais en voir une.
