ИМХО если и нанимать разработчика, то надо чтобы исходники были предоставлены.
Но тут я вижу много проблемы: трудности взаимопонимания заказчика и исполнителя, период исправления ошибок, который может тянуться долго - за чей счет это будет делаться? Риск недостаточное компетентности исполнителя и риск срыва сроков проекта. Очень много рисков.
Чем проще задача по объему тем лучше ее сделать самим, хотя бы потому что ее будет проще сопровождать. А с точки зрения квалификации - это рост.
По инструменту - я бы смотрел в сторону WWW, это или php, или python и т.п. языки, библиотеки для доступа к DBF давно существуют. Нет смысла сейчас делать толстого клинтеа под винду, тем более простые приложения - больше доля проблем с поддержкой и совместимостью. Тем более DBF подразумевает файловый доступ скорее всего через сеть - это дополнительный источник проблем.
DBF в Foxpro имеет свои индексы, которые как правило плохо поддерживаются сторонними библиотеками, а без индексов что-то приличное по объему будет сделать сложно. При совместном использовании foxpro , то читать такую dbf базу со стороны безопасно только на чтение. Можно сделать некий демон на foxpro который будет писать в эту базу. Это гораздо безопаснее.
А самый эффективный вариант по возможности уходить с DBF на MySQL, полностью поменяв стек.
"Минусы программного: ниже производительность, выше сложность настройки"
Не соглашусь.
1. Производительность не ниже. Сейчас производительности современного CPU хватает работы для программного рейда. Этот тезис был оправдан для железа 90-х годов. Сейчас в этом нет смысла.
2. Настраивать софтовый рейд проще, т.к. он на любом железе одинаково работает. Полно инструкций и автоматизаций. Например, на нормальных ОС программный рейд можно настроить при инсталляции системы.
При этом аппаратный - это зоопарк терминов, вендоров и прошивок. Из ОС до него дотянуться сложно. Унификации нет.
это не очень верный ответ, т.к. неизвестно какие типы движков используются. если не используется MyISAM то нет смысла ему выделять память, и наоборот.
innodb-buffer-pool-size над делать под размер базы или чуть с запасом на вырост - цель чтобы mysql мог держать всю базу в памяти, если памяти больше чем размер базы.
если же размер базы значительно превышает размер ОЗУ то надо выделять памяти под завязку, за вычетом нужд системы и других процессов. Поэтому когда огульно выделяют половину ОЗУ - это странный подход.
250 коннектов тоже непонятно почему столько? каждый коннект жрет память под буфера, если реально максимум до десятка соединений то такой запас не нужен. А если выделить памяти больше, чем ее есть физически можно доиграться до OOM killer, уж лучше mysql прекратит принимать часть коннектов, чем его прибьют в разгар транзакции
Но тут я вижу много проблемы: трудности взаимопонимания заказчика и исполнителя, период исправления ошибок, который может тянуться долго - за чей счет это будет делаться? Риск недостаточное компетентности исполнителя и риск срыва сроков проекта. Очень много рисков.
Чем проще задача по объему тем лучше ее сделать самим, хотя бы потому что ее будет проще сопровождать. А с точки зрения квалификации - это рост.
По инструменту - я бы смотрел в сторону WWW, это или php, или python и т.п. языки, библиотеки для доступа к DBF давно существуют. Нет смысла сейчас делать толстого клинтеа под винду, тем более простые приложения - больше доля проблем с поддержкой и совместимостью. Тем более DBF подразумевает файловый доступ скорее всего через сеть - это дополнительный источник проблем.
DBF в Foxpro имеет свои индексы, которые как правило плохо поддерживаются сторонними библиотеками, а без индексов что-то приличное по объему будет сделать сложно. При совместном использовании foxpro , то читать такую dbf базу со стороны безопасно только на чтение. Можно сделать некий демон на foxpro который будет писать в эту базу. Это гораздо безопаснее.
А самый эффективный вариант по возможности уходить с DBF на MySQL, полностью поменяв стек.