MaestroEvКак правильно работать с соединением MySql?
1. Открывать соединение - брать данные - закрывать?
2. Открывать, работать с открытым и поднимать если упало?
Это зависит от многих причин.

Не вдаваясь в подробности - если много клиентов у сервера, то однозначно вариант 1 (со стороны разработчика).
Если нагрузка небольшая то можно использовать и вариант 2.

В реальной же жизни - всё зависит от драйвера который Вы используете для connection. И как правило это "смесь" открытых connections in the pool. Дело в том, что предоставление новых connection на стороне сервера довольно затратная операция.

В общем случае всё зависит от многих причин - скорости Вашего доступа к SQL Server, загруженности самого сервера etc...

Вопросы.
- Правильно ли я полагаю, что надо как-то закэшировать

* правильно, большинство "больших" программ так и работает.

- (перенести их во временную директорию фокса) все служебные таблицы (справочники) при первом обращении и уже работать с ними как раньше?

* в общем не правильно. Данные должны быть уже в памяти приложения. Создайте свой класс кэша в FoxPro - у него должно быть ограничено время, когда кэш устаревает и при новом обращении к массиву данных - происходит обновление с сервера. В MS SQL Server есть встроенная функция оповещения подписчиков если данные за которыми Вы следите - изменились.

** я бы посветовал Вам почитать как работает кэш в ASP.NET. Потом просто перенести архитектуру в VFP (там ничего сложного нет).

*** данные по доступу к отдельным сегментам приложения, не изменяемым справочники системы обычно хранятся в кэше with long expiration time.

**** если пользователь обновляет данные, которые кэшируются - обычно все данные или частично по дате обновления переписываются.

***** для небольших прложений можно использовать технологию replication in MS SQL server. При грамотном распределение данных между подписчиками вполне неплохо получается - в каждой локальной сети у Вас будет по своему SQL Server и соответсвенно с кэшами можно не "заморачиваться"... На клиентах бесплатные урезанные MS SQL сервера.

****** можно посмотреть в сторону MS Azure но я думаю что это пока ещё дороговато да и цены не снижаются...

Good luck!

MaestroEvСоответственно, если меню содержит 500 строк кода, и к каждому пункт есть DOSTUP из базы по ролям, то это уже 6 минут на запуск и торможение во время движения по секунде на каждой строке !

-- таблица с правами доступа как раз первый кандидат для кэширования. И тогда меню будут стриться из таблицы памяти быстрее чем в настоящий момент.

MaestroEvВ моем случае нет разницы сколько запрашиваю и из какой таблицы.. всегда это 0,8 и более.
Открыть соединение, взять данные, закрыть соединение.

-- к сожалению я не знаю архитектуры Вашей системы. Где у Вас SQL server? В локальной сети? Тогда 0.8с это очень много. Как Вам уже посоветовали выше - надо задать этот вопрос на тематическом MySQL форуме (я сейчас в основном работаю с Oracle и MS SQL Server). В общем скорость работы сервера зависит от:
- скорости сети и внутренней firewall
- железа на котором "крутится" MySQL server
- версия - коммерческая/не коммерческая
- клиентский драйвер (очень сильно зависит)
- сколько пользователей в сети

-- по большому счёту я бы отказался от MySQL а пользу MS SQL Server. Можно начать с официально бесплатной версии Express Edition (до 50 пользователей и при правильно архитектуре приложения более чем достаточно). Будет мало - можно купить следующую версию.

-- интересно, скольуко у Вас пользователей? Все они в одной локальной сети? Или есть филиалы?

-- в конфигурации с replication которую я описал выше у нас примерно 800 магазинов от Штатов да Малазии. В каждом магазине по express edition of the MS SQL Server. К этому серверу по локальной сети подключаются кассовые терминалы (до 24 штук в самом большом магазине в Лондонстане). В отведённое время сервер передаёт данные на центральный сервер. Данные сегментированы строго по тому товару, который есть в данном магазине etc... В общем всё просто и надёжно. Перебои в глобальной сети ни на что не влияют, всё работает очень быстро...

Справочников не мало.. Кэшировать в память? Ну допустим, а что явится сигналом, что кэш устарел? Время?

-- если честно, никто не кэширует информацию, с которой работают. Например, при выписке счёта запрашиваются "живые" остатки, одновременно блокируются чтобы кто-то другой не продал Ваш товар. После окончания выписки - база данных обновляется. Я не думаю что при работе с таблицами у Вас другая архитектура.

-- да, кэш устаревает по времени. У нас как правило три градации в зависимости от того, как меняются данные. Справочники подгружаются по мере потребности. При запросе загрузка идёт в кэш и потом уже Вы работает с данными из памяти. Устарели данные - ничего не происходит, пока они Вам снова не потребовались...

Или все же событие, что ест изменения в таблицах?

-- такое есть в MS SQL Server (в MySQL скорее всего нет) называется "SQL Server Notification Services". Почитайте. Мы их использовали немного лет 8 назад, но когда у тебя более 20000 запросов в секунду, этот сервис просто "убивал" наш MS SQL Server и мы отказались в пользу распределённого кэша который устаревает по времени. А Вам может быть и подойдёт.