Инженер, PHP, Go, Linux
49,2
рейтинг
29 марта 2010 в 19:56

Разработка → СУБД на PHP — реально! Представляем MooSQL!

PHP*
MooSQL Я думаю, многие в своей жизни сталкивались с ситуацией, когда у вас под рукой нет MySQL (по разным причинам, например хостер не позволяет), а все-таки иметь что-то подобное, или даже сам MySQL хочется. Теперь у вас есть надежда :)! Я и nblxa хотим представить проект под названием MooSQL, цель которого — предоставить MySQL-совместимую СУБД на чистом PHP на случай, если в доме закончился обычный MySQL.

Добро пожаловать под кат! Итак, продолжим :).

Что такое MooSQL?


MooSQL [муу-скул] — это название нашей СУБД с намеком на то, что она будет поддерживать MySQL-совместимый синтаксис. Именно будет — на данный момент такая поддержка отсутствует. Сама СУБД является логическим продолжением YNDb, моего движка для хранения данных на PHP, описанного в этом хабратопике: habrahabr.ru/blogs/i_am_insane/70140.

Одна из поставленных целей — это хорошая (для СУБД на PHP :)) масштабируемость и высокая производительность благодаря использованию индексирования полей.

Что умеет?


Умеет MooSQL не очень много — на данный момент доступен лишь API самой YNDb, который описан на этой вики-странице: code.google.com/p/moosql/wiki/HOWTO.

С тех пор YNDb претерпел немного изменений:
  • Полностью ООП и PHP5, научился бросать исключения при любых критических ошибках
  • Улучшенная поддержка многопоточного доступа — есть возможность параллельно делать несколько селектов из одной и той же таблицы
  • Добавлено два новых типа колонок, которые можно индексировать — BYTE и DOUBLE. Текстовые поля индексировать пока что все равно нельзя
  • ! Row splitting — отныне стало возможным увеличивать длину текстовых полей! Это достигается с помощью введения нового типа записей, которые состоят из нескольких кусков.

Покажите пример работы!!


Во-первых, я бы хотел привести ссылку, которая давалась в топике про YNDb — База данных forum.dklab.ru (старая), импортированная в самодельный форум. С тех пор на нём поселились спам-боты и умудрились написать около 600 (!) Мб текста, написав порядка 120 000 новых сообщений (к тем 130 000, которые были). Форум до сих пор работает и не подает признаков смерти :).

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

Технические подробности


СУБД написана на PHP5, без привязки ни к каким фреймворкам, расширениям PHP и т.д. Физически таблицы и базы данных представляют из себя файлы и папки соответственно. Одна таблица состоит из 4-6 файлов, в зависимости от использования индексов. При чтении из таблицы накладывается разделяемая блокировка на файл table_name.lock, что и позволяет делать параллельно выборки из одной и той же таблицы. При операциях записи ставится эксклюзивная блокировка на тот же файл.

Индексы бывают трех видов — PRIMARY (AUTO_INCREMENT), UNIQUE и INDEX. Формат PRIMARY индекса очень простой — записывается смещение в файле данных (32-битное) по адресу value*4. Это накладывает ограничение на размер файла с данными в 2 Гб. Для UNIQUE индексов используются Б-деревья (Статья про Б-деревья в Википедии), для INDEX — сочетание Б-деревьев и списков для хранения повторяющихся значений.

Данные хранятся в бинарном формате в виде последовательности строк, без разделителей и какой-либо информации о структуре таблицы. Мы называем этот формат «MooISAM». Планируется также сделать формат «MooDB» (по аналогии с InnoDB), который бы позволял осуществлять сильно-многопоточный доступ к данным одной и той же таблицы (MooISAM на данный момент более-менее нормально работает при степени параллельности доступа менее 10). Помимо этого, если MooDB будет, то он будет проектироваться с возможностью добавления поддержки транзакций и внешних ключей.

Заключение


Если вам интересен этот проект, приглашаю вас в нем поучаствовать! Ядро MooSQL под названием YNDb уже приближается по стабильности к production-ready, и хотелось бы привлечь как можно больше людей к тестированию, прежде всего — написанию автоматических тестов для моей СУБД. Я на данный момент знаю о по крайней мере одной ошибке, которая может испортить ваши данные при корректной работе с API. Ну, и, естественно, ищутся желающие принять участие либо в разработке ядра СУБД, либо SQL-части. Обращайтесь, к примеру, в скайп, расскажу поподробнее, если интересно.

Сайт проекта на Google Code: code.google.com/p/moosql
PhpMooAdmin: moosql.googlecode.com/files/PhpMooAdmin.0.0.1.php
Юрий Насретдинов @youROCK
карма
239,1
рейтинг 49,2
Инженер, PHP, Go, Linux
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (125)

  • +1
    А как же транзакции, хранимые процедуры и т.д. и тп.?
    • +1
      Сейчас не планируется. Мы хотим для начала добиться совместимости с MySQL 3.23, в котором всего этого нет :)
      • +2
        Хранимые процедуры — ладно с ними, в embedded БД без них можно обойтись (любителям и профессионалам хранимых процедур — не сердитесь, в общем случае я с вами за одно). А внешние ключи и транзакции imho очень нужны, без них тяжело воспринимать реляционную СУБД как сколько-нибудь полноценную. А область применения найдётся. Небольшие вебприложения под low-load, к примеру, для рабочих групп. Главное чтобы экспорт-импорт был 100%, что называется, «seamlessly» совместим с MySQL 5.1 и PhpMyAdmin 3.3 чтобы люди могли спокойно мигрировать на полноценную MySQL по мере роста потребностей и возможностей.
        • 0
          Между прочим, MyISAM внешние ключи и транзакции не поддерживает, а ведь это очень долго был дефолтный движок в MySQL :)!

          А экспорт и импорт конечно сделаем, потому что именно на это и рассчитано — дать возможность человеку поработать без MySQL настолько долго, насколько это возможно, но с возможностью после этого пересесть на MySQL безболезненно.
          • 0
            > Между прочим, MyISAM внешние ключи и транзакции не поддерживает

            Именно поэтому пока InnoDB-движок в MySQL более-менее не созрел, я пользовался только MS SQLServer. Ниша MyISAM, на сколько я понимаю, mid/high load consumer приложения, прежде всего с большой интенсивностью инсертов и апдейтов, там она себя оправдывает. А в Enterprise (не зависимо два там клиента или десятки тысячь) транзакции необходимы, и в low-load внешними ключами вряд ли есть смысл принебрегать, да простит меня К.О.
            • 0
              MyISAM это не high-load, она относительно плохо держит высокие нагрузки, особенно параллельные вставки во время селектов. А вот InnoDB — хорошо, ценой некоторой потери производительности, связанной как раз с overhead от поддержки в том числе и транзакций.
              • 0
                Спасибо за поправку.
  • +45
    А… прочитал тэги, передумал писать коммент
    • +1
      Уже спрашивали. В общем, в основном для получения опыта и получения представления о том, как работают СУБД. А заодно заставить хостеров добавить MySQL даже для самых дешевых тарифов.
      • +1
        На самых дешёвых тарифах, как правило (по крайней мере из того, с чем я сталкиваюсь), нет не только MySQL, но и PHP (и появляются они с повышением цены вместе, а дальше меняются колличественные характеристики). Иначе я сейчас же бы воспользовался MooSQL. Напишем РСУБД на SSI? :-)

        А вот для образовательных целей очень может оказаться полезной вешью. Потомство оценит если Вы будете писать хорошо структурированный и документированный код. Надеюсь оно ООП :-)
    • –5
      Я не понял ваш коммент :)
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Хотелось совместимости с MySQL, SQLite такой совместимости не даёт :). Плюс к тому, у SQLite есть некоторые проблемы с разницей хранения данных между SQLite 3 и SQLite 2, а здесь можно поставлять библиотеку, которая будет хранить данные точно в том формате, в котором записана база.

      А вообще, я писал изначально это для PHP4, на котором SQLite нет :).
      • 0
        Было бы здорово иметь в комплекте конвертер файлов данных из/в sqlite.
        Наверняка несложно сделать, особенно, если конвертировать через промежуточный текстовой SQL-дамп.

        (Зачем? Ну, к примеру, был проект на хостинге с SQLite, надо его переложить туда, где SQLite по каким-либо причинам отключен)
      • +1
        Сколько же вы лет ее писали? о_О
        • 0
          С огромными перерывами — года полтора. Просто сначала я думал всё же оставить совместимость с PHP4, а сейчас передумал :).
    • +8
      ну как же! он же не на нашем любимом php! /irony
  • +1
    В пост приглашаются умельцы написания парсеров/генераторов парсеров.
    • 0
      bizon?
      • 0
        bison умеет php генерить?
        • +1
          www.gnu.org/software/bison/
          RTFM. Bison умеет все. Но его нужно учить.
          • –3
            GPL :(
            Но с тем, что знание bison/yacc/etc полезно, конечно, соглашусь.
    • 0
      Молодцы, так держать!
  • +28
    Вы выкинули в никуда кучу времени. Поздравляю!
    • –8
      Как по-Вашему, создатели MySQL тоже выкинули вникуда кучу времени, или нет? Чем СУБД на PHP хуже?
      • НЛО прилетело и опубликовало эту надпись здесь
        • +6
          Вот смотрите, к примеру, это страница форума на основе MooSQL: datapoliten.ru/misc/fdklab__AA221tda/moosql_test_forum/index.php?act=viewtopic&t=1400. Выборка порядка 20 сообщений из базы в 130 000 меньше, чем за 0.014 сек — это медленно (во время входит не только время исполнения запросов)?

          Когда я думал, делать её вообще или нет, я руководствовался тем соображением, что скорее всего в современных СУБД ограничивающим фактором является не процессор, а работа с файловой системой и диском. Процессоры станут быстрее, а вот жесткие диски, особенно по времени произвольного доступа — вряд ли. Да, PHP медленный, но только в сравнении с голым Си. И на нём всё равно можно писать сложные системы, вот только трудозатраты будут меньше в несколько раз.
          • +6
            Форум этот просто летает. Я серьезно.
            • +2
              Спасибо :). Но на MySQL он работает ещё быстрее :).
              • +8
                Быстрее у меня монитор не сможет менять кадры.
                • 0
                  «Java не тормозит, просто всё остальное слишком быстро работает» вспомнилось))))
        • +1
          Я бы не стал так утверждать. На большинстве реальных серверов, которые мне попадались, операции с файлами производятся быстрее, чем с базой. А временем исполнения самого PHP-скрипта часто можно пренебречь. Поправьте меня, если я неправ.

          Мне кажется, это может стать успешным проектом. У меня была подобная идея, только я хотел портировать код SQLite на PHP. Но идея показалась слишком безумной и ненужной.
          • 0
            А по-моему, не так уж безумно и ненужно, как может показаться на первый взгляд.
            • 0
              Раньше это потребовало бы от меня неоправданных усилий (опыта было мало). А теперь PHP меня мало привлекает и я занимаюсь им только в коммерческих проектах.
          • 0
            Скажу по секрету, что MySQL тоже хранит данные в файлах.
            Тут лишь аналог встраиваемого мускула, только написанный на языке, не предназначенном для задачи и обгрызанным функционалом.
      • 0
        Нет. Создатели MySql — молодцы, что создали базу, которой успешно пользуется куча людей. Правда, надеюсь, MySql скоро умрет под напором NoSQL баз.

        А вот вы выкинули время в никуда. Кто будет пользоваться вашей базой? Где вы видели такие хостинги без MySql? Если хостинг без базы, то сделать все на файлах куда как быстрее и лучше, чем городить 100500 абстракций для поддержки SQL, в которых (абстракциях) еще и багов будет несметное множество.

        Разница за хостинг без и с мускулом — копейки. Ваш проект — мертворожденный.

        Если у вас есть куча времени и желания, то можно приложить свои усилия в куда как более перспективные направления. Лично я жалею, что в сутках только 24 часа, т.к. идей немерено, а времени их реализовывать мало.
        • –1
          Если хостинг без базы, то сделать все на файлах куда как быстрее и лучше

          Обоснуйте, пожалуйста. На данный момент у нас поддержки SQL собственно нет, но вот производительность уже сравнить можете. Сейчас это чисто файловый движок, без SQL абстракций. Тоже не нужно, скажете?

          А вот вы выкинули время в никуда. Кто будет пользоваться вашей базой? Где вы видели такие хостинги без MySql?

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

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

          Про несметное множетсво багов мне тоже не очень понятно. Почему вдруг они должны появиться? Для отлова багов проводится тщательное автоматическое тестирование, тот же SQLite проходит порядка 2 млн. тестов перед каждым релизом, насколько мне известно. А мы будем использовать тесты, написанные для MySQL, чтобы как раз-таки убедиться в отличии расхождений между MySQL и MooSQL :).

          Если у вас есть куча времени и желания, то можно приложить свои усилия в куда как более перспективные направления. Лично я жалею, что в сутках только 24 часа, т.к. идей немерено, а времени их реализовывать мало.

          Приведите пример, что Вы считаете перспективным направлением? К тому же, я трачу не так уж много времени, и только когда хочу. И у меня тоже много других идей, которые я тоже постепенно воплощаю в жизнь.
          • +1
            Если сейчас нет поддержки SQL, то откуда эта аббревиатура взялась в заголовке?

            Я не говорю о производительности. Я говорю о скорости и удобстве разработки.

            Баги есть всегда. Это аксиома. Чем больше внешних библиотек используется, тем сложнее эти баги исправлять и отлавливать. Ваша библиотека на данный момент слишком молода, чтобы говорить об отсутствии проблем. Автоматические тесты отнюдь не гарантируют 100%-ую надежность.

            Для меня перспективное направление — стартапы. Для вас, если вы хорошо разбираетесь например в базах, таким направлением может быть создание революционной NoSQL базы без всякого там PHP, который для этих целей совершенно не подходит.
            • 0
              Если сейчас нет поддержки SQL, то откуда эта аббревиатура взялась в заголовке?

              На данный момент поддержка SQL активно разрабатывается, и в коде библиотеки есть немало кода, посвященного именно SQL. Тем не менее, оно пока что не документировано и не пригодно к использованию.

              Баги есть всегда. Это аксиома. Чем больше внешних библиотек используется, тем сложнее эти баги исправлять и отлавливать. Ваша библиотека на данный момент слишком молода, чтобы говорить об отсутствии проблем. Автоматические тесты отнюдь не гарантируют 100%-ую надежность.

              А что в таком случае гарантирует?

              Для меня перспективное направление — стартапы. Для вас, если вы хорошо разбираетесь например в базах, таким направлением может быть создание революционной NoSQL базы без всякого там PHP, который для этих целей совершенно не подходит.

              Меня лично реляционная модель вполне устраивает, и для абсолютного большинства проектов её производительности и машстабируемости вполне хватает, так что я не стал бы сбрасывать реляционные СУБД со счетов. А с чего Вы решили, что PHP не подходит для разработки СУБД (или веб-сервера, фаерфола, файловой системы и т.д.), мне не очень понятно.
              • 0
                > А что в таком случае гарантирует?
                На 100% — ничто. Кроме того, вопрос ведь не только в объемах тестирования, которые вы произвели, но и в банально в доверии к вашему продукту.

                Реляционная модель плохо изменяется, плохо приспособлена для задач современного веба (к примеру, древовидные структуры), плохо масштабируема. Под «плохо» понимается «хуже, чем альтернативы». Сравните геморрой, описанный тут: habrahabr.ru/blogs/mysql/76149/, с простотой изменения структур большинства NoSQL баз.

                Так что привычные табличные структуры лучше всего хранить в nosql базах, которые и работают быстрее, и программировать под них удобнее. Для древовидных структур существуют графовые базы. А во многих ситуациях обычным key-value хранилищем можно ограничиться.

                PHP не подходит не для чего, кроме создания относительно несложных сайтов. Начните писать на других языках, и вопросы сами отпадут. Писать огромное full ajax веб-приложение на PHP — морока страшная. Писать на нем демоны в принципе нереально. Сборка мусора появилась совсем недавно и ее надежность и производительность под оооочень большим вопросом. Кроме того, стандартная библиотека PHP провоцирует программиста на ошибки. Все это жевано-пережевано кучу раз. Хотя, лично мне не нравится разрабатывать на нем и обычные сайты, но это уже другая тема.
                У PHP, безусловно, есть достоинства. Но недостатков настолько много, что закрывать на них глаза — просто глупо.

                И, да, то, что 100000000 кодеров по всему миру использует PHP и MySQL для меня ничего не значит. Мнение кодеров (именно кодеров, а не толковых программистов) вообще ничего не должно значить.

                Разрабатывать можно на чем угодно. Но при этом надо видеть и плюсы, и минусы своего выбора. В противном случае это — ограниченность.

                Предлагаю не продолжать тему PHP тут, т.к. лично мне это просто не интересно. Если мой коммент заставит кого-то задуматься — отлично. Если он вызывает только мысли «remal — еритик, а PHP — великий язык», то смело ставьте мне минус и идите дальше. Мне пофиг на карму, но интересны интересные обсуждения. В этом топик готов поговорить на тему баз.
        • 0
          Кстати, с вводом поддержки SQL производительность, по планам, не должна ощутимо ухудшиться. Баги — ну будем править баги, куда денемся. А сообщество, надеюсь, поддержит.
      • +1
        Всем?
      • 0
        а почему в названии sql? какой стандарт поддерживается?
        • 0
          Пока что — никакой :). Но планируется поддерживать «стандарт» MySQL 3.23
      • 0
        Тем, что на PHP. Нельзя будет использовать в неPHP проектах.
    • 0
      Просмотр телевизора — трата времени впустую. Программирование — нет. :)
  • –4
    пэздец :-)
  • НЛО прилетело и опубликовало эту надпись здесь
  • +3
    Интересно посмотреть как оно изнутри работает. Полезно в плане изучения того как работает БД и хранит все. Особенно интересно удаление записей. Как индекс будет при этом себя вести.
    • +2
      Исходники открыты, смотрите :). При удалении записей в файле с данными просто остаются пустые места, а индекс действительно частично и по довольно сложному алгоритму перестраивается, но для Б-дерева используется «упрощенная» система, которая не осуществляет полной перестройки Б-дерева ценой потери гарантии 50% заполненности каждого узла. Удаление из индексов очень тщательно мной тестировалось, причём код самих тестов в проекте на Google Code тоже есть.
      • 0
        Вы меня заинтриговали )) В свое время создавал аналог БД правда под одну задачу: решение анаграмм. Индекс + орфографический словарь в бинарном файле. Решение анаграммы составлял сотые-тысячные доли секунды. Потом усложнил и мне захотелось узнать давно мучавший меня вопрос. Сколько слов можно составить из слова «синхрофазатрон». Оказалось более 200 ;) С тех пор интересных задач и не попадалось (( Правда и вышеописанную я сам для себя придумал.
        • +3
          эх, придётся вам пересчитывать…
          что-то сохранилось? надо теперь проверить верное написание, через «о» :)
          (синхрофазoтрон)
  • +1
    я когда-то (лет 5 назад) такой-же велосипед на перле изобретал… freshmeat.net/projects/lkbindb
    Оно до сих пор пашет в одном из моиих (заброшеных) проектов. все хранилось в двоичных файлах (что «условно» несвойственно перлу).
    Если интересно — можете глянуть код. Ой наверно старшный он тогда был :-)
    • 0
      Интересно :). Посмотрю, спасибо.
    • 0
      Кажется, у неё нет индексов, это так? Если да, то печально…
      • 0
        мне стыдно. но я не помню ;-). Давно это было. но вроде что-то такое я пытался там сделать
  • +2
    Шикарная картинка
  • 0
    Насколько хорошо документирован проект? И насколько стабилен? И что, например, с INSERT DELAYED — будет работать хоть в каком-то виде? А GROUP_CONCAT?
    • 0
      SQL нету сейчас! Не будет INSERT DELAYED работать сейчас :). Но планируется те директивы, которые ни на что не влияют (тот же DELAYED) просто игнорировать.
      • 0
        Туплю наверное, а какой же интерфейс к БД предполагается?
        • 0
          Умеет MooSQL не очень много — на данный момент доступен лишь API самой YNDb, который описан на этой вики-странице: code.google.com/p/moosql/wiki/HOWTO .
          • 0
            А ведь интересно, черт побери (с)!

            Надо пощупать повнимательнее…
  • +8
    Чертовы фанатики :D
  • –1
    >MySQL-совместимую СУБД на чистом PHP на случай, если в доме закончился обычный MySQL.
    >под рукой нет MySQL (по разным причинам, например хостер не позволяет),

    вы напишите php-совместимый интерпретатор… на случай, если хостер не позволяет php…
    • +1
      Интерпретатор PHP на PHP уже есть и называется eval() :)
      • 0
        пхп-шный же eval? .) и как вы его выполните без пхп?
        я думал, вы дочитали до места «на случай, если хостер не позволяет php»…
        • –3
          А на чём Вы предлагаете писать интерпретатор PHP, если на хостинге даже PHP нет??
          • 0
            На html+javascript :) Правда, клиентский PHP насколько помню уже кто-то писал в буржунете.
          • +1
            ну додумайте же, наконец, тег irony к моему комменту, а?
            • +1
              Ну а Вы в свою очередь к моему, да :).
              • –2
                гг
  • 0
    Имхо, подобные вещи — шаг назад.
    И это я пишу не потому что не понимаю вас, а потому что сам делал кучу велосипедов, и СУБД и ОР-маппер и HTTP-сервер, и еще много всяких «полезных штук».
    И наконец то дорос до того, что пользуюсь как и все тем, что уже давно сделано :))
    В любом случае, удачи вам… :)
  • +5
    Скоро будем PHP'ом щи хлебать!
    • +3
      >>PHP'ом
      Перебрал много вариантов произношения, но не осилил…
      • 0
        пиэйчпипом :)
      • 0
        пиашпом?
        пиэйчпом?

        эр-эн-эром?
        • +1
          похапом
      • +3
        пыхом
        • 0
          ^_^
      • +5
        рок-н-ролом
  • +3
    Поразительное по качеству извращение, одобряю! :)
    • +4
      Я надеюсь хотя бы на йоту приблизиться к мастерству того человека, который на хабре публиковал сетевой морской бой (или что-то подобное :)) на батниках :).
    • 0
      А если вообще и не думать предупреждать, то они начнут писать свою ОС на html+JS и прикладное ПО.
      Хм… Мне кажется я сказал что-то лишнее…
      • 0
        Написали виртуальную машину на JS, а вы ОС, ПО ;)
  • +2
    как бе… и?

    напишите сравнение вашей коровячей субд и SQLite?
  • +1
    молодцы ребята так держать!
  • +1
    Не обсуждая всю абсурдность идеи. Глянул на код btree_gen.php. Это позор.
    • 0
      Тоже глянул. Половину можно в community.livejournal.com/code_wtf/ постить. Из запомнившегося: метод delete(), сразу после if($ISLEAF) идет $N--. А где изначально присваивается значение этой переменной?
      • 0
        здеся

        list($N, $ISLEAF, $pointers, $values, $offsets) = $data_arr;

        • –1
          Это был риторический вопрос:)

          Вообще, язык программирования не должен давать так писать… А раз дает, то не надо пользоваться такими не очевидными конструкциями.
          • 0
            плюсуэ
          • +2
            так мы когда-нибудь дойдем до того, что конструкция for($i=0,$i<$c,$i++) тоже станет для кого-то неочевидной…
    • 0
      В начале файла реализации Б-дерева честно предупреждается, что это самая сложная часть СУБД и требует хорошей теоретической подготовки для того, чтобы понять код, который там написан. В основном он является портом с примера реализации Б-дерева по этому адресу: www.bluerwhite.org/btree/ (причём с исправлением ошибок в коде примеров :)). Метод delete() «сочинил» я сам, причём я реализовал не полную версию алгоритма удаления из Б-дерева, но зато ту, что есть, постарался очень тщательно прокомментировать.

      Не вижу здесь позора, поскольку я не обязан приводить описание непосредственно схемы работы Б-дерева прямо в коде :).
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        B-tree изучают студенты в ВУЗе. Я писал не про алгоритм, который знать весьма полезно, а про качество реализации и код. Вместо того, чтобы писать километровые комментарии, лучше бы отрефакторили код.
        • 0
          Я так и не понял, что в моём коде Вам конкретно не нравится.
          • +1
            Это плохо, что не понимаете.

            Вообще говоря, ничего, не нравится.

            Ужасный coding style, naming convention.
            Есть слово класс. Но это не ООП. Функция обработки ошибок в процедурном стиле.
            Debug трейс вместе с форматированием внедер прямо в код, что вносит еще большую путаницу.
            Куча вложенных if, циклов. Наверняка можно отрефакторить.
            Слишком длинные методы.
            Слишком большое кол-во входных параметров у методов.
            Не уверен, что этот код пройдет E_ALL | E_STRICT.
            • 0
              Функции для обработки ошибок в процедурном стиле только в файле с Б-деревом, насколько я помню (не переписал их ещё на использование исключений, не спорю).

              Debug трейс вместе с форматированием внедер прямо в код, что вносит еще большую путаницу.

              Где Вы предлагаете его держать?

              Куча вложенных if, циклов. Наверняка можно отрефакторить.

              Возможно, их можно сделать проще, но не сильно, там именно сама логика сложная.

              Слишком большое кол-во входных параметров у методов.

              По-моему, там от силы 5-6 параметров, причём первые 2 всегда одинаковы (это сделано для того, чтобы один и тот же instance класса можно было использовать для разных файлов с Б-деревом, или же для разных Б-деревьев внутри одного и того же файла), все из которых необходимы и необходимость наличия этих параметров определяется сутью самого метода.

              Слишком длинные методы.

              С тем, что код delete() длинный я соглашусь, а все остальные методы, ИМХО, достаточно короткие.

              Не уверен, что этот код пройдет E_ALL | E_STRICT.

              Может, и не пройдёт. Это показатель качества кода?
              • 0
                Ну и другие файлы не лучше?

                client.php.
                У класса с модификатором final есть protected методы.
                MooResource то же самое.
                Зачем в состояние класса MooResource добавлен sql? Он нигде не фигурирует кроме конструктора.
                if (isset($this->parser)) — дурацкая проверка, так как параметр обязателен.

                DataInterface.php
                О! Знакомый set_error, см. пред. пост.
                Это что такое: !!fopen_cached ??
                метод getTableStructure НЕ может возвращать false, он возвращает structure. Если структуры нету — это null или exception, если она обязательна.

                По такому качеству кода далее смотреть я не стал.
                • 0
                  !!fopen_cached() — это более короткий эквивалент (bool)fopen_cached(...)

                  метод getTableStructure НЕ может возвращать false, он возвращает structure. Если структуры нету — это null или exception, если она обязательна.

                  Возможно, Вы и правы.

                  client.php.

                  Это файлы Паши, может быть он Вам и ответит :).

                  А вообще, на данный момент самая важная часть СУБД лежит в core/, в том числе и Db.php

                  О! Знакомый set_error, см. пред. пост.

                  Этот метод больше не используется в DataInterface (как и почти везде в core/) и оставлен «на всякий случай», если я вдруг где-то забыл заменить вызовы set_error на throw new Exception(...).
                  • 0
                    Ну вот открываем Index.php. И что?

                    Все то же самое можно сказать и об этом файле.

                    function delete_index($fp, $fpi, $data, $fields, $index, $row_start) — это не метод, это процедура.

                    Кстати, когда я писал на php, я считал одним из самых важных правил тот факт, что код должен нормально выполняться при: E_ALL | E_STRICT. Это гарантирует защиту хотя бы от глупых ошибок.
                • 0
                  Спасибо за то, что ткнули носом в качество кода. Любая критика уместна.

                  Я, все же, надеюсь, что мы не на экзамене, и можем постепенно улучшать и качество кода и функционал. Шероховатости будут разглажены, баги исправлены, круглое перекачено, а квадратное перенесено.
  • +3
    Как бы там ни было — для автора это, определенно, level up. А нужно ли это кому-то еще — покажет время. Иногда, самые неожиданные идеи находят свои ниши. В любом случае, удачи!
  • 0
    Посмотрите, такие решения уже есть. Везде пришлось отойти от стандартного SQL по элементарной причине — скорость удручает.
    • +1
      Я в курсе, что есть решения на PHP, которые поддерживают SQL (и делают это довольно плохо, кстати :)), но я не видел ни одной СУБД с поддержкой индексов, а значит их скорость будет сильно падать не только из-за неграмотной работы с SQL, но и из-за необходимости полного просмотра таблицы для любого запроса. Причём найти адекватные парсеры SQL или же «вычленить» SQL-часть из уже имеющихся проектов (вроде FFQL) не представляется возможным и разумным. Мы хотим использовать достаточно простой, и в тоже время гарантирующий высокую производительность, подход для работы с SQL, о котором я могу Вам рассказать подробнее в личке / скайпе / где-нибудь ещё
      • –3
        Не слушайте их.

        Ругать PHP модно, ибо есть домохозяечные языки вроде Ruby (сейчас заминусуют).
        txtSQL видели, кстати? Может пригодится.

        За проект — респект вам.
        Напишу на досуге драйвер для своего фреймворка под MooSQL.
        Просто для расширения спектра решений для разных применений =)
        • 0
          Видел TxtSQL, но в нем SQL поддержки нет, а блокировки сделаны таким образом, что они могут терять данные ( flock() после fopen() в режиме 'w'… ). Ну и индексы не поддерживает. Помимо того, что их сайт www.txtsql.com/ недоступен :)).

          Кстати, если будете делать драйвер, не забудьте учесть, что SQL пока что у нас тоже нет :).
          • 0
            А у меня всеядная система доступа к данным, она не видит различий между переменными, файлами, СУБД, KVS или удалёнными ресурсами.
            • 0
              Хорошо, если так :).
        • 0
          Не скажете кого «их» не слушать? Я программирую на PHP много лет, ещё PHP3 застал.
          • 0
            «Их». Не «Вас».
      • 0
        Спасибо! Послежу за проектом.
  • 0
    подойдет для автоматического тестирования mysql запросов
  • 0
    А через hiphop пропускать пробовали?
    • 0
      Пока что нет.
  • +10
    Сами собой напрашиваются два вопроса:
    1. Нахуя;
    2. НАХУЯ?!

    Это похапе головного мозга, товарищи.
    • 0
      Спасибо за Ваше ценное мнение. По делу есть чо?
    • 0
      на самом деле, взглянув на большую часть, процентов так в 99, разработок в инете можно сказать — «НАХ*Я».

      Ребята развиваются, а как в пхп это еще можно без проектов подобного рода.
      единственное что конечно вопрос то friday довольно адекватен, но бог в помощь. буду почитывать, может что получится интересное.

      правда конечно это еще стоит поискать хостинг без мускула… ну если уж очень бюджетный.
  • 0
    Скоро мы увидим NoNoNoSQL. Если вы делаете маломальски хороший проект, врядли будет проблемой купить хостинг с мускулом, а заниматься этой ерундой — бред, имхо!
  • 0
    Спасение для тех кто размещает cms на дешевых хостингах, теперь хостинг может быть ещё дешевле, без Mysql =)
  • 0
    Спасибо за статью.
    Прочитал с удовольствием.
    С нетерпением жду DBD::MooSQL
  • 0
    это извращение
  • 0
    Приходите на DEVCONF 2010 с докладом…
    Кроме автором MySQL и Postgres — мы планируем собрать все noSQL DB
    devconf.ru/offers
  • +1
    Такая ситуация интересная произошла, намедни наткнулся на статью, прочитал с удовольствием, улыбнулся, подумал про себя: «ведь сейчас везде есть MySQL, не проще ли раздобыть хостинг с мускулом, либо установить его на сервере». По прошествию нескольких дней меня попросили написать 1 штуку, нужно использовать БД, а мускула нет на сервере и установить — гемор очень большой (не будем вдаваться в подробности). Бегом полетел искать эту статью, на этот раз добавил в favorites :)). Автору большое спасибо!!!
  • 0
    Автору-разработчику благодарность за развитие такого проекта.

    Немного напрягают возгласы типа: "-а нах оно надо! -везде есть мускуль! -а чем SQLite не устроил" и тп и тд. Слова избалованных веб разработчиков… НО! ведь применение данного инструмента не ограничено рамками веб проектов! Очень кстати будет использование в различных embedded системах, устройствах и тп (примеров много).
    Для своего проекта (live система узко заточенного linux) в свое время долго искал mysql совместимый легковесный встраиваемый движок БД. Возможно медленный, со слабым функционалом, но легкий и совместимый с mysql. Кроме sqlite ничего не нашел. Вроде как все почти устраивает, однако нет совместимости с mysql ;(

    С удовольствием буду следить за развитием проекта ;)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.