Это побеждает в основном in vitro, так же, как и exists в предикате. Чуть посложнее основной запрос и/или корррелированный - и нет никакой гарантии, что вся конструкция не свалится в O(N^2).
Вывод - если вы можете решить задачу без подзапроса/outer apply (что собственно практически одно и то же) - делайте надежно через inner/left join с подзапросом. Если не можете (лень, или селективность предиката основного запроса выше, чем селективность подзапроса) - делайте коррелированным - но тогда уж лучше - outer apply. В нем хоть можно получить несколько полей за один раз, да и протянуть из него значение в основной предикат (последнее нужно юзать с пониманием).
Но никто не мешает возвращать пару (EmployeeID, RowOrder) и сохранять в буферную таблицу. На стороне песочницы можно сделать row_number() переместив order by в него. Тогда все будет работать железобетонно, но просто данных через stdout будет передаваться в 2 раза больше :)
Нужно делать все, чтобы компьютер как можно дольше оставался рабом человека, а не наоборот (наоборот оно само скоро получится - знаний и навыков манипуляции в AI-мозге уже больше чем достаточно, чтобы обдурить статистическое большинство людей, а с разумным меньшинством искусственный мозг скоро догадается расправиться силой зомбированного большинства, а не собственной хитростью - то есть ровно так, как мы это наблюдаем сейчас в человеческом обществе).
Следовательно - никаких Гц с миганиями, резких тонов, кнопок ЖМИ скорее и получи мегабонус итд. Всем этим вы увеличиваете (быдло)конверсию, но в гораздо большей степени приближаете адъ! И не важно, выше порога эпилепсии частота мигания или резкость градиента цвета, или она еще "терпима" устойчивыми представителями - важно то, что вред от массовых агрессивных UI и UX-решений компенсировать в обществе будет очень дорого, если вообще возможно.
всегда было интересно, есть ли в умных чайниках алгоритмическая защита от его использования в горах? А от выхода из строя датчика температуры? Напрмер, умеет ли прошивка анализировать кривую роста температуры, а не только достижение 100С (которая на высоте 2000м например, всего 93С), или ограничивать предельное время работы нагревателя, и выключать элемент при выходе температуры на полку кипения, или по таймауту? :
На уровне ORM это очень грубо, буквально черно-бело. Все или ничего. Если делать оптимальнее, то метод, который выбирает данные чилдовой сущности, должен иметь на входе список первичных ключей родительской сущности, для которых выбираются чилдовые. Далеко не всегда их нужно выбирать для всех ключей родителей. В рудиментарном случае - это единственный ID (например, для показа/редактирования экземпляра родителя), в более сложном (или статистически-частом) - например, вызов чилдов только для ID тех родителей, которые в данный момент рендерятся на клиентском экране.
Вычитывать "все для всех" часто бывает избыточным - а интегральная производительность системы определяется не трудоемкостью отдельно взятых операций, а трудоемкостью их статистической смеси, наблюдаемой при рабочей нагрузке. Например, если клиент статистически не скроллит вниз выдачу дальше первых 5-6 элементов - то и выбирать чилдов дальше 5-6 без специального события (скролла вниз) заранее не нужно. И что в данном случае будет лучше (если у нас нет точных средств, которые я описал, а есть только "все или ничего") - совсем не очевидно.
Видимо текстовые значения окавычиваются на middle-tier без экранирования и подставляются в стейтмент типа where x in (‘aaa’, ‘bbb’, ‘ccc’), где потом строковые значения лукапятся в ID ролей из справочника, и дальше идет merge в таблицу ассоциаций юзер-роль. Как-то так.
Как Вам сказать - это было лет за 10 до открытия кафедры КТ, студенты и выпускники которой прославились на весь мир. В начале моей учебы в институте там было все достаточно архаично, и меняться начало только со второй половины 90-х годов. Преподаваемый Паскаль с практикой на СМ-1420 мало чем помог бы в низкоуровневом программировании под MS-DOS (а вот книга Правец-16 и самостоятельное изучение ассемблера x86 - очень даже помогли)
Я на кафедральной PC/XT на Турбо-Паскале написал wysiwyg-файловый менеджер, который считывал MBR, FAT и структуру директорий дисков прямо через вызовы BIOS, показывал файлы и каталоги наподобие NC, и позволял защищать/снимать защиту с файлов и каталогов путем патчинга первого байта имени защищаемых файлов нулем (перенося то, что там было, в неиспользуемый байт записи о файле). Это делало невозможным открытие файла ничем, кроме непосредственного редактирование секторов через diskedit. Chkdsk тех времен, как и NDD, тоже емнип не замечали этого, так что получалось довольно надежно ;)
Прятали таким образом в учебном классе на кафедре программу, которая через RS-232 позволяет копировать файлы с компа на комп. А вот в этих файлах были втч игрушки. Шлейф для копирования тоже был самодельный - метров 15 телефонного провода с цанговыми разьемами от какого-то советского разьема на концах (колодки DB-9 тогда стоили денег).
Лучше бы в Гугл-картах сделали умный указатель POI в режиме следования по маршруту. В существующем варианте - это ад кромешный - если ввести, скажем fuel stations, или McDonald’s, то предложения густо даются в местах, которые ты уже (давно) проехал, а вперед по маршруту - либо ничего, либо через 10 часов пути вблизи от точки назначения. Бесит страшно, особенно если найти POI нужно во время движения. Я вспоминаю старый добрый CityGuide, он на порядок лучше сделан для вождения, хотя и не без глюков тоже (при путешествии между странами не умеет адекватно считать время из-за проблем с трассировкой на стыках карт), и в Европе пробки и дорожные события показывает неадекватно.
А простой делитель на двоичном счетчике не подошел бы в качестве устройства понижения частоты? И на выходе тоже был бы меандр и фиксированная амплитуда..
Да, абсолютный диапазон изменения частоты бы уменьшился, но это критично?
Тут дело не в выгорании, а в буксовании. Потребности (втч финансовые) 20-летнего и 50-летнего человека сильно различаются - как и пропорция его времени, которое он может уделить работе - как и scope проблем, которые он может охватить в своей деятельности (условно - высота полета над ландшафтом задач в bird’s eye view).
Если человек идет стандартным статистическим путем (обзаводится семьей, детьми, дачей, тещей, пожилыми родителями итд) - то ему нельзя не поднимать высоту bird’s eye view, так как для определенного scope существует предел денежной компенсации (условно, семейство кривых роста зп от уровня квалификации насыщаются - и этот уровень разный для разных квалификаций). Поэтому посредственный директор может прокормить семью с детьми, дачей, тещей, Volvo Executive или MB GLE, а экспертный разработчик- нет. Нужно соблюдать баланс скорости и угла атаки (как для самолета), чтобы эффективно увеличивать еще и высоту.
Я бы приспособил вместо шлема уже имеющийся в доме апплаенс - смарт-пылесос. Нужно только воткнуть его шланг в нагнетающий выход, а другой конец держать в районе головы. Как только телефон почувствует невесомость, он по блютусу дает команду пылесосу дуть, и тот сдувает телефон с траектории падения в сторону от головы. Нужно только еще, чтобы в пылесосе был двигатель с мгновенной раскруткой (обычный коллекторный не подойдет). И никаких шлемов :)
Это для пациентов стационаров? Здоровым людям проще читать телефон, лежа на боку, чем держать руки вытянутыми вертикально вверх с увесистой (в Азии превалируют андроид-лопаты) плюхой в руках. Зачем бороться с тяготением, когда можно просто лечь на бок?
Ну если нужны бронебойные решения для работы в Заполярье, я бы сделал даже программную нагрузочную вилку - скажем нагружать батарею через ключ на полевике на 500 Ом импульсом в пару десятков микросекунд, и смотреть падение, чтобы оценить внутреннее сопротивление.
Был уверен, да. Через буфер-триггер Шмидта вешалось все равно, через буфер + RC-цепь - нет. И если тактировать вход через D-триггер от sysclk - тоже нет.
Это было что-то на уровне логики цифрового автомата внутри контроллера.
Это побеждает в основном in vitro, так же, как и exists в предикате. Чуть посложнее основной запрос и/или корррелированный - и нет никакой гарантии, что вся конструкция не свалится в O(N^2).
Вывод - если вы можете решить задачу без подзапроса/outer apply (что собственно практически одно и то же) - делайте надежно через inner/left join с подзапросом. Если не можете (лень, или селективность предиката основного запроса выше, чем селективность подзапроса) - делайте коррелированным - но тогда уж лучше - outer apply. В нем хоть можно получить несколько полей за один раз, да и протянуть из него значение в основной предикат (последнее нужно юзать с пониманием).
Но никто не мешает возвращать пару (EmployeeID, RowOrder) и сохранять в буферную таблицу. На стороне песочницы можно сделать row_number() переместив order by в него. Тогда все будет работать железобетонно, но просто данных через stdout будет передаваться в 2 раза больше :)
само использование например GREATEST/LEAST уже намекает на 160
при INSERT .. EXEC вставка идет в том порядке, в котором резалтсет поступает в stdout - то есть в порядке, прописанном в dsql.
Хорошо обозначен базис в 8-мерном пространстве, но из-за объема статьи по каждому из измерений - по 1-2 шажка. Но все равно созвучно, спасибо.
Нужно делать все, чтобы компьютер как можно дольше оставался рабом человека, а не наоборот (наоборот оно само скоро получится - знаний и навыков манипуляции в AI-мозге уже больше чем достаточно, чтобы обдурить статистическое большинство людей, а с разумным меньшинством искусственный мозг скоро догадается расправиться силой зомбированного большинства, а не собственной хитростью - то есть ровно так, как мы это наблюдаем сейчас в человеческом обществе).
Следовательно - никаких Гц с миганиями, резких тонов, кнопок ЖМИ скорее и получи мегабонус итд. Всем этим вы увеличиваете (быдло)конверсию, но в гораздо большей степени приближаете адъ! И не важно, выше порога эпилепсии частота мигания или резкость градиента цвета, или она еще "терпима" устойчивыми представителями - важно то, что вред от массовых агрессивных UI и UX-решений компенсировать в обществе будет очень дорого, если вообще возможно.
всегда было интересно, есть ли в умных чайниках алгоритмическая защита от его использования в горах? А от выхода из строя датчика температуры? Напрмер, умеет ли прошивка анализировать кривую роста температуры, а не только достижение 100С (которая на высоте 2000м например, всего 93С), или ограничивать предельное время работы нагревателя, и выключать элемент при выходе температуры на полку кипения, или по таймауту? :
На уровне ORM это очень грубо, буквально черно-бело. Все или ничего. Если делать оптимальнее, то метод, который выбирает данные чилдовой сущности, должен иметь на входе список первичных ключей родительской сущности, для которых выбираются чилдовые. Далеко не всегда их нужно выбирать для всех ключей родителей.
В рудиментарном случае - это единственный ID (например, для показа/редактирования экземпляра родителя), в более сложном (или статистически-частом) - например, вызов чилдов только для ID тех родителей, которые в данный момент рендерятся на клиентском экране.
Вычитывать "все для всех" часто бывает избыточным - а интегральная производительность системы определяется не трудоемкостью отдельно взятых операций, а трудоемкостью их статистической смеси, наблюдаемой при рабочей нагрузке. Например, если клиент статистически не скроллит вниз выдачу дальше первых 5-6 элементов - то и выбирать чилдов дальше 5-6 без специального события (скролла вниз) заранее не нужно. И что в данном случае будет лучше (если у нас нет точных средств, которые я описал, а есть только "все или ничего") - совсем не очевидно.
Слог потрясающий, как и спектр примеров. Чувствуется старая школа. Респект!
Видимо текстовые значения окавычиваются на middle-tier без экранирования и подставляются в стейтмент типа where x in (‘aaa’, ‘bbb’, ‘ccc’), где потом строковые значения лукапятся в ID ролей из справочника, и дальше идет merge в таблицу ассоциаций юзер-роль. Как-то так.
Как Вам сказать - это было лет за 10 до открытия кафедры КТ, студенты и выпускники которой прославились на весь мир. В начале моей учебы в институте там было все достаточно архаично, и меняться начало только со второй половины 90-х годов. Преподаваемый Паскаль с практикой на СМ-1420 мало чем помог бы в низкоуровневом программировании под MS-DOS (а вот книга Правец-16 и самостоятельное изучение ассемблера x86 - очень даже помогли)
Я на кафедральной PC/XT на Турбо-Паскале написал wysiwyg-файловый менеджер, который считывал MBR, FAT и структуру директорий дисков прямо через вызовы BIOS, показывал файлы и каталоги наподобие NC, и позволял защищать/снимать защиту с файлов и каталогов путем патчинга первого байта имени защищаемых файлов нулем (перенося то, что там было, в неиспользуемый байт записи о файле). Это делало невозможным открытие файла ничем, кроме непосредственного редактирование секторов через diskedit. Chkdsk тех времен, как и NDD, тоже емнип не замечали этого, так что получалось довольно надежно ;)
Прятали таким образом в учебном классе на кафедре программу, которая через RS-232 позволяет копировать файлы с компа на комп. А вот в этих файлах были втч игрушки. Шлейф для копирования тоже был самодельный - метров 15 телефонного провода с цанговыми разьемами от какого-то советского разьема на концах (колодки DB-9 тогда стоили денег).
Это был 1989-1990 г. ЛИТМО.
Лучше бы в Гугл-картах сделали умный указатель POI в режиме следования по маршруту. В существующем варианте - это ад кромешный - если ввести, скажем fuel stations, или McDonald’s, то предложения густо даются в местах, которые ты уже (давно) проехал, а вперед по маршруту - либо ничего, либо через 10 часов пути вблизи от точки назначения. Бесит страшно, особенно если найти POI нужно во время движения. Я вспоминаю старый добрый CityGuide, он на порядок лучше сделан для вождения, хотя и не без глюков тоже (при путешествии между странами не умеет адекватно считать время из-за проблем с трассировкой на стыках карт), и в Европе пробки и дорожные события показывает неадекватно.
сфокусированным потоком свч-излучения ловко передаем собранную даровую энергию из облаков прямо в дом.
А простой делитель на двоичном счетчике не подошел бы в качестве устройства понижения частоты? И на выходе тоже был бы меандр и фиксированная амплитуда..
Да, абсолютный диапазон изменения частоты бы уменьшился, но это критично?
Тут дело не в выгорании, а в буксовании. Потребности (втч финансовые) 20-летнего и 50-летнего человека сильно различаются - как и пропорция его времени, которое он может уделить работе - как и scope проблем, которые он может охватить в своей деятельности (условно - высота полета над ландшафтом задач в bird’s eye view).
Если человек идет стандартным статистическим путем (обзаводится семьей, детьми, дачей, тещей, пожилыми родителями итд) - то ему нельзя не поднимать высоту bird’s eye view, так как для определенного scope существует предел денежной компенсации (условно, семейство кривых роста зп от уровня квалификации насыщаются - и этот уровень разный для разных квалификаций). Поэтому посредственный директор может прокормить семью с детьми, дачей, тещей, Volvo Executive или MB GLE, а экспертный разработчик- нет. Нужно соблюдать баланс скорости и угла атаки (как для самолета), чтобы эффективно увеличивать еще и высоту.
Но у Вас с этим все в порядке ;)
Забрало будет потеть, если лежать на спине. Значит, читатель смартфона будет открывать забрало - но тогда см. выше )
Я бы приспособил вместо шлема уже имеющийся в доме апплаенс - смарт-пылесос. Нужно только воткнуть его шланг в нагнетающий выход, а другой конец держать в районе головы. Как только телефон почувствует невесомость, он по блютусу дает команду пылесосу дуть, и тот сдувает телефон с траектории падения в сторону от головы. Нужно только еще, чтобы в пылесосе был двигатель с мгновенной раскруткой (обычный коллекторный не подойдет). И никаких шлемов :)
Это для пациентов стационаров? Здоровым людям проще читать телефон, лежа на боку, чем держать руки вытянутыми вертикально вверх с увесистой (в Азии превалируют андроид-лопаты) плюхой в руках. Зачем бороться с тяготением, когда можно просто лечь на бок?
Ну если нужны бронебойные решения для работы в Заполярье, я бы сделал даже программную нагрузочную вилку - скажем нагружать батарею через ключ на полевике на 500 Ом импульсом в пару десятков микросекунд, и смотреть падение, чтобы оценить внутреннее сопротивление.
Был уверен, да. Через буфер-триггер Шмидта вешалось все равно, через буфер + RC-цепь - нет. И если тактировать вход через D-триггер от sysclk - тоже нет.
Это было что-то на уровне логики цифрового автомата внутри контроллера.