SQL queries alternative

Утверждается, что в некоторых случаях можно работать с огромными базами данных, в которых все предсказуемые SQL запросы могут быть заменены своими эквивалентами, типа как в Clipper’e, так чтобы не терять существенно в производительности.

Здесь опубликована часть будущей статьи для обсуждения.

Август 2009 года

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

Говоря кратко, альтернативой SQL запросам могут служить два основных метода:

1. Индексация данных.
2. «Проводка» данных или дублирование данных в другом (нужном) порядке.

Вообще говоря, сюда следует записать еще такие достаточно «очевидные» утверждения, как

3. Оптимальная организация базы данных.
4. Использование циклов для фильтрации и выборки данных, там, где это эффективно .

Речь идет не столько о принципиальной возможности избежать использования операторов SQL запросов (думаю, это вполне очевидно), а об альтернативе, которая сопоставима по производительности с SQL запросами провайдеров данных и внешних библиотек баз данных . Понятно, что ценой этому будет строгая структура и достаточно жесткий порядок работы с нашей базой данных и, особенно, дополнительный (избыточный) объем данных , который мы вынуждены будем задействовать, чтобы избежать «лишних» запросов.

Используя эти методы можно вполне отказаться от непосредственного использования SQL запросов , а, следовательно, привлечения определенного «движка» (сервера) базы данных. Тем не менее, сервер баз данных может пригодиться для выполнения редких, непредсказуемых операций, эмуляция которых данными методами может занять слишком много времени, например, для разового преобразования данных, либо для «экзотического» экспорта – импорта . Однако особо следует отметить организацию разделенного (совместного) доступа к данным с помощью внешних библиотек баз данных . Программировать это самим достаточно трудно. Другое важное применение сервера БД это минимизация объема (дублирования) данных, за счет использования SQL запросов , ну и, конечно же, это защита данных и разделение полномочий и привилегий доступа к данным . Данные методы эти задачи просто не решают. Тем не менее, даже скромные возможности индексации, проводок, оптимизации и циклов достаточно интересны, чтобы рассмотреть их подробнее на данном этапе.

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

Пока ограничимся кратким замечанием по поводу «правильной» структуры данных . Очень важно четко понимать организацию своей базы данных. Скажем, для учетных задач можно выделить первичные и вторичные таблицы. Первичные таблицы (справочники) служат для определения объектов , например, сотрудника, контрагента, фирмы, банковского счета и т.д. А вторичные таблицы определяют отношения между объектами (операции) , например, документы прихода, расхода, перемещения, переоценки или списания ресурсов и т.п. Далее важна правильная структура подчиненных таблиц (отношение один ко многим) и ссылок на записи (элементы, объекты) других таблиц (отношение многие к одному) . Затем нужно четко контролировать дублирование данных и проводки на их основе . Желательно вместо копирования данных использовать ссылки на них. А при изменении базовых элементов отслеживать зависимые вычисления, особенно для уже проведенных документов . Полезно также для дублированных данных установить режим «только чтение» . Но к этому мы еще вернемся, когда наша демонстрационная программа достигнет соответствующего уровня развития и мы сможем говорить, например, об учете ресурсов более предметно.

Таким образом, точнее будет говорить об индексации, проводках, циклах и «правильной» структуре базы данных как об инструментах оптимизации нашего способа избежать явного применения SQL запросов (т.е. не использовать внешних провайдеров и библиотек баз данных) без существенной потери эффективности работы программы с базами данных .

«Сложность» индексации только в том, что она используется явно достаточно редко, так как любой программист всегда имеет возможность применения либо бесплатных провайдеров данных и различных библиотек баз данных, либо платных коммерческих продуктов. В дальнейшем мы также продемонстрируем работу с такими внешними программными продуктами, но сейчас нам интересно выяснить эффективность собственного «движка» базы данных эмулирующего работу с базой данных VFP-9 .


Следующим пунктом идет «Алгоритм создания CDX файлов» , тоже незаконченный фрагмент статьи. Тем не менее, думаю, что для обсуждения материала достаточно. Единственное. Что не надо думать, что я пытаюсь «отменить» промышленные базы данных . По сути, речь больше идет [b]о «ручном управлении» в частных случаях[b], интересных нам как программистам.

WorobjoffИнтересно, сколько миллионов человеко-часов готов для этого предложить?
Весьма немного. Где-то 0.0001 «миллиона человеко-часов», чтобы опубликовать следующую (пятую) статью с демонстрационным кодом. Вот ссылка на четвертую статью: MFC-04. MMF чтение и создание DBF файлов вместо сериализации для виртуальных списков.

_модЛюбая попытка придумать заменитель SQL рано или поздно приводит к очередному диалекту того же SQL (проверено, плавали). Дело в том, что в основе все равно лежит язык ALPHA Кодда.
Я хочу не «заменитель», а временный «отменитель». Т.е. не использовать SQL вообще, пока в нем не возникнет исключительная потребность. Есть масса достаточно примитивных задач, где есть элементы баз данных, но нет желания использовать дорогую или громоздкую базу данных. Например, что-то типа шароварной программы – напоминателя дней рождений своих друзей. Таких программ в интернете валом, за все просят небольшие, но бабки, и везде реализация таблицы данных реализована из рук вон плохо. Хранят данные либо обычным текстом, либо в виде сериализации. Ясень пень, что лепить сюда внешний движок базы данных абсолютно бессмысленно. Здесь практически одна таблица, в которой максимум что надо делать это сортировку и поиск. Другой пример, который я уже цитировал в соседнем топике это возможность решить задачу «Несложная специфическая БД для 200 млн записей.» средствами С++ & MFC (ради интерфейса). Для подобных задач применять коммерческие движки баз данных достаточно глупо, а использование безплатных библиотек типа MySQL, MyLibSql и т.д. слишком громоздко для таких простых задач (особенно первой). Так что важный вывод, для написания относительно несложных шароварных программ с элементами баз данных лучше всего использовать небольшой по объему, общедоступный код (например, в моем варианте, который я со временем опубликую полностью), без явного применения SQL запросов, что должно сказаться положительно на качестве шароварных программ и их конкурентно способности.

AlexandrPlusА альтернатива в чем?
Убирание SQL и работа с данными на процедурных языках. При создание SQL обратно шли,
чтобы отцепиться БЕЗ ОСОБОЙ ПОТЕРИ ЭФФЕКТИВНОСТИ. А эффективность разных реализаций SQL - это как собственно СУБД реализована!
И что - попытка сделать свою СУБД под одну задачу?

Вот ПРОЛОГ может быть и уже был, а точнее есть - алтьтернатива SQL. Например, DalaLog или СУБД Mnesia Erlang.
Альтернатива – в не использовании внешнего движка БД без крайней необходимости, без существенной потери эффективности.

Не под «одну задачу», а «класс задач». Таких задач достаточно много. Например, шароварные программы, в которых присутствуют элементы баз данных. Скажем, напоминальщики дней рождений ваших друзей. Или домашняя база данных мультимедийных файлов. За такие программулины обычно просят не большие, но бабки. Причем таблицы данных используются из рук вон плохо, поскольку нет средств работы с БД. В лучшем случае используют сериализацию для хранения данных, а обычно просто текстовые файлы. Но даже в таких задачах желательно инлайн редактирование, хранение данных в известных форматах БД, сортировка и поиск. Ну, может быть еще отбор по значению. Понятно, что лепить сюда движок БД глупо, даже если это SQLite. Проще воспользоваться несколькими килобайтами открытого кода для работы, скажем с dbf / cdx файлами. И для такого класса задач вполне достаточно и выглядеть будет прилично. А то я встречал в Интернете один такой «напоминатель» написанный на Яве, с сотней метров самой Явы и сфарганенного как из «царства мертвых». Еще одна характерная задача сформулирована здесь на форуме. Я уже говорил о ней в соседней теме. Это «Несложная специфическая БД для 200 млн записей» . Вот такую проблему стоит решить без привлечения внешних БД. И полезно и приятно и дешево и не долго.

Другой такой класс задач – учетные задачи для предприятия, Типа учета ресурсов, зарплаты, бухгалтерии. Сами по себе эти задачи могут быть достаточно сложны, однако все запросы там предсказуемы и легко могут быть замещены их аналогом. То что эта метода эффективная, я уже доказал самому себе на своей работе. Отвлекаться не буду, так как уже не по теме.

ИзопропилSQLite - дорог или громоздок?
Нет, но что это доказывает? Что ее нужно обязательно использовать, даже если в ней явной необходимости? Будет необходимость, можно будет прилепить к своему клиенту и промышленные SQL сервера – какие проблемы? Принцип минимальной целесообразности еще никто не отменял .

MasterZivА при чём тут собственно SQL или нет ? Скорость работы зависит от
алгоритмов обработки данных, т.е. в основном от алгоритма поиска нужных
записей. Там уже SQL или нет -- всё равно.
А при том, что без внешних серверов БД очень трудно работать со своими БД. Обычно таким сервером БД является SQL server, поэтому о нем и идет речь. Но внешняя БД или библиотека для работы с ней стоит некоторых денег, что следует принимать в расчет, когда собираешься распространять свой продукт. Зачем покупать лицензию на распространение библиотек чьей-то БД, если без них можно, в некоторых случаях, обойтись? Понятно, что алгоритмы прошиты в библиотеках баз данных. Если вы можете написать собственные лучшие алгоритмы или, хотя бы, достаточные по производительности для собственной БД, то почему бы не воспользоваться ими? Множество алгоритмов опубликовано, проблема здесь больше выбора из имеющихся, чем изобретение нового.

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

MasterZivЯ прочитал всё вместе, и понял, что это либо полный бред,
либо на столько неграмотно изложено, что воспринимать можно только
как полный бред.
Бред очень трудно реализовывать в виде серии последовательных статей и демонстрационного кода. Вы читали мою четвертую статью? В пятой будет добавлена поддержка индексных cdx файлов и замерена производительность создания индексов в сравнении с VFP-9 (хотя бы для некоторых, интересных для меня случаев). Тесты по скорости создания индексов с помощью самого VFP-9 я уже показал, затем хочу сравнить со своей реализацией. Будут неприемлемые результаты, буду работать со сторонними библиотеками, нет, тогда со своими. Что здесь бредового то?

MasterZivНу не используй, кто ж тебя заставляет-то ?
Есть у твоей СУБД другие средства -- работай ими. Только быстрее-то
не будет. Т.е. может быть быстрее, да только ты пока даже не заикался
про то, почему бы это могло быть так. В смысле, я-то знаю, почему
может быть быстрее, но ты, видимо, нет.
Любое частное решение всегда можно сделать лучшим, чем универсальное, хотя бы и от таких монстров, как Майкрософт. Я не ставлю целью, написать аналог СУБД. По большом счету, меня интересуют, на данном этапе, только алгоритмы индексации. Про оптимизацию моих программ вряд ли мне кто-либо скажет больше, чем я сам. Про алгоритмы создания cdx файлов у меня здесь есть статья. Она еще не закончена и выбор алгоритмов еще не закончен. Опубликовал ее с единственной целью услышать конструктивные замечания. Пока таких не было. Если вам есть что сказать по этому поводу, то скажите, если нет, то критика «вообще» меня интересует мало. Я там писал, что Майкрософт не публикует своих алгоритмов. Однако это не совсем так. Частично публикует, только бесплатные первоисточники находятся с большим трудом. Например, нашел кое-какие оригинальные статьи Рудольфа Байера, изобретателя B+ деревьев, лежащих в основе создания индексов. Есть и другие интересные статьи по этому поводу. Все на английском, поэтому нужно время, чтобы переварить. Так что я не думаю, что ваше «ноу-хау» будет оставаться в «секрете» слишком долго. Меня сейчас занимают некоторые обнаруженные «секреты» Майкрософт.

ИзопропилEmery,
Что такое "явная необходимость" ?
Это когда хочется без этого обойтись, но не можется :) .

Roman S. GolubinEmeryИзопропилEmery,
Что такое "явная необходимость" ?
Это когда хочется без этого обойтись, но не можется :) .
Есть Embedded-SQL сервера. Это которые только с данными программы работают. При чем, 99% из них - совершенно бесплатные решения с той же производительностью, как и полномасштабные промышленные сервера.
Я займусь SQL серверами, когда почувствую в этом «явную необходимость» :) . Пока же мне интересно исследовать предложенную концепцию насчет временного отказа от внешних SQL серверов за счет ручного управления собственными базами данных.

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 пишет:Не, ну я тоже не понимаю, зачем изобретать свой велосипед.
Это не «велосипед», а «тренировка».

MasterZivRushmore -- это технология применения индексов для выполнения запросов,
а не технология организации индексного файла.
Ну а разве любой SQL не основан на «технологии применения индексов для выполнения запросов»? Вы хотите сказать, что бывают другие варианты, типа тупым перебором? За что тут давать патент то? Да, выражения FOR прописаны в CDX файлах и индексы там сильно с выражениями FOR связаны (если они присутствуют). Конечно, это должно входить в технологию Rushmore. Однако почему вы думаете, патент Rushmore только на организацию выражений FOR и индексов на его основе в CDX файлах? Я предполагаю, что логично будет, что и «замещение физической последовательности файла логической» входит в этот патент. Ни вы не можете предъявить этот патент, ни я, так что дальнейший спор вряд ли что даст.

MasterZiv> преимущество дает *«замещение физической последовательности файла
> логической»*?

Да мне тоже не понятно, о чём ты. Там описываются обычные
методики организации индексного дерева.
Моя таблица и рисунок вам ничего не говорят? А они не вписываются в «обычную методику организации индексного дерева».

Michael_NТо, что Вам интересно в этом ковыряться - это понятно. Не очень понятно, как Вы собираетесь все это применять. В смысле оммерческого использования. Для "«напоминателей дней рождения ваших друзей», где всего одна таблица и максимум, что нужно это сортировка и поиск в не более чем 1000 записей " - можно вообще обойтись текстовым файлом для хранения, потом все операции в памяти. Какие тут нужны индексы? Для задач, требующих большей производительности, как уже говорилось, есть куча продуктов, в т.ч. бесплатных...
Можно, так все и делают и еще имеют наглость просить за это баксы. Только если все смотрят «Дом-2», не означает, что и я его должен смотреть. Мне подобную задачу предложили в качестве теста на программистские способности. Только я всех послал с ихними тестами. Но в памяти отложилось, и волей неволей стал думать, как бы я эту задачу оформил. Сначала хотел просто использовать обычный CListCtrl с инлайн редактированием и сериализацию данных. Ну и плюс свертку в трэй. Однако в своей 4-й статье, которую я здесь упоминал уже много раз, пришел к мнению, что лучше вместо сериализации делать поддержку собственных dbf файлов. Почему dbf? Да просто потому, что это старейший и простейший формат баз данных и на него есть масса внешних вьюеров, в том числе встроенных в Total Commander. Кроме того и CListCtrl и dbf файл работают исключительно со строками (не считая наших преобразований форматов). А CDX логично следуют из DBF, тем более что класс задач на их основе можно значительно расширить. Вы, конечно, можете в «напоминателе дней рождения ваших друзей» использовать хранение данных в текстовых файлах и не использовать индексы для сортировки и поиска. Однако, по-моему, это очень не профессиональный подход. За такую работу надо ставить «двойки». Впрочем, я вам не преподаватель, а вы мне не студент, делайте, как вам хочется. Просто мне такой подход не нравиться, и тут даже спорить глупо.

Michael_NТак что +1. Зачем изобретать велосипед?
Я уже говорил, что это не «велосипед», а «тренировка».