IndexedDb. Ха ха ха
Unfortunately, IndexedDB lacks the kind of full-text searching that you would find with SQL databases such as MySQL or PostgreSQL. Instead, we need to filter our results using a regular expression.
Это смешно, товарищи.
Думаю, ни о какой скорости речи даже быть не может, по сравнению с тем же sqlite.
Ведь данные идут по циклу и цикл снаружи, и применяется фильтрация на стороне клиента.
О ужас.
Чем им sqlite то не понравился.
Нужно будет всё же перевести проект на indexed db ради прикола, для проверки скорости работы...
То есть, получается, что это какая-то помесь localstorage + индексы. И ничего более.
Читаем:
По сути, они приговорили к смерти будущие клиентские приложения.
Ибо они будут медленными и/или ограниченными в чём то (из-за низкой скорости работы по поиску данных).
Хорошо, если sqlite не выкинут из браузеров. Ибо я не вижу вообще смысла использовать indexeddb, если конечно, это не простой список дел на 100 элементов =))
Например, для серьёзного проекта может понадобиться поиск по слову для 1 миллион записей. Представляю, как это будет тормозить при этом самом внешнем цикле и проверке даже строковыми функциями =))
Конечно, кто-то скажет, что можно сделать индекс по словам в отдельную таблицу, приводить-нормализировать, выбирать сначала оттуда, потом по индексам из основной таблицы (ведь обычно на странице бывает не более 10...20...50 элементов, поэтому тормозить не будет так сильно). По идее, правильно, в стиле сфинска для mysql.
Но основной фокус в том, что страничник показать будет возможно, только узнав полное количество записей по данному ключу, а это можно будет сделать, только перебрав все *миллионы* записей =))
Ибо какого-то возвращения количества записей в этих курсорах нет.
Конечно, кто-то скажет, что нужно завести ещё одну таблицу и там хранить индекс количества записей по каждому слову, по каждому сочетанию слов и т.д. до бесконечности (таблица может быть очень огромная).
В общем, ребята тут что-то намудрили. Неужели не проще использовать уже готовый продукт в виде sqlite и мощных универсальных языков запросов SQL?
Конечно, скорости процессора и js повышаются, но всему есть предел.
У кого-нибудь есть реальные замеры скорости на реальном серьёзном приложении, которое использует indexeddb и fulltext search на > 10000 записей?
Это смешно, товарищи.
Думаю, ни о какой скорости речи даже быть не может, по сравнению с тем же sqlite.
Ведь данные идут по циклу и цикл снаружи, и применяется фильтрация на стороне клиента.
О ужас.
Чем им sqlite то не понравился.
Нужно будет всё же перевести проект на indexed db ради прикола, для проверки скорости работы...
То есть, получается, что это какая-то помесь localstorage + индексы. И ничего более.
Читаем:
18 ноября 2010 г. консорциум W3C объявило прекращении поддержки СУБД Web SQL. В связи с этим разработчикам более не рекомендуется использовать эту технологию, так как выпуск обновлений для нее прекращен, а поставщики браузеров не заинтересованы в ее дальнейшем развитии.
Заменой для Web SQL являются индексированные базы данных (которым, собственно, и посвящено данное руководство), предлагаемые разработчикам для хранения и обработки данных в клиентских приложениях.
По сути, они приговорили к смерти будущие клиентские приложения.
Ибо они будут медленными и/или ограниченными в чём то (из-за низкой скорости работы по поиску данных).
Хорошо, если sqlite не выкинут из браузеров. Ибо я не вижу вообще смысла использовать indexeddb, если конечно, это не простой список дел на 100 элементов =))
Например, для серьёзного проекта может понадобиться поиск по слову для 1 миллион записей. Представляю, как это будет тормозить при этом самом внешнем цикле и проверке даже строковыми функциями =))
Конечно, кто-то скажет, что можно сделать индекс по словам в отдельную таблицу, приводить-нормализировать, выбирать сначала оттуда, потом по индексам из основной таблицы (ведь обычно на странице бывает не более 10...20...50 элементов, поэтому тормозить не будет так сильно). По идее, правильно, в стиле сфинска для mysql.
Но основной фокус в том, что страничник показать будет возможно, только узнав полное количество записей по данному ключу, а это можно будет сделать, только перебрав все *миллионы* записей =))
Ибо какого-то возвращения количества записей в этих курсорах нет.
Конечно, кто-то скажет, что нужно завести ещё одну таблицу и там хранить индекс количества записей по каждому слову, по каждому сочетанию слов и т.д. до бесконечности (таблица может быть очень огромная).
В общем, ребята тут что-то намудрили. Неужели не проще использовать уже готовый продукт в виде sqlite и мощных универсальных языков запросов SQL?
Конечно, скорости процессора и js повышаются, но всему есть предел.
У кого-нибудь есть реальные замеры скорости на реальном серьёзном приложении, которое использует indexeddb и fulltext search на > 10000 записей?