Главная > AJAX, Open Source, web2.0, веб-обзоры, СУБД > СУБД для AJAX приложений? Вы подумали про HTML 5, Google Gears или Firefox? Нет, только JavaScript!

СУБД для AJAX приложений? Вы подумали про HTML 5, Google Gears или Firefox? Нет, только JavaScript!

14 марта 2008

taffydb.JPGПриветствую наших читателей. Как уже повелось, сразу хочу сделать маленькое объявление  - после некоторых раздумий я пришел к выводу, что пока, по крайней мере, в блоге не будет материалов с обзорами IE 8.1beta - решение обосновано тем, что об этом уже столько написали, и очень многие, что поднимать эту тему, если только я не смогу написать что-то эксклюзивное, я не собираюсь. Надеюсь, это не сильно разочарует наших постоянных читателей, наш блог все же призван рассказывать Вам о совершенно новых технологиях и инструментах, о которых вы не узнаете где-то еще.

Не а после небольшого вступления, начнем нашу тему. Если вы разработчик AJAX приложений или интерфейсов, то вам это окажется полезным. Если приходится хранить некоторые достаточно обьемные данные в структурированном виде на стороне клиента, то каким образом это оптимально сделать?  Конечно, вам могут помочь обычные массивы (тип данных или, скорее, встроенный обьект Array), и он даже предоставит базовые функции для управления массивом данных и основные операции над ним, но это очень, скажем так, низкоуровневое решение, часть функционала может зависеть от реализации JS-движка в конкретном браузере. Кроме этого, что-то делать с сохраненными данными нужно писать достаточно много собственного кода, и в конце концов ваш код превращается в такое нагромождение вызовов, функций и переменных, что разобраться в этом ой как сложно.

Да, выход из этого есть. В частности, самым лучшим решением (в теории) является использовать специальных плагинов для расширения функциональности браузера, для примера, в Google Gears встроена полноценная СУБД (SQLite), и вы получаете в свое распоряжение все ее возможности прямо в JavaScript коде (самое ценное, по моему, кроме хранения большого обьема данных, является полнотекстовый поиск). Аналогичные инструменты можно встретить в спецификации HTML 5, да и в последних версиях Mozilla Firefox будет встроена база данных в качестве клиентского стораджа, в среде Adobe AIR также используется встроенная база SQLite. Но что делать, если все эти радости по какой-либо причине недоступны либо их использование ограничено, а удобное хранение и работа с данными нужно иметь уже здесь и сейчас, и без дополнительных надстроек. Выход, конечно же есть!

Реализовано все это в проекте Taffy DB - небольшая (честно, реально очень небольшая, порядка 10 Кб) библиотека, которая реализует почти полноценную базу данных полностью на JavaScript. Предназначена она, как думаю, уже понятно, для хранения любых типов данных (в том числе и обьектов, передаваемых в виде JSON), обеспечивает парадигму CRUD (подробнее в Wikipedia), что и позволяет отнести библиотеку к специализированным базам данных, а также предоставляет расширенные функции поиска, фильтрации и сортировки данных. Taffy DB значительно расширяет список доступных операций над коллекциями данных, упрощает вставку, выборку, обновление и удаление данных, поддерживает сортировку в различных форматах (традиционную для SQL DESC/ASC, в том числе и по нескольких полях сразу), выборку данных используя различные выражения (почти как в обычных SQL запросах), учитывая равность, больше/меньше, сходство с образцом, начало/окончание строки по заданной маске и другие. Все операции задаются в виде JSON-обьекта (вернее, в виде JavaScript обьекта, записанного в JSON-нотации, но вы поняли).

Заявляется, что библиотека совместима со всеми популярными фреймворками, включая Dojo, ExtJS, Prototype, jQuery и другие, при этом она полностью самостоятельная, не используя для работы другие библиотеки. Кстати, в Dojo есть модуль, имеющий вроде как схожий функционал, даже несколько (правда они не объединены) - для SQL-запросов и для хранения данных в виде коллекций и списков, в ExtJS, моем любимом, есть очень хороший объект MixedCollection, который может существенно облегчить работу с данными в приложении (раскрою секрет - очень планирую скоро написать обзорчик этого обьекта, уж больно он хорош), но все они все же это, хоть и существенное расширение стандартного обьекта Array, но до функциональности Taffy DB, которая "почти DB", они не дотягивают.

И тут вырисовывается интересная перспектива. Если Google Gears/HTML5 Storages и остальные технологии предлагают офф-лайн сторадж, данные в котором могут хранится даже после закрытия страницы и перезагрузки браузера, то эти обьекты могут только хранить обьекты во время работы приложения. А вот что, если написать некоторую прослойку, которая, сверху, будет предоставлять весь API той же Taffy или ExtJS.MixedCollection, ну а внутри это все в конечном итоге работает либо через Dojo.storages (предлагает использовать либо Flash Storages, либо GoogleGears), либо напрямую с каким-либо плагином. Конечно, обеспечивая работу даже без этих надстроек. Для многих приложений это было бы очень удобно и позволило бы создавать серьезные веб-приложения.

Попробуйте использовать Taffy DB в своих проектах, уверен, вы по достоинству оцените ее мощность, простоту и быстроту. Я уже использую, а вы?

  1. 14 марта 2008 в 16:00 | #1

    Сперва подумал: «Зачем такое счастье нужно».
    Затем вспомнил свои проекты и понял, что есть где применить.
    Спасибо за обзор.

  2. 14 марта 2008 в 16:46 | #2

    оп-ля. ну буквально на днях перечитывал ваши старые дифирамбы Google Gears и прикидывал, как это всё прикрутить к текщему проекту. Возражения были скорее юридического характера — чужое, некондовое да пафосное. а ну как завтра само обновится и начнет адвордс (ихний) посетителям (моим) крутить без спросу? 🙂

    а вот данная СУБД как раз ко двору придется. спасибо за обзор!

  3. 14 марта 2008 в 16:54 | #3

    это все же совершенно разные продукты… и у гугла нет конкурентов и пока не предвидится (именно всему пакету гиарс), даже хваленный HTML5.

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

  4. 14 марта 2008 в 17:56 | #4

    Прикольно, вот только до БД не тянет 🙂 JOIN’ов нет, а без них жизнь нам не мила 🙁
    А про интеграцию с GG и Air так это будет, и после выхода HTML5 никто не будет работать с SQL все будут использовать ORM, и может быть Taffy его прародитель 🙂

  5. 14 марта 2008 в 18:08 | #5

    А можно конкретный пример использования, где это было бы 100% нужно и без этого очень сложно обойтись?

  6. 14 марта 2008 в 18:27 | #6

    ну JOIN это сильно… никогда в жизни не пользовался и все ок 🙂 это не есть неотемлемый атрибут базы 🙂 Просто делает какие-то вещи легче или проще, перекладывая работу куда-то еще… Но всегда можно без них и не менее гибко и удобно. SQL запросы на страницу текста — это плохо, что бы не говорили гуру 🙂

    так то что только задекларировано в HTML 5, уже есть в гирсе и аир, причем на гораздо более высоком технологическом уровне (в AIR в частости).

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

  7. nekufa
    14 марта 2008 в 20:30 | #7

    aleks_raiden: Если вы не пользуетесь «join» это не значит что вещь бесполезная 🙂

  8. 14 марта 2008 в 22:51 | #8

    при интеграции с Флеш хранилищем получится очень приятная штука, кстати может кто посоветует уже проверенные Флеш хранилища (кроме Dojo)

  9. 15 марта 2008 в 19:00 | #9

    nekufa — не бесполезная, а просто необязательна для приложения, которое может считаться БД, к тому же всегда можно сделать проще 🙂

    Руслан — нет больше таких, а дожо как раз проверенная (вроде читал, что разработчик вернулся, либо кто-то новый и теперь перепишут под 1.1 версию).

  10. 15 марта 2008 в 23:09 | #10

    ха! раз нету альтернативы, значит можно подумать в эту сторону, выучить еще Флеш чтоли :)… да и прикрутить к себе в либу…
    прикольно было бы страницы повторно не грузить с инета, только при каком нить флаге принудительного обновления

  11. 15 марта 2008 в 23:55 | #11

    Хм, а зачем? Зачем плодить сущности, если флешевый компонент и хороший уже есть? Вряд ли получится написать лучший, особенно непрофи в AS/Flash.

  12. 16 марта 2008 в 00:21 | #12

    альтернатива это всегда хорошо, как я уже говорил, когда есть выбор это гораздо лучше чем когда его нет, да и еще надо разобраться как у них там все устроено (не факт что идеальным образом) с этого и начну 🙂
    боюсь желание использовать только их сторадж повлечет за собой потянет использование дополнительных ЖС библиотек из dojo, дай бог чтобы небольших. щас вот и выясним можно ли этот сторадж выдернуть не потащив за собой кучу всего

  13. 16 марта 2008 в 01:48 | #13

    Так и оказалось, структура очень запутана, имеет много связей… за универсальность всегда надо платить… посмотрел в исходники их флешек, ничего сложного нет, вполне реально сделать отдельную такую флешку с минимальным ЖС скриптиком, будет очень удобно… если будет настроение, то займусь, мне все равно в проект нада такая штука…

  14. 16 марта 2008 в 14:21 | #14

    ну давайте, если действительно соеденить как плагин для ExtJS и для Taffy, а также просто самостоятельный, да еще с автодетектом гирса то будет достаточно интересно. Тем более, что часть алгоритмов можно вынести в AS, должно быть, скорее всего, быстрее (поиск и другие подобные операции). Кстати, интересно, на AS базы данных писали или нет 🙂

  15. 16 марта 2008 в 16:25 | #15

    Вообще — вещь полезная. Спасибо за статью.

  16. 16 марта 2008 в 17:11 | #16

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

  17. 16 марта 2008 в 21:59 | #17

    Да материальчик подбираешь хороший, постоянно пасусь тут перед сном 😀 …
    По поводу Flash хранилища — ходил думал как туда картинки запихнуть, вот этот вопрос пока мне не понятен, если бы придумать как с картинками пихать — точно возьмусь тогда за это дело… у меня есть пару мыслей но они не проверенные и пока не очень мне нравятся… может у кого есть соображения по этому поводу?

  18. 24 апреля 2008 в 14:26 | #18

    лично я являюсь противником больших обьемов данных на стороне клиента (тоесть архитектуры fat client). Если вам на клиентской стороне понадобилась целая БД — задумайтесь о архитектуре вашего приложения. Мое виденье — что клиент ввобще не должен содержать логики и датасетов. Если это ну просто необходимо (к примеру задача сохранения накапливающихся изменений), то я реализовывал бы типизированый датасет специально под задачу.

  19. 24 апреля 2008 в 14:37 | #19

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

  20. 24 апреля 2008 в 14:56 | #20

    это своего рода холи-вар, которые не хотелось бы начинать (поэтому я и подчеркнул о своем личном мнении по даному поводу). в любом случае спасибо за статью 🙂

  21. 28 июня 2008 в 00:53 | #21

    andrew_scater, №20 — самое интересное, что это решение является абсолютно правильным и провереным временем.
    Жаль, только что многие этого не понимают… 🙁

  22. 28 июня 2008 в 09:16 | #22

    почему вы так считаете, и почему считаете, что нельзя развиваться дальше?

  23. 1 августа 2008 в 01:43 | #23

    Действительно интересно. Подпишусь-ка я на РСС пожалуй. 🙂

  24. 28 августа 2008 в 21:22 | #24

    Оригинальная идея. Только вот интересно сколько времени на это потрачено? 🙂

Комментирование отключено.
Developers.org.ua