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 серверов за счет ручного управления собственными базами данных.