В этой заметке мы обсудим преимущества и недостатки Visual FoxPro.
Как известно, система старая, в FoxPro прослеживается еще ваткомовское наследие.
Осмелюсь утверждать, что лучшей версией была и остается FoxPro 2.6
для MS-DOS. Я ее по случаю изучил весьма подробно (пожалуй, все
остальное, чем приходилось пользоваться, так глубоко не копал), вплоть
до написания сишных библиотек с ассемблерными вставками (для изменения
палитры монитора, хи-хи). Изучал бы и далее - на уровне модификации
работы встроенных функций FPD - да другим занялся. Используя
расширенную память, FoxPro под DOS работала очень быстро и переваривала
сравнительно большие объемы данных. Это был пример эффективнейшего и
адекватного сочетания железа и программного обеспечения.
Коробка VFP
Следует также отдать должное пятой и шестой версиям Visual FoxPro
(третья была довольно-таки ненадежной). Но, по большому счету, Visual
FoxPro явил собой современный конструктор интерфейса, не более того.
Фанаты VFP могут долго обсасывать изменения, происходившие с этим
“чахликом невмирущим” от версии к версии. Нам это совершенно
неинтересно. Почему - будет ясно далее по тексту. Я могу путать версии
и ошибаться в деталях. Это не страшно. Я также не могу решить, какого
рода самоё название FoxPro. Это тем более неважно.
Анализ будем вести в трех аспектах:
СУБД и особенности SQL-транслятора (диалектом его называть язык не поворачивается)
IDE и визуальный конструктор классов интерфейса (в смысле, GUI)
Некогда БД ФоксПро представляла собой просто набор DBF-файлов (однако с особенным идентификатором в заголовке). И это было хорошо.
Затем в базу добавили словарь данных (файл DBC).
Это было бы хорошо, если бы он меньше глючил. Я призываю не
использовать DBC-файл ни для чего! Реализуйте все необходимые функции в
собственных подпрограммах.
Впрочем, одно применение у файла DBC есть. Если в него забить
подробные комментарии к полям и таблицам базы данных, то затем,
открывая словарь как обычную таблицу DBF, легко написать на том же
самом foxpro программку, вываливающую куда-либо полное описание базы данных. Я сделал такой экспорт в HTML. Очень удобно.
В фокспро есть какие-то ограничения на размер таблиц, я их не помню.
Люди хранили в DBF просто-таки огромные объемы данных. Я считаю, что
начиная с таблиц в десятки тысяч записей, следует задумываться о
переходе на клиент-серверные технологии. Хотя сотни тысяч записей для
FoxPro как СУБД далеко не предел, начинает играть роль ненадежность самой файл-серверной концепции БД. Просто попробуйте поработать с любым SQL-сервером, и мне ничего не придется объяснять.
Собственно SQL-язык запросов в VFP довольно-таки беден, но все
основные команды в нем имеются. Нет подзапросов, и очень странно СУБД
ФоксПро работает с такой хитрой сущностью, как NULL. Поэтому и диалект
SQL с ней работает так же странно.
Если VFP работает с “внешним” сервером и получает результаты
запросов через ODBC, то место хранения данных непредсказуемо. Это может
быть область памяти или даже файл на диске. Соответственно, все
недостатки работы с собственной базой проявятся и здесь. Но, с другой
стороны, автоматизированное получение данных в формируемый внтури VFP
курсор (не тот курсор… собственное трактование этого понятия в VFP) -
это очень полезно с точки зрения экономии времени и трудозатрат на
разбор выдаваемых сервером данных.
Я (думаю, что обоснованно) считаю, что разнообразные прокладки между
FoxPro и SQL-серверами - зло. Мирясь с получением курсоров через ODBC,
запросы на сервер следует отправлять только напрямую.
Это тем более важно, потому что я рекомендую использовать для клиент-серверных систем на основе Visual FoxPro в первую очередь MySQL и PostgreSQL, но никак не SQL-сервер от Microsoft (а иные покупать нет смысла тем более).
Про фокспрошные контролы и классы, работу с системами
контроля версий и конкретными SQL-серверами я выскажусь в следующий
раз. Следите за анонсами, подписывайтесь!