Нет смысла вспоминать историю компьютеризации СССР с 90-х годов прошлого столетия. Есть смысл констатировать тот факт, что и по сей день на предприятиях требующих для управления мощных СУБД, серверов и надежных операционных систем, стоят "файл-серверные" сети из нескольких сотен персоналок, использующие DBF в качестве формата хранения данных, и эксплуатирующие миллионы строк кода разработанного на Clipper или FoxPro.

Альтернативой "файл-серверу" и, надо сказать, весьма заслуженно стал "клиент-сервер". Но, совершенно незаслуженно, недостатки "файл-серверной" архитектуры перекочевали на весь ее инструментарий:

• - язык xBASE,
• - формат DBF,
• - средства разработки Clipper, Clarion и FoxPro.

Как формат данных, язык или средства разработки могут влиять на скорость и надежность вычислений совершенно не понятно. Тем не менее, в рассуждениях о применении тех или иных средств в программировании систем связанных с обработкой баз данных, устойчиво сложился ряд мифов в отношении к DBF и xBASE, развенчать которые не помешало бы.

Миф 1. xBASE == DBF. Это скорее не миф, а заблуждение. Уже выросло целое поколение программистов, которое кроме SQL ничего не знает, а о DBF и xBASE сохранилось смутное воспоминание из курсов теории СУБД. Если рассматривать современные версии xBase - это давно уже не DBF, а и множество других форматов и источников данных, в том числе и SQL,OLE,XML,CORBA,..... Да и в те недалекие времена xBASE могли намного больше, чем просто управлять форматом DBF.

Миф 2. DBF - это медленно. Медленно работает сеть и компьютер клиента. Во времена возникновения этого мифа сервер с 486-м процессором и с 16-ю метрами памяти был совершенством, а arcnet'овские сети пропускали не более 200-300кб/с. И эта "мощь" должна обслуживать десятки пользователей прокачивая им до сотни мегабайт файлов и одновременно следить за блокировками записей, целостностью индексов и т.д.

Миф 3. DBF - это ненадежно и все время разрушаются файлы и индексы. Представьте себе что у вас в сети два десятка машин класса XT/AT "красной сборки", без UPS и заземления, напряжение в электросети скачет от 160 до 250 Вольт по прихоти ближайшего сварочного аппарата, DOS как ОС ничего не хочет делать для защиты информации, сетевые пакеты исчезают в кабеле как будто их и не было. Естественно, что любой сбой из перечисленных приводил к порче файлов, и не только DBF. И почему же этот миф применяют только для xBase? Потому, что чаще всего именно такие программы и выполняли (и выполняют до сих пор) огромное количество  работы. Раньше этот миф был выгоден производителям SQL-серверов для увеличения доли собственного рынка, а сейчас этот миф вспоминается как привычный шаблон.

Миф 4. xBASE устаревший язык. Увы и это не так. Развитие xBASE продолжается. Вместо бывших 3-4 продуктов сейчас имеется 8-10. Для всех ОС, типов пользовательского интерфейса, в свободном и коммерческом вариантах, с поддержкой объектного программирования, SQL-выражений, WEB-сервисами и использованием различных библиотек функций и много чего другого. Попробуйте назвать еще языки для которых растет количество компиляторов и библиотек. Их единицы и среди них xBASE.

Миф 5. xBASE не имеет визуальных (графических) средств и, в настоящее время, это не модно. Визуальные средства имеются, например, в CAVO и Visual FoxPro. И в других xBASE либо уже, есть либо разрабатываются. Может быть не такие мощные как в PowerBuilder, но имеются. Да собственно мощные средства и не нужны, потому-что основная работа программиста в xBASE заключается не в рисовании рюшечек и фенечек, а в том чтобы базы данных обеспечивали качественной информацией всех потребителей и пользователей. И многие задачи для этого не требуют визуальных средств, а скорее даже наоборот. Как простой пример можно привести факт, что хорошо построенный текстовый интерфейс на порядок эффективнее графического для определенного круга задач.

Миф 6. DBF это DOS. Далеко не так. DBF реализуется на ВСЕХ операционных системах, за исключением разве что ОС КПК.

Миф 7. В DBF легко "подсмотреть" данные. Угу, легко. Потому что формат DBF описан и имеются утилиты для просмотра содержимого файлов DBF. SQL-сервер также хранит данные в файлах, и содержимое этих файлов тоже можно посмотреть. Вся "секурность" этих файлов заключается в том что формат файлов НЕИЗВЕСТЕН. Но эти времена кажется уже проходят. Например MySQL основан на библиотеке управления таблицами и индексами innoDB, которую можно использовать для прямого просмотра содержимого данных в таблицах MySQL.

Все беды не от формата или языка, а от простой формулы надежности - "чем больше система имеет подсистем - тем она менее надежна". В файл-серверной конфигурации состояние файла зависит от всех компьютеров, ОС, питания, элементов сети. Поэтому любой сбой в любой части сети может привести к порче файла. Также неэффективно каждый раз доставлять файл на конечный компьютер только для того, чтобы посмотреть на часть этого файла. Это уже прошлый век программирования, но DBF и xBASE тут совсем не причем. С массовым внедрением архитектуры "клиент-сервер", началось активное развитие и продвижение средств разработки приложений для этой архитектуры. При этом, развитие таких средств как Clipper и Clarion было фактически прекращено в виду отсутствия коммерческой востребованности.

При всем достоинстве "клиент-сервер" не является таким уж абсолютом (см. "Блеск и нищета клиент-серверных технологий"). Да и дуализм "файл-сервер" - "клиент-сервер" не такой уж и дуализм. Все новое, это очень хорошо забытое старое. Поэтому обратим взоры лет на 30 назад и посмотрим на "модель" вычислений мейнфреймов. Центральная ЭВМ обслуживает все вычислительные процессы всех пользователей, подключенных к ней через терминалы. А общение через терминал подразумевает не обмен файлами ("файл-сервер") и не запросами-ответами ("клиент-сервер"), а передачей кода нажатых клавиш (или позиции курсора) на ЭВМ и получение "картинки" на экран дисплея. При чем картинка, как ни странно, может быть графической. То есть иметь все причитающиеся GUI прибамбасы: мышки, окошечки, менюшки и т.д. В такой "архитектуре", хоть кабель между терминалом и ЭВМ перережь - скрути концы и твоя картинка снова на экране. Но мейнфрейм+UNIX вчера, это сервер+Linux сегодня. При этом терминал может быть как сэмулирован на любой ПЭВМ, так и приобретен отдельно, по цене гораздо ниже персоналки. "Терминал-сервер" не остался в стороне и от пристального ока Microsoft. Правда повального перехода пользователей на "WindowTerminal" пока не наблюдается. Да и не будет скорее всего никогда, по той простой причине, что это не выгодно самой Microsoft. Кажется, при чем здесь DBF? А при том, что DBF и Clipper'ные приложения прекрасно работают в архитектуре "терминал-сервер". Как в режиме эмуляции DOS, так и прямой компиляции clipper'ных исходников на Linux. Заброшенный на произвол судьбы CA Сlipper был возрожден в таких проектах, как CLIP, Alaska и др. При этом, все DOS'овские ограничения для таких приложений (на размер и количество файлов, размер записи) снимаются. Добавьте к этому web, xml, gui, sql, ООП и все то, что появилось со времен мейнфрейм+UNIX и вы получите экономически эффективное средство для построения ИС высокой надежности и производительности.