MasterZivТогда я совсем ничего не понимаю.
Что ж тут непонятного? Зачем платить за чужие библиотеки, если без них вполне можно обойтись в своих программах? Если уж нельзя, тогда другое дело придется покупать.

MasterZivНет, не читал.
Почитайте, если будет желание и время. «MFC-04. MMF чтение и создание DBF файлов вместо сериализации для виртуальных списков»
В пятой статье логично для своих программ обеспечить поддержку индексов, В формате VFP потому, что так удобней. В шестой статье будет идти речь о непосредственном подключении и работе с vfp9r.dll / vfp9renu.dll . Затем, может быть, для примера будут взяты безплатные движки БД. Однако, я хочу чтобы моя программа работала как с движками БД, так и без них.

MasterZivА зачем создавать свои собственные индексы, тем более в FoxPro, где
есть и SQL, и не SQL ?
Чтобы иметь возможность юзверю не платить за библиотеки Visual FoxPro (или чтобы мне не требовалось обязательно дистрибутировать их, так как за это нужно платить денежку). Но ежели у пользователя уже есть такие библиотеки (при желании их можно найти в интернете), но он сможет спокойно подключиться к ним и работать на полную катушку. Другое дело, если такая дистрибуция будет окупать себя. Тогда можно будет подумать и об этом. Что касается безплатных библиотек БД, то с ними я пока слабо знаком, но не думаю, что они сильно лучше библиотек VFP (проще говоря, до них еще не дошли руки).

MasterZivИндексы очень сложно сделать лучше, чем они уже сделаны. И там особых
частностей нет. Всё универсальное, и всё одинаковое.
У VFP очень хорошая производительность в их создании, ну просто очень хорошая. Если мне удастся достичь хотя бы 80% это будет очень большой успех для меня. Насчет универсальности не очень согласен. В создании CDX файлов есть много специфики, может быть даже запатентованной, Майкрософт. Кое о чем я веду речь в «Алгоритм создания CDX файлов» . Сейчас я читаю статьи Гоца Грейфа из Майкрософт . Хочу выяснить для себя следующую проблему.

Майкрософт умудряется сохранять физический порядок в индексном файле при разовой вставке / модификации записи без его явного физического переупорядочивания . Если бы внутри файловые указатели CDX файла были бы относительными, а не абсолютными, то этого можно было бы достичь путем вставки нужного сегмента данных в файловый связный список на уровне операционной системы и корректировкой нескольких связей на логическом уровне. Для нас это выглядело бы практически мгновенным (как оно и есть на самом деле). Однако абсолютные внутри файловые смещения в указателях меняют дело. Может быть каким-то образом операционная система может автоматически регулировать эти указатели?

Тот же Гоц Грэйф пишет, что

«Чтобы избежать последующего обновления соседних страниц, традиционная цепочка страниц с использованием физических идентификаторов страниц заменяется логической цепочкой страниц с использованием разделительных ключей (separator key) , т.е. каждая страница несет в качестве нижнего и верхнего барьеров разделительный ключ, копируемый в страницу родительского узла при отщеплении страницы от ее соседей. В дополнение к поддержке тех же проверок согласованности и других технических операций, что и те, которые поддерживаются традиционными физическими цепочками страниц, барьерные ключи упрощают и улучшают блокировку диапазонов значений ключа, поскольку никогда не требуется перемещаться к соседней листовой странице для нахождения правого значения ключа в диапазоне. После замены физических цепочек страниц логическими барьерными ключами физические идентификаторы страниц остаются только в указателях детей, и только их требуется изменять при перемещении узла на новое место на диске .»

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

MasterZivДа ёлы-палы, если вам нужны алгоритмы и структуры для индексирования,
то это не проблема. Литературы по этому делу навалом.
С теоретическими алгоритмами я знаком, но они не могут объяснить физический порядок индексов в CDX файле, наряду с логическим. Там нигде не идет речь об упаковке данных в индексных листьях также. Так что литературы валом, а практического толку мало. Тот же Алексей Долгачев , который написал библиотеку для работы с dbf / cdx файлами работает только с чужими индексами и не создает собственных. Поэтому и достижений у него немного, собственный грид (который все равно не лучше CListCtrl, особенно для виртуального режима) и утилиты просмотра / редактирования dbf файлов. Стоило ли вообще огород городить?

MasterZivЭто какое такое ноу-хау ?
Ваши слова:
MasterZivВ смысле, я-то знаю, почему может быть быстрее, но ты, видимо, нет.

miksoftУже такой длинный топик, а слово Рашмор еще не прозвучало
Посмотри ссылку на «Алгоритм создания CDX файлов» чуть выше. Так это слово встречается трижды.

АСУ ТПшникможно вопрос? а на кой лад нужны альтернативы sql запросам? вот честно? у нас рынок раздулся и программисты не знают как быстрее избавиться от печатания select * from MYSUPERPUPERTOTALTABLE? :)
Вот цитирую самого себя с начала этой страницы: «Что ж тут непонятного? Зачем платить за чужие библиотеки, если без них вполне можно обойтись в своих программах? Если уж нельзя, тогда другое дело придется покупать». Для себя любимого можно и пиратскими копиями воспользоваться, но юзверям надо предлагать безупречное решение. С другой стороны это просто интересно, иначе можно озадачится вопросом Митрофанушки: «Зачем учить географию, если извозчики есть, отвезут куда надо!»

c127Совершенно верно, зачем платить, если можно взять бесплатные. Хотя об этом уже говорили.
Зачем брать бесплатные на несколько метров (МБ), если можно не брать и воспользоваться своим кодом на несколько килограммов (КБ)?

MasterZivEmery пишет:

> *Майкрософт умудряется сохранять физический порядок в индексном файле
> при разовой вставке / модификации записи без его явного физического
> переупорядочивания*.

Я опять ничего не понимаю.

DBF имеет записи только фиксированной длины. Т..е файл
-- это массив (регулярная структура) записей. Указатель на запись --
это просто её номер по порядку с начала. Записи никогда из DBF не
удаляются физически. Только логически. Физическое удаление
выполняется только в монопольном режиме захвата файла коммандой
PACK. Добавляются записи тольк в конец. Так что ж сложного-то
в сохранении физического порядка записей ?
Ну, речь идет не о dbf файле, а об cdx файле. Про dbf вы все правильно пишите. А в cdx ситуация примерно такая. Вставка идет обычным классическим методом в связный список под управлением дерева (расщепление узла и редактирование нескольких логических связей). Физически индексный ключ оказывается в конце, если ему нет места в середине. А дальше начинается «мистика». Если cdx файл достаточно большой, то происходит замещение физической последовательности сегментов файла логической . Об этот как раз и говорит Гоц Грэйф из Майкрософт . Т.е. физическое переупорядочивание файла идет на уровне операционной системы (абсолютное чтение / запись физического диска). Менять содержимое файла (внутри файловых указателей) нет никакой необходимости, так как реально мы имеем дело с аналогом физической дефрагментацией жесткого диска (которое не влияет на содержимое файла). А вот визуально эффект присутствует. Вставка в гигабайтный индексный файл ключа, который логически должен быть в начале, оказывается в начале и «физически». Т.е. просматривая этот файл через любой шестнадцатеричный редактор, мы видим, что «физически» эта запись присутствует в самом начале файла (имеет соответствующее файловое смещение), тогда как ссылка на эту запись говорит, что реально она находится в конце файла.
Вот пример того, что мы имеем на логическом уровне в нашем гигабайтном cdx файле после вставки в него ключа с 70-ю нулями и буквой «z»:

Адрес листа в файле Ссылка на RList Кол-во ключей4096 1023870976 34608 3072 45120 4096 65632 4608 66144 5120 66656 5632 67168 6144 67680 7680 68192 8192 68704 8704 69216 9216 69728 9728 610240 10240 610752 11264 6

До вставки этого ключа была физически и логически упорядоченная структура с 6-ю ключами во всех листовых индексах. А реальное «физическое» представление после вставки этого ключа показано на прилагаемом рисунке.

MasterZivНу, подобные техники опять-таки достаточно распространены в литературе.
Но конечно покопать придётся.
Вот я и «копаю» :) .

MasterZivЯ имел в виду, что преобразование SQL в физические алгоритмы обработки могут
быть не всегда оптимальными, если вы пишите их руками, может получится выигрыш. Но тоже не всегда :-)
Вот эта и есть одна из причин моего «ручного управления» базами данных.

Да, забыл добавить, что может быть в этом и заключается один из секретов Рашмора (Rushmore’s secret) ? Правда не совсем понятно, какое преимущество дает «замещение физической последовательности файла логической» ?

GYGYИМХО - начните лучше с ОС. А то они уже за несколько Гб переваливают.
Следуя ваше логике, в простенькую программу на 30-50 Кб «напоминателей дней рождения ваших друзей», где всего одна таблица и максимум, что нужно это сортировка и поиск в не более чем 1000 записей (вряд ли у вас больше друзей), нужно обязательно прилепить безплатный движок БД только потому, что он безплатный? А у меня на эту сортировку и поиск в собственном dbf файле уже написано несколько килобайт кода. Так что мне этот код выбросить и обязательно прилепить какой-нибудь sqlite? А если мне этого не хочется делать, так что по этому поводу надо ёрничать? Позвольте другим быть другими и это вам зачтется в будущей жизни!

maytonЯ-бы для начала исследовал возможность использования "того что уже есть" в нормальном Windows XP/Vista. Посмотрите в сторону драйверов MS-Jet (движок Access). Дополнительно, почитайте про MS-SQL Express, особенно про встраивание в приложения. Насколько мне известно, он бесплатен для применения.

Уж коли этих возможностей не будет хватать, тогда следует садиться за разработку чего-то кустарного.
Знаете, провайдеры данных меня не очень устраивают, если уж на то пошло, то меня более привлекают библиотеки коммерческих БД, например, работа напрямую с библиотеками vfp9t.dll / vfp9renu.dll (и другие мои сообщения в этой теме) безо всякой регистрации в реестре. Я уже пытался это делать и имею неплохие результаты (причем с этими dll-ками напрямую никто не работает). Об этом более подробно будет идти речь в моей шестой статье (а сейчас я готовлю пятую). Так что всему свое время .

maytonСмотрели эту ссылку?
Смотрел, только у меня между 4-й и 5-й статьями стоят другие задачи. Вы можете для себя не воспринимать концепцию, изложенную в этой теме. Только традиционные устоявшиеся взгляды в программировании не отменят ее значения. Я говорю не просто так, у меня на работе это метода (пока только частично) задействована профессионально и приносит очень хороший эффект и для меня и для предприятия. Правда, пока это не связанно с С++, на который я ныне ориентируюсь. Вообще-то я по жизни программирую не стандартно, однако это не мешает мне получать хорошие результаты «малой кровью».

maytonЗдесь, позвольте с вами не согласиться. Для современных систем (слава богу) требования объёма кода в бинарнике уже перестали быть критичными. Прошли те времена, когда надо было в оверлейный буфер пихать всю возможную логику. Поэтому мне кажется большее внимание стоит обращать на то, как софт использует и освобождает heap memory и какие механизмы управления этим предоставляет.
Опять же, «два юриста – три мнения», как говорил наш любимый Михаил Сергеевич. Пусть даже так, с этим никто не спорит. Однако, вопрос то в другом, писать программы так, чтобы получать от этого еще и удовольствие . Лично меня не прикалывает слепое поклонение SQL серверам, хоть платным, хоть бесплатным. До сих пор я применяю файл – серверную технологию доступа к данным, вместо клиент –серверной. И ничего, на моем предприятии все прекрасно работает. И перейду я на клиент – сервер только тогда, когда почувствую в этом внутреннюю потребность, а не внешнее «принуждение».

maytonПо поводу ёрничания. Вы взяли на себя смелось написать статью в популярный портал разработчиков. Это - большая ответстсвенность. Вы - несёте "своё" учение. Многие неокрепшие умы после прочтения этого материала перестанут быть "другими" и начнут думать как вы.
Вы, наверное, любите пафосный тон? :) . Интересно, а соседние 25 тысяч статей «в популярном портале разработчиков» не влияют на «неокрепшие умы»? Или на них действуют только мои статьи? Может быть, тогда в них рекламу разместить, чтобы покупали «сникерсы»? Глядишь, мне какой-то процент отчислений пойдет :) ? Не думаю, что это серьезно. С таким же успехом вы можете сказать, не пишите глупости в интернет, их могут читать дети! И пишут и читают и ничего, мир не рухнул. Вообще-то это надо очень постараться, что получить влияние на массы за счет пропаганды своих идей. Для многих это запредельная мечта. Думаю, интернет это вообще хорошее противоядие на информационную отраву. У людей возник такой стойкий иммунитет к информации, что их уже ничем не проймешь. А у кого еще не возник, по малоопытности, то возникнет. Так что собака зарыта в другом месте, а не в этом :) .

maytonP.S. Поэтому не обижайтесь на пристальное внимание и критику.
Да я не обижаюсь, поскольку конструктивной критики как таковой почти нет. Есть элементарное несогласие с моей точкой зрения. Мол, у меня есть своя точка зрения, значит ваша не правильная! А это мы проходили уже не раз, чтобы обижаться. Я ведь соглашаюсь с вашими точками зрения и не пытаюсь «отменить» их, ибо понимаю причины, почему вы так думаете. Но сам я думаю по другому (иногда :) ).

битыйБыл когда популярен Btrieve. Сейчас есть и его бесплатный open source вариант.
Не пошло, понимаешь. Очень трудно потом поддерживать и изменять данные.
Даже Pervasive сделал свой SQL.
Ну и что из этого следует? Для любой популярной программы есть тысячи клонов. Одних только решений автоматизации предприятий предлагают сотни фирм. И сотни тысяч программистов – сотрудников фирм пишут для своих контор свои варианты учета на предприятии. И что? И ничего! Я тоже пишу свой вариант. Если бы помалкивал, то и вопросов бы не было. Но вот решил пообщаться с народом на эту тему, а «народу» это не нравиться. Ну не нравиться, могу и не говорить. Это что решение вопроса – загонять его в угол?

MasterZivEmery пишет:> Вот эта и есть одна из причин моего «ручного управления» базами данных.

Ты про неё не говорил до сих пор ни слова.
Так я много о чем еще не успел сказать! Просто не было повода.

MasterZivEmery пишет:Не, ну я тоже не понимаю, зачем изобретать свой велосипед.
Это не «велосипед», а «тренировка».