Я вот недавно открыл для себя преимущества dbf-файлов перед другими форматами баз данных. Понятно, что речь идет не об абсолютных достоинствах, а относительно решения определенной задачи.

Задача была такая. Есть контрол списка данных (грид), поддерживающий виртуальный режим. Это может быть контрол на базе SysListView32, типа MFC-ешного CListCtrl либо виджет wxGrid из фреймворка wxWidgets либо соответствующий контрол из Qt или еще какой-нибудь. Также имеется конкретный файл базы данных с большим количеством записей, например, порядка сотни миллионов. Нужно организовать подкачку данных (через обработчики виртуального режима) из файла БД в виртуальную таблицу. Т.е. когда обработчик просит нас предоставить ему i-тую запись из файла БД мы должны быстренько получить ее из локальной файловой таблицы и передать обработчику.

Нам требуется обеспечить удобную и быструю интерфейсную навигацию по виртуальной таблице, чтобы она отображала нужную нам страницу записей. Действия там такие: переход в начало таблицы данных (Ctrl+Home), в конец (Ctrl+End), перемещения стрелками вверх / вниз на одну запись вверх / вниз, перемещения клавишами PageUp / PageDown на одну страницу записей вверх / вниз, перемещение ползунка вертикального скролбара с помощью мыши в произвольное место, так, чтобы при этом данные в таблице плавно, легко и быстро изменялись.

Главная проблема здесь, как организовать быстрый доступ к данным файловой таблицы. В общем случае нам надо проиндексировать файл (для быстрой выборки произвольного блока данных), иметь средства некоторой СУБД, с помощью которой считывать определенные порции данных в буфер, из которого уже и возвращать обработчикам виртуального режима запрашиваемые ими записи. Все это достаточно муторно, если делать самому.

Однако если работать непосредственно с dbf-файлами, то ситуация сильно упрощается. Если у нас имеется огромный dbf-файл который мы хотим отображать в собственном клиенте, то виртуальную навигацию по нему организовать очень просто. Достаточно отобразить файл в память и получить к нему произвольный доступ по технологии MMF (Memory-Mapped Files). А поскольку dbf-файл имеет простую табличную структуру, то вычислить адрес начала его произвольной записи проще простого. В свое время я писал подобные тестовые программы, правда, не задумываясь о достоинствах открытой и простой структуры dbf-файлов. Там представлены dbf-файлы небольшого размера, но для больших принцип собственной навигации останется тот же. Просто в то время на этот момент я не обращал внимания. Вот ссылки: Создание и проецирование в память существующих DBF файлов. . . и Рабочий алгоритм на С++ внешней сортировки «естественным слиянием». . .

Почему создана данная тема? Просто сейчас происходит забвение Visual FoxPro и многие вынуждены оставлять эту систему и переходить, кто на 1С, кто на MS Access или SQL Server. Однако движок VFP очень хорош, очень лёгкий и мощный, лучше, чем, скажем, у опенсорсных Harbour / xHarbour, xBase и др., чего не скажешь о его интерфейсных возможностях. Зато средства создания интерфейса сейчас достаточно развиты в других системах разработки (те же wxWidgets и Qt). Поэтому, как вариант, можно писать собственный интерфейс на одной системе, а выборку данных осуществлять из другой, в данном случае VFP. Причем для случая навигации по виртуальной таблице больших dbf¬-файлов нам даже не нужно, в принципе, использовать движок VFP, что сильно упрощает программирование. А использовать VFP только для выборки данных и других специфических задач СУБД. При этом обмен данными внешнего интерфейса с VFP можно осуществлять различными способами. Это, во-первых, DDE (у меня по этой технологии организован расчет зарплаты во внешнем приложении VFP использующем базу данных 1С77 и отправка запросов от VFP к 1С как DDE-серверу), во-вторых, использование VFP как COM / OLE сервера ( Работа с dbf ), в третьих, через dbf-файлы, в-четвертых, через каналы связи организованных в VFP, таких как анонимные и именованные каналы, разделенная память, «почтовые ящики» и т.п. стандартные средства межпроцессного взаимодействия Windows, к которым можно получить доступ из VFP. Я думаю, что здесь перечислены не все возможности, есть еще хакерские методы, которые мы рассматривать не будем.

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

Что удивительно, первая ссылка продемонстрировала преимущества спроецированных в память dbf-файлов при отображении их в виртуальный список еще семь лет назад. Но понял я это только сейчас. Для этого нужно просто увеличить размер используемых там файлов до сотен тысяч и даже миллиона записей (хотя бы тупым самокопированием). Скорость навигации по этим файлам практически не изменится. А попробуйте покрутить файлы таких размеров в 1С77. Замечу, что в данном случае контрол SysListView32 имеет встроенные ограничения на 100 миллионов записей. Я протестировал случай: три файла размерами по 250 МБ, с количеством записей более 3 миллионов, каждый. Навигация летает что дурная. Можно при желании попытаться выйти на физический предел 2 Гб для каждого dbf-файла либо 100 миллионов записей, смотря чего вы достигните быстрее.

бухалтер фантоцциИногда охота матом покрыть всем известную корпорацию, но мир не совершенен... продолжаем двигаться вперёд.
К сожалению, главное для них коммерческий результат, а не технический. Однако я надеюсь, что еще в этом веке мы доживем хотя бы до цифрового коммунизма.

бухалтер фантоцциНадеюсь на чудо, что аналог фоксовского движка появится в виде кросс-платформенного приложения с поддержкой UTF-8,
и чтобы интерфейс был возможен в других приложениях через API...
Мечты, мечты...
Сейчас можно пока просто конвертировать из одной кодировки в другую:



и обратно



А насчет кроссплатформенности логично использовать (x)Harbour. Там даже возможна работа под x64. Хотя он не может быть полноценной заменой VFP.

Владимир2012EmeryЯ вот недавно открыл для себя преимущества dbf-файлов перед другими форматами баз данных.Судя по множеству ваших топиков относительно использования dfbf, cdx, ... вы много времени уже
потратили на исследование cdx ...
На мой взгляд вы тратите время попусту.
Ценю вашу заботу о моем свободном времени.

Как раз на cdx я потратил мало времени. Есть на этом форуме мои записи 2009 года, с тех пор я к этой теме не возвращался. У меня, правда, имеются закрытые исходники, где реализована технология построения и использования компаундных индексов, но я ими пока еще всерьез не занимался. Просто не было необходимости.

Владимир2012Почему?
Не сложно найти ссылки на десяток библиотек для работы с dbf и несколько с cdx.
Теоретически можно эти библиотеки использовать, а практически будет просто потеря времени.
Например в xharbour-1.2.1.src.tar.gz содержит исходники для работы с cdx.
Но скорее всего не просто будет на их основе создать свою библиотеку для работы с cdx.
Времени потеряете много.
harbour-3.0.0-src тоже содержит исходники для работы с cdx, fpt и т.п. Про имеющиеся у меня закрытые исходники одного проекта я уже говорил. Насчет времени не переживайте, это моя область интересов как хобби, поэтому как минимум получу удовольствие.

Владимир2012Для меня например проще с нуля разработать свою библиотеку.
Да и времени займет не так то много.
В начале 90-х, когда еще интернета то не было и исходников для работы с dbf и idx мне понадобилось
всего лишь недели две для написания библиотеки, обеспечивающей работу с dbf и idx файлами.
И знаете ни чего в этом сложного нет.
Вполне вам верю. Dbf это простая таблица, я даже к ним собственную сортировку применял. А cdx это бинарное дерево плюс двухсвязный список – известные классические объекты. Нюансы только на уровне спецификаций формата данных. Если строить cdx для себя, не пытаясь их делать 100%-но совместимыми с форматом VFP, то проблем особых как бы не возникает. А если стремиться к совместимости (сразу вопрос, зачем?), то возникают вопросы из-за недоступности официальной спецификации. Кстати, официального описания формата нет и на dbf, все что есть, это просто «вычисленный» народом формат.

Владимир2012Но имеется одна большая сложность.

Какая?

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

Вот и сейчас, поскольку активность на этом форуме была низкой, я продублировал тему на мисте . Критика конечно присутствует, но критики бояться, на форумы не ходить.

Владимир2012Почитал также о ваших попытках использования vfp dll.
Конечно любопытно, что вы уже научились их как-то использовать.
Но это пожалуй и все.

PS: А если кратко.
Не теряйте попусту время.
Недели за две разработаете библиотеку для работы с dbf и cdx.
Вы знаете, для меня проблема не dbf, cdx. Вопросом был, как правильно организовать межпроцессное взаимодействие. Почитал книги. Узнал, что есть DDE, COM, OLE, MMF, анонимные и именованные каналы, почтовые ящики и т.п. Однако многие из этих вещей я уже давно использовал и все это можно применять в т.ч. и к VFP. Я еще много лет назад знал, что рантаймная версия VFP это нестандартный COM сервер, поэтому в этом ключе с ним никто не может толком работать. Можно либо использовать OLE-версию VFP (vfp9.exe) либо применять хакерские методы к vfp9xxx.dll. Пока это просто интересно, а что из этого будет, посмотрим.

Владимир2012К великому моему сожалению похоже через некоторое время мне придется написать api для работы с cdx
/не спрашивайте для каких целей .... Все равно не отвечу. Да и флудить на эти темы не буду/.
Хорошо, напишите, а дальше, что? API это только пол дела. Можете не отвечать по существу, просто скажите, уверены, что справитесь со второй половиной дела?

Владимир2012File Structures https://msdn.microsoft.com/en-us/library/d863bcf2(v=vs.80).aspx
О! Это полезная ссылка. Спасибо!

Dima TEmeryМожно либо использовать OLE-версию VFP (vfp9.exe)
vfp9.exe - это IDE, среда разработки.
Не только. Если вы запустите его с параметром:



то никакой ИДЕ не будет, а будет зарегистрированный ОЛЕ-сервер.

Dima TИспользование vfp9.exe разрешено там куда он купленный поставлен.
vfp9*.dll - это рантайм, распространяется бесплатно.
Пользователю совершенно не обязательно поставлять лицензионный VFP. Где он его возьмет, его проблемы.
А к рантайму у нас особый интерес.

Dima TВ остальном не понял зачем такой сложный велосипед нужен? Зачем мапить именно dbf? Кстати из фокса прямой доступ к памяти не возможен.
Хотя по сути на подобных принципах фокс и работает: если открыть dbf монопольно, то происходит кэширование в памяти и за счет этого значительное ускорение.
Из фокса много чего можно сделать. Он имеет доступ к WinAPI, а это уже означает многое. Он может работать с Си, поддерживать собственные dll-ки (с расширением fll) и много чего еще. Проще вести речь, а чего он не может?

А мапить dbf понятно, почему. С другими форматами работать труднее.

Все что делается кому-то да нужно. Есть класс задач, для которых не хочется привлекать «тяжелые» или платные средства. Иногда достаточно чего-нибудь попроще, поэтому и идет речь о возможностях dbf для этих целей.

Sergey ChСегодня физическая память очень дешёвая.
Ну, не везде. У нас она почти недоступная. Мы живем в ЛНР, поэтому после войны (а на границах она продолжается до сих пор) уровень жизни и экономики сильно просел, поэтому живем только тем, что имелось ранее. Хотя раньше да, была дешевая. Дома у меня, например, 16 ГБ памяти, гораздо больше, чем на работе. Однако сказать, что это упрощает использование тяжелых приложений, я бы не стал.

Sergey ChБесплатный "штатный" framework .NET довольно хорошо работает с большими массивами данных в памяти, причём очень быстро.
В самом .NET очень просто реализуется быстрая "загрузка" данных без блокирования UI в нескольких параллельных процессах...
Я видел начало процесса, когда раскручивали .Net Framework. Это было нечто с чем-то. В итоге, как оказалось, гора родила мышь. Все .Net приложения очень тяжелые и тормознутые. Ява и то предпочтительней выглядит. Пример, DebetPlюс12, система учета в стиле 1С77, написана на Яве. Размер около ГБ. А вот система Medoc, написанная на .Net Framework'e весит более 2 ГБ монстр еще тот. Мы на нем сдавали отчетность в Украину. Работать можно, но очень неудобно. Удивляет то, что нет нормальной работы с таблицами данных, что, по идее, должно быть встроено в этот фрэймворк изначально. Можно сколько угодно хаять «криворуких» программистов, но от того что сам фундамент не очень, никуда не деться. А этому нетовскому Медку по функционалу до явовского ДебетПлюс как до Киева пешком. Да и бесплатной базы данных у .Net Framework'а нет, в Медке используется Firebird, что только увеличивает тормоза еще более.

Однако и Ява меня не очень привлекает, ну, не люблю я самопальные приложения размером под гектар и более. Предоставляю это садомазо другим. А мне вполне достаточно легких приложений.

Dima Tфокс очень медленно работает со строками. Есть несколько парсеров больших файлов, переписал их на шарпе - стало работать в десятки раз быстрее.
Строки это не актуально, если используешь внешний интерфейс. В Qt есть прекрасные QString, в wxWidgets – wxString. От VFP надо по большому счету работа с индексами и оператор select sql, ну и все, что с этим связано.

Есть хороший сайт codeproject.com. Так вот все тамошние примеры на шарпе я всегда старался переписать на С++. Но спорить не буду, все это на любителя.

Dima TПока присматриваюсь к C# как к замене C/C++. Писать на C# гораздо проще чем на C/C++. По производительности C# не сильно уступает C/C++.
На чистом C/C++ сейчас мало кто пишет. Есть масса фреймворков, которые облегчают жизнь. Помимо Qt, wxWidgets есть еще boost и много чего еще. Как бы потребности менять С++ на что-то подобное у меня лично не возникает. Тем более это все это может быть кроссплатформенным, если задействовать компилятор minGW. Но если понадобиться аналог C#, то тогда уж лучше Java, JScript, hta и т.п.

Dima TEmeryДа и бесплатной базы данных у .Net Framework'а нет
Есть бесплатный MSSQL Express (с ограничением 10 Гб на одну базу). Никто не запрещает любой другой SQL-сервер использовать. Альтернатива локальной БД - Sqlite. Не пользовался, читал немного обзоры. По сути Sqlite это то что ты собираешься сделать из фокса. Может тебе лучше сначала в эту сторону поизучать?
В Qt sqlite и sqlite2 поддерживаются по умолчанию. Еще он поддерживает db2, ibase, mysql, oci, odbc, psql, tds. Через ODBC можно подключаться к MS SQL Server, Oracle и т.п. Замечу, что в последних версиях Явы и Виджетов убрали поддержку ODBC, мол, это типа устаревшая технология. У меня же есть пример на Qt для работы с dbf через "VisualFoxPro.Application.9". ( http://www.sql.ru/forum/actualfile.aspx?id=15291607 Файл dbf можно взять отсюда http://www.sql.ru/forum/actualfile.aspx?id=15291616 Если будете использовать бинарник, то подключите его к библиотекам Qt ).

Про другие бесплатные СУБД я знаю, если возникнет необходимость именно в них, то воспользуемся без проблем.

Sergey ChMicrosoft уже дал нам своё предложение - VB.NET/C# Visual Studio, MS SQL Server (SSIS, SSRS). Всё это даётся нам бесплатно и легально.
Как по мне, то более адекватной заменой VFP является MS Access. Как и в VFP здесь есть собственная база, к тому же защищенная, собственный язык, доступ к WinAPI, поддержка классов, программирование собственного интерфейса, в т.ч. системы отчетов, возможность подключения к SQL серверу (платному или бесплатному) и другим СУБД. Производительность и параметры работы у них сопоставимы. Плюс переход MS Office на 64-х разрядный движок.

Согласен, что можно вместо MS Access использовать VB.NET или Visual Studio (не обязательно C#). Только это все равно не отменяет VFP. Чем хорош VFP, так это своей эффективностью на уровне ядра, легкостью и переносимостью, скопировал на другую машину несколько файлов, общим объемом в несколько мегабайт и вперед за работу. Для собственного программирования легких клиентов, VFP практически идеален, вот только внутрипроцессную поддержку для рантаймовских библиотек организовать проблематично, поскольку они представляют из себя нестандартный COM-сервер. Хотя организовать межпроцессную связь можно без особых проблем.

Sergey Chкоманда разработчиков FoxPro всё лучшее из последнего уже давно перенесла в .NET...
Ну да, если не считать запредельные объемы общего кода в .NET.

Sergey ChХотя мы все имеем свои пути решения бизнес-задач
Вот именно, здесь речь идет о легких и сверхлегких клиентах. На сверхлегких можно даже вообще обойтись без сторонних СУБД, если организовать собственную индексацию и сортировку, что не является особой проблемой.

Dima TТут я не понимаю что мешает пойти классическим путем, т.е. просто написать клиента на фоксе целиком?
Мне никогда не нравились интерфейсные возможности в FoxPro. Ни в MS DOS'e, ни в Windows. Насколько хорош движок у FP и VFP, настолько плох у них программируемый интерфейс. В Досе вообще нельзя было вывести более 5-6 окон на экран, сразу сказывалась нехватка памяти, а в Виндоусе в принципе можно работать, но удовольствия нет никакого. Вон Парус попытался, но получилось у него не очень.

Sergey ChВы будете удивлены, но ядро архитектуры .NET построено по тому-же принципу что и run time environment FoxPro. Там есть такой-же intermediary language который понимает только среда исполнения. Но в .NET MS пошёл дальше добваив много нового. Начиная с последних версий у .NET есть только клиентская часть (как и FoxPro runtime), достаточная для запуска Ваших приложений и она весьма небольшая. Ещё есть compact version для "маленьких устройств" типа mobile phone (даже есть compact SQL server). Microsoft отвечает на наши вопросы и проблемы.
Будет лучше, если вы назовете десктопную программу, клиента БД, написанную на .NET и ее объем инсталяции. А мы уже протестируем ее на предмет удобства и скорости работы.

Sergey ChУ Вас временнве проблемы с железом, но оно постоянно дешевеет и становится всё более производительным...
Да нет, железо у меня хорошее, пока не жалуюсь. Просто я не люблю относительно простые и малоудобные программы размером под гектар и более.