Ну в принципе, вам идеально подойдет SAP SQL Anywhere (в девичестве Sybase Adaptive Server Anywhere). Но оно платное. Зато все восемь хотелок удовлетворяет.


А пункт 4 - вам сильно стоит пересмотреть свою архитектуру. Удалять (да и добавлять) столбцы можно только при глобальном апдейте приложения. А в нормальной работе намного проще просто игнорировать не нужные столбцы. Да EAV модель намного удобнее чем игры со столбцами.

Драйвера ODBC устанавливать не обязательно. Достаточно просто скопировать все нужные dll. Конечно, в этом случае не получится использовать odbcad32.exe и создавать DSN, но всегда можно передавать имя dll файла в строку коннекта. Хотя по слухам это работает не всегда, но на Вин-7, с ODBC v3.5 у меня работало.

Но никакой админ не может запретить ручное добавление записей в пользовательскую часть регистри - а этого достаточно чтобы получить пользовательские DSN.

Да и вообще, боятся админов - ничего не делать. А если проект боевой, то объяснить начальству что надо что-там установить чтобы работало - очень просто. А уж начальство админов убедить сумеет. Тем более, всего-то надо ставить odbc драйвера для выбранной RDBMS.

Ну может начальство и право?
Если ты не можешь объяснить начальству как твоя база облегчит жизнь бизнесу, то эта база действительно не нужна.
А если надо базу данных прятать от начальства это уже никак не боевая задача. Смотри определение "боевых задач".

Если ты действительно веришь что твой проект будет полезен - ну сделай пилотный запуск на одного-двух человек. Покажи начальству что "вот как круто стало". Поможет с убеждениями. А там уже и само начальство начнет изыскивать средства на поддержку и проталкивать инсталляцию всего что нужно.


Обычно, задачу описанную в твоем первом посте решают когда надо ставить базу туда, где нету своих админов. Там есть юзверя, но нет ни одного самого завялящего эникейщика. Вот тогда и ищут БД с минимумом требований к инсталляции и дальнейшей поддержке. Варианты тебе уже накидали.

Учитывая, что речь идёт о C#, упоминание ODBC показывает всего лишь неопытность
топикстартера и невладение инструментом.
Ну это не обязательно.
Многие RDBMS (особенно старые версии) просто не имеют ADO.Net в своем составе, а вот ODBC есть почти всегда. И мосты уже отлажены давно. Так что не вижу большого криминала в использовании System.Data.Odbc вместо System.Data.

Хранить большие файлы отдельно БД это вообще всегда хорошо и правильно. Это относится к любой СУБД.

Главным фактором тут является именно размер файла. Если мы пихаем блоб в БД - файл БД раздувается. В конечном итоге, мы можем раздуть файл БД, до размеров которые с точки зрения ОС - слишком большие для одного файла.
Сегодня это конечно не так важно, теоретический максимум на ext4 и ntfs - исчисляется в экзобайтах (10е+18). Но там вмешиваются еще и размеры параметров в функциях ОС, размеры раздела, размеры самого диска в конце-концов.
В общем на Линуксе по последним сведениям ограничение файла в 16 террабайт, в Винде-10 это задрали до 8 петабайт.
Ограничение, конечно, труднодостижимое, но есть.
Так что разбить данные на много файлов - одна БД и куча внешних блобов - и мы обошли ограничение размеров. Можно писать все экзабайты данных. Если HDD хватит :)

Но кроме размеров, есть еще и скорость. БД имеет в себе кучу индеректов и добраться до всех страниц где лежат куски блоба получается намного медленнее, чем до сегментов диска. А если еще учесть что страницы БД сами лежат где-то в сегментах диска...
У SQLite есть забавное исследование этого вопроса: https://www.sqlite.org/intern-v-extern-blob.html
Думаю что если поискать и для других СУБД можно найти подобное. Да и самому провести можно.