Вот давайте не будем про настоящих и ненастоящих гиков. У всех свои основные рабочие инструменты. Дизайнер или верстальщик по-вашему тоже должны мышку выкинуть?
Но даже я, будучи программером — больше читаю код и путешествую по зависимостям, нежели непосредственно пишу его. И мышкой пользуюсь очень активно.
Возможно, я не спорю :) Есть куча народу, у которых рабочий стол завален всегда, а я привык наоборот — на рабочем столе чисто как после установки системы, зато пуском пользуюсь очень активно :)
В статье говорится про Windows RT и Surface RT, а публика начала обсуждать Windows 8 и соответствующие сценарии использования.
Я Win8 ещё не ставил, но уже сейчас мне кажется весьма сомнительной идея отказаться от кнопки пуск и необходимость прыгать в метро на устройствах без сенсорного монитора. Поэтому Windows 8 с её сценариями использования — это совершенно отдельная песня.
А вот Windows RT и Surface RT — это просто сказка. И в статье очень правильные вещи говорятся. Реально, я пользую Surface RT всего чуть более трёх недель, однако уже сейчас я практически перестал пользоваться своим «нетбуком» (исторически сложилось, у меня ультрабук — это основная машина, исключая рабочую). Metro безумно удобен.
Из того, что есть на нетбуке и чего не хватает на Surface RT — это MS VS (но она и на нетбуке была «на всякий случай») и IRC-клиент. Но IRC-клиенты для Surface уже начали появляться в маркете и в скором времени их допилят до юзабельного состояния.
Более того, я стал меньше пользоваться своим HTC Sensation на андроиде. Т.к. кроме звонков я с него читаю с гуглридера и просто в инете лажу — так вот, лазить в инете на Surface RT намного удобнее. Полностью устраивающего меня гуглридер клиента для Surface RT пока нет, но те, что есть — часть задач покрывают и делают это красиво и удобно.
Итого — в моём повседневном использовании surface перетянул на себя большую часть задач именно от нетбука и немалую часть задач с телефона. О чём, собственно и говорится в статье.
Вопрос на засыпку. Являюсь пользователем Windows RT, по указанной выше ссылке написано, что версия для ARM доступна. А в Store на самом устройстве по слову mamba находит только приложение IM+. Так как поставить-то его? :)
Чем не угодило более подходящее по смыслу событие HttpApplication.ResolveRequestCache ??? Так ли уж необходим маппинг обработчика до решения о выдаче страницы из кэша?
Т.е. вы в итоге поняли суть моего первого сообщения? Я это к тому, что от написанного в посте метод принципиально ничем не отличается (преобразование двумерных координат в id узла qtree и обратно — оно ж базовое, его по-другому не сделать).
Просто мне не понятен был выбор символьного типа для хранения и индексации, вместо простого, более логичного и более быстрого бинарного.
Аналогично можно 1101000000000000 < x < 1111039999999999 заменить на бинарную операцию (проверка по маске), если база сию операцию правильно поймёт и погонит по индексу, а не фулл сканом.
В моём случае применялась ESE DB, она на кластерном индексе такого в принципе не понимает, да и там не SQL ни разу.
Нет. Вы упорно игнорируете упаковку координат в один qtreeid.
ГРУБО:
из (10.211111; 11.201010) получаем 1101221011101110.
поиск также будет 1101000000000000 < x < 1111039999999999
Это совсем грубо и на пальцах. В реале как минимум перемешиваем биты, а не цифры и границы интервала координат приводим к границам возможных значений выбранного числового типа.
То ли я вас не понимаю, то ли вы меня.
SQL база ни про какой qtree знать ничего не знает, хоть в строковом виде, хоть в бинарном. Исключение — PostGIS и прочие geo-ориентированные базы со специальными типами.
В вашей реализации мы имеем поиск по строковому индексу, что по сути выливается в range scan по индексу, а далее вытаскивание строк, на которые ссылаются вытащенные записи индекса.
В моей реализации с обычным индексом поиск выливается в такой же точно range scan по индексу, с той лишь разницей, что бинарное сравнение быстрее, чем символьное.
В моей реализации с кластерным индексом — range scan идёт напрямую по строкам, предварительный скан индекса не нужен вообще, что ещё быстрее.
Если это замечание ко мне — то я не предлагаю делать range scan по двум полям, я предлагаю именно по одному.
Координаты переводятся в вид с фиксированной запятой (по сути целые), далее их составляющие биты чередуются (lat1,lon1,lat2,lon2 и т.д.), в результате получаем тот же qtree id, но в целом виде. Из вашего варианта можно получить то же самое, заменив литеры 0, 1, 2 и 3 на соответствующие биты 00, 01, 10, 11. На выходе получите то же самое, но целочисленная арифметика всяко быстрее.
В результате — для выборки точно так же имеем range scan по одному полю.
Ога. Даже упаковка обеих координат в 32 бита даёт в итоге точность на уровне сантиметров (точно сейчас уже не помню, когда делал — считал), чего для большинства применений более чем достаточно.
Ога. Только вместо строкового поля с Id тайла лучше привести к числовому (каждый уровень будет занимать по 2 бита в нём).
В результате можем во-первых строить кластерный индекс, во-вторых индексация int явно дешевле, нежели индексация string, в-третьих поиск a < x < b тоже явно дешевле, нежели поиск LIKE '132023231%'
Но даже я, будучи программером — больше читаю код и путешествую по зависимостям, нежели непосредственно пишу его. И мышкой пользуюсь очень активно.
А то, что метро в принципе есть в Win8 — это даже хорошо, т.к. ноуты с сенсорным дисплеем будут только множиться, а метро под палец очень удобен.
Я Win8 ещё не ставил, но уже сейчас мне кажется весьма сомнительной идея отказаться от кнопки пуск и необходимость прыгать в метро на устройствах без сенсорного монитора. Поэтому Windows 8 с её сценариями использования — это совершенно отдельная песня.
А вот Windows RT и Surface RT — это просто сказка. И в статье очень правильные вещи говорятся. Реально, я пользую Surface RT всего чуть более трёх недель, однако уже сейчас я практически перестал пользоваться своим «нетбуком» (исторически сложилось, у меня ультрабук — это основная машина, исключая рабочую). Metro безумно удобен.
Из того, что есть на нетбуке и чего не хватает на Surface RT — это MS VS (но она и на нетбуке была «на всякий случай») и IRC-клиент. Но IRC-клиенты для Surface уже начали появляться в маркете и в скором времени их допилят до юзабельного состояния.
Более того, я стал меньше пользоваться своим HTC Sensation на андроиде. Т.к. кроме звонков я с него читаю с гуглридера и просто в инете лажу — так вот, лазить в инете на Surface RT намного удобнее. Полностью устраивающего меня гуглридер клиента для Surface RT пока нет, но те, что есть — часть задач покрывают и делают это красиво и удобно.
Итого — в моём повседневном использовании surface перетянул на себя большую часть задач именно от нетбука и немалую часть задач с телефона. О чём, собственно и говорится в статье.
На sql-базах не пробовал, т.к. они отжирают на хранение и индексы куда больше места, чем я могу им дать :)
Просто мне не понятен был выбор символьного типа для хранения и индексации, вместо простого, более логичного и более быстрого бинарного.
И кстати, я только сейчас обратил внимание, как у вас из 11d получается 0101b??? Да и с другими числами аналогично, равно как и предыдущих сообщений.
В моём случае применялась ESE DB, она на кластерном индексе такого в принципе не понимает, да и там не SQL ни разу.
ГРУБО:
из (10.211111; 11.201010) получаем 1101221011101110.
поиск также будет 1101000000000000 < x < 1111039999999999
Это совсем грубо и на пальцах. В реале как минимум перемешиваем биты, а не цифры и границы интервала координат приводим к границам возможных значений выбранного числового типа.
SQL база ни про какой qtree знать ничего не знает, хоть в строковом виде, хоть в бинарном. Исключение — PostGIS и прочие geo-ориентированные базы со специальными типами.
В вашей реализации мы имеем поиск по строковому индексу, что по сути выливается в range scan по индексу, а далее вытаскивание строк, на которые ссылаются вытащенные записи индекса.
В моей реализации с обычным индексом поиск выливается в такой же точно range scan по индексу, с той лишь разницей, что бинарное сравнение быстрее, чем символьное.
В моей реализации с кластерным индексом — range scan идёт напрямую по строкам, предварительный скан индекса не нужен вообще, что ещё быстрее.
Координаты переводятся в вид с фиксированной запятой (по сути целые), далее их составляющие биты чередуются (lat1,lon1,lat2,lon2 и т.д.), в результате получаем тот же qtree id, но в целом виде. Из вашего варианта можно получить то же самое, заменив литеры 0, 1, 2 и 3 на соответствующие биты 00, 01, 10, 11. На выходе получите то же самое, но целочисленная арифметика всяко быстрее.
В результате — для выборки точно так же имеем range scan по одному полю.
В результате можем во-первых строить кластерный индекс, во-вторых индексация int явно дешевле, нежели индексация string, в-третьих поиск a < x < b тоже явно дешевле, нежели поиск LIKE '132023231%'