Например, ЛИНТЕР.
Список поддерживаемых платформ ниже по тексту

PS Что Вы реализовать-то хотите?

olehRЛИНТЕР платний?
Платный .
Но если планируется тиражируемое ПО (не 4-5 установок), есть партнерская программа и стоимость лицензий тогда вполне себе небольшая.

pkarklinИ что за терминальчик? Гараздо меньше гимора, когда он работает терминальным клиентом к виндовому терминальному серваку, на котором запускается обычное Win32 приложение работающее, например, с "обычным" MS SQL. Как то так:
Это, я так понимаю, уже как бы тонкий клиент. А тут ситуация несколько другая

PS Кстати, а чего стоит такой сервер с допустим 100 подключенными терминалами?

pkarklin
rodenКстати, а чего стоит такой сервер с допустим 100 подключенными терминалами?

Интересует цена железа или цена клиентской лицензии служб терминалов (TS CAL)?
Приблизительная цена вопроса решения в целом.
Что бы сориентироваться есть ли существенная финансовая разница между подобными 2-мя решениями

olehRТаблицы будуть иметь размер не более 50 000 записей. Смотрю в сторону SQLite. Оперативки свободной всего 25 метров.
Но хотелось б расмотреть альтернативы
Если сам SQLite не пугает с его возможностями, то можно попробовать.

PS Не принимайте быстрых решений, потом это все ещё поддерживать.

pkarklinrodenПриблизительная цена вопроса решения в целом.
Что бы сориентироваться есть ли существенная финансовая разница между подобными 2-мя решениями

Какого решения?! 100 клиентских лицензий будут стоить по ~93 каждая. А железо надо будет подбирать исходя из софта, который будет на нем крутиться. Ищите Terminal Server Sizing Guide.
Это ж в $?
Тогда получается на 100 подключений это где-то 300 000 рублей
+ сервер эдак по-минимуму процессоров на 16 и с 32Гб ОЗУ - не уверен, но это где-то 500 000

ЗАТО (!) администрируется довольно легко и стоимость владения сравнительно небольшая


PS В случае с толстым клиентом посчитать сейчас тяжело, но сдается мне в сравнении с возможным геморроем в дальнейшем вполне конкурентное решение.

Спасибо!

AnyaNartova, каков размер ядра SQL Anywhere?
Сколько съест оперативки?

AnyaNartovaroden,

Это указано в приведенной мной ссылке
Написано-то написано.
Но это жестко фиксировано или как с обычными базами, она начнет есть столько, насколько её нагрузят?

Я объясню:
Например, у нас с ЛИНТЕР такая ситуация - ядро системы занимает 900кб, при этом вполне полноценный сервер - это уже порядка 6Мб (как и описано у Вас). При этом в ЛИНТЕР жестко фиксируется количество оперативной памяти, с которой он может работать, и ни копейкой больше.
Насколько я знал/считал до этого - такое поведение СУБД - это ноу-хау специалистов, разработавших ЛИНТЕР.
Вот и хочу понять насколько это реализовано в SQL Anywhere.

По ЛИНТЕР приблизительно так:
olehR1) Софт написан, но по ряду причин подрядчик не хочет развивать функционал.
Хранимые процедуры при написании использовались?
Если нет, то проблем с переходом на любую СУБД будет минимум

olehR2) речь идет о терминалах в количестве >150 , количество площадок >70 Многие площадки покрить Вайфай не так уж и просто. Там дешовим делинком не обойдешся, ибо нужен прозрачний переход между точками.

Исходя из объемов, Вы вполне попадаете под партнерскую программу ЛИНТЕР, соответственно стоимость будет соизмеримо маленькой в сравнении со стоимостью софта, который Вы делаете.

olehR3) Софт не сложний. (запроси тоже)

Значит подойдет любая реляционная СУБД.
Единственное на что стоит обратить внимание - SQL Lite. Нужно смотреть реализованы ли там подобные SQL запросы (пусть они и не сложные)

olehR4) Режим однопользовательский

Это значит, что аппаратные ресурсы будут расходоваться только на собственные задачи.
Тогда для ЛИНТЕР можно будет выделить часть ресурсов, конкретно прогнозируемую. Остальные ресурсы будет использовать сам софт.

olehR5) Во время работи синхронизация не происходит.
Может тогда будет полезен асинхронный режим?

olehR6) ЦБ у нас ORACLE 11G

Возможно будет интересным

olehRСейчас движок MS SQL CE но не всегда скорость устраивает. Ну и слишком много памяти жрет... Вот и задумалса об альтернативе.
Насчет скорости - любую СУБД надо тестировать в подобных условиях. Возможно на данной платформе ничего быстрее работать не будет, а возможно и большое увеличение производительности.
А вот что касается ресурсов (если это важно!) задуматься о переходе стоит.
В общем пробуйте. Осилит дорогу идущий :)