Причем тут пхп? Или предлагаете сравнить sqlite на сервере с sqlite на клиенте?
База на клиенте не заменит базу на сервере, у нее задачи другие. Например, позволить веб приложению функционировать в режиме оффлайн, или выступить в качестве кеша — хотя тут уже storage уместнее.
Хотя возможны и другие варианты, например, роль основной базы в приложении Opera Unite…
Ну вы же понимаете, что sqlite на клиенте — это никоим образом не HTML :)
HTML был и остается тем же что и всегда — декларативным языком разметки. Просто для разработки красивых и динамичных веб приложений не хватает очень многого и со стороны HTML, и JS, и транспортных возможностей, и…
Вот как-то так и получилось, что собрали всё это светлое будущее в одну кучу. И назвали HTML5
HTML тут по сути нипричем, это для толстых клиентов сделано, и я лично, разрабатывая в свое время очень большой проект, был бы доволен такой возможности как клиентские дб
Это же офигенная вещь выходит. Дополнительное хранилище на стороне клиента лишним не будет, давно лелеял свою параноидальную идею об использовании ассиметричного шифрования для аутентификации пользователя на Веб-проектах.
А в том-то и соль, что использовать это шифрование каждый раз — слишком ресурсоемко и ненужно. Его планирую использовать иногда, в остальных случая использовать как раз временные cookie. Имелось ввиду что не ключ в них передавать, конечно же.
Это в первую очередь механизм для переиспользования запросов (для ускорения их отработки при нескольких последовательных вызовах), во вторую — для передачи сложным структур данных (array/blob/clob, хотя не в курсе: есть ли такое в sqlite), а уж потом для верификации типов и противодействия sql-injection.
в статье кое-что упущено, при использовании метода openDatabase работает асинхронная версия API и сигнатура метода db.transaction включает в себя ещё два обработчика
transaction(transaction, errorCallback, successCallback);
HTML 5. Работа с Web SQL базой данных