Если бы я писал этот коммент, мне было бы обидно написать два экрана текста и получить отрицательный рейтинг.
Если бы я писал этот пост, мне было бы обидно прочитать два экрана текста и увидеть внизу ремарку, что это лишь теоретические рассуждения.
От себя добавлю, что рекомендации спорные, а иногда и неверные.
Дык и с объектами на уровне приложения — оно же должно знать структуру хранимого объекта. Вообще, даже в sql никто не мешает вам ограничиться всего одним строковым полем на таблицу и сказать, что в нем находится сериализованный объект (удобство sql, кстати, как раз в том, что он этого НЕ делает). Так что это скорее синтаксический сахар, а мы с Вами говорили об эффективности.
Да, конечно, можно и нужно хранить предрасчитанные данные. И если четко ограничить круг запросов, которые будут в системе, то можно сделать крайне эффективное кеширование, заточенное исключительно на эти запросы и работающее очень быстро. Но это вопрос бизнес-логики, а не БД — если понятна структура этого кеша, то уже неважно, в каком сторадже он будет реализован, эффективность дает в первую очередь именно строго специализированный кеш, а не движок стораджа.
Я бы все-таки рекомендовал свой велосипед.
Дело в том, что в ваших условиях как минимум два предиката неравенства: i < j && X_i < Y_j, а, значит, вам понадобится мерджить индексы и операция, которую вы, как я понял, ожидаете мгновенной, сведется как минимум к index scan.
Правда, если вы будете часто сравнивать не две произвольные точки из ряда, а, например, одна из них будет близко к концу, то этот index scan будет быстрым.
То есть получается либо а) велосипед, либо б) sql storage. Гибкости sql вам вполне хватит, а сильно эффективнее вряд ли можно сделать — index scan будет все равно.
NoSQL вообще не советовал бы рассматривать — для вас критично умение стораджа реализовывать разные методы слияния индексов и умный оптимизатор — а в обоих вещах тот же InnoDB даст NoSQL стораджам большую фору.
Еще забыл рассказать про подключение наушников к источникам сигнала — это совершенно отдельный ад. Подключение у меня занимало секунд 10-15 каждый раз (а я-то наивный рассчитывал просто кнопочку на наушниках включить), причем действия на компе нужно было делать в строгой последовательности. Не знаю, почему так — даже bluetooth-мышь подключалась сама.
Ну и держали наушники часа 4 игры, а потом — на зарядку становись.
К качеству звука претензий нет, есть претензии к устойчивости.
Звук теряется при повороте головы (зачастую и при плавном), даже небольшом перемещении относительно источника звука (в моем случае трясся при ходьбе карман с плеером). В результате постоянные секундные паузы, музыку при ходьбе слушать невозможно. От ноутбука в соседнюю комнату тоже не отойдешь — не ловит. Или ловит, но так, что лучше бы вовсе не ловил.
Bluetooth-мышь теряла сигнал даже при тонкой преграде (ноутбук лежит на коленях ниже уровня стола, мышь елозит по столу — сигнала нет). Заменил на радиоадаптер — проблема исчезла.
Похоже, в идеальной ситуации (сидит недвижный манекен, прямо рядом с ним — источник звука) это работает, а вот в реальном мире — не ахти.
В итоге, считав два года назад Bluetooth серебряной пулей, сейчас я скорее буду советовать знакомым его избегать.
Возможно, виноват не сам стандарт, а производители, которые экономят на уровне сигнала, но, честно говоря, это не мои проблемы как потребителя :)
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Если бы я писал этот пост, мне было бы обидно прочитать два экрана текста и увидеть внизу ремарку, что это лишь теоретические рассуждения.
От себя добавлю, что рекомендации спорные, а иногда и неверные.