Если речь идет о том, что СУБД будет крутиться на университетских ПК, тогда цель может быть только одна - не засорять основную ОС. Представь, ты сел, поставил себе СУБД на хостовую ОС, создал какую-то базу, забил пару таблиц информацией и т.д.
Первая причина - время инсталляции СУБД. Не знаю как для MS SQL, но, например, Oracle 10g ставится около 50 минут, что есть полпары. А процесс инсталяции особо ничем не примечателен, просто сидишь втыкаешь в процесс бар на экране...
Вторая причина.
ОК, поставил ты СУБД, начинаешь ты ее конфигурировать. Все упирается в рут-пароль, без которого, например, Oracle снести вообще нельзя(хотя могу ошибаться). Можно конечно условится, чтобы пасс был один, но кто-нибудь из больно "умных" студентов задаст свой пароль и потом надо будет над этим ПК оператору аудитории с бубном плясать пару часов либо искать кто ставил тот злосчастных пасс... А это все время, на которое учебная машина выпадает из учебного процесса.
Третья причина
Убил кто-то СУБД корявыми настройками. Сколько надо будет танцевать с бубном чтобы выпилить убитую СУБД с хостовой ОС? Зависит от того как убили, но ясно что на это время опять университетская машина из учебного процесса выпадает.
А теперь прикинь, что СУБД стоит под виртуалкой и есть где-то образ с конфигурацией по умолчанию. Развернуть виртуалку на основе готового образа - дело 5-10 минут. Снести виртуалку или заменить ее - опять же больших проблем не вызовет.
При этом, как было подмечено в выше, в настройках твоего приложения разница будет только в 1 строке - адрес сервера. Для локального localhost, для любого другого - ip-адрес
