Нейтронный поток — есть. И даже существенно более интенсивный, т.к. это термоядерные нейтроны. И наведенная радиация есть. Но «бомбового пика» — нет.
Т.к. нет продуктов распада урана, плутония и трансурановых элементов.
Ну, точнее они есть, но в следовых количествах.
Например, в советских промышленных термоядерных зарядах степень «выгорания» плутония превышала 90%, при том, что собственно плутония там было менее 100 грамм.
А нейтронный поток лишь активирует окружающие легкие элементы, которые становятся радиоактивными на кратчайший срок.
Какой такой «бомбовый пик»?
И, кстати, заметьте, первое ядерное испытание — это 1945 год, а промышленные ядерные устройства — 1980. Т.е. 35 лет всего. Мгновение.
Еще один забавный момент.
Практически достоверно известно, что ЮАР провела 2 ядерных испытания в период разработки ЯО.
Но никто не знает, где и как.
А это было менее 40 лет назад.
Это к вопросу обнаружения отдаленных последствий взрыва.
Ну… Это просто!
Выступлю адвокатом дьявола :-)
Достаточно отнести «ядерную цивилизацию» в ледниковый период, т.е. 110-10 тыс. лет назад.
В то время уровень океана был на от 20 до 200 м ниже современного, так что все прибрежные города, и, вся промышленность сейчас находятся на 200 метровой глубине под слоем донных отложений.
Даже сейчас подавляющее число городов находятся в прибрежной полосе 100 км, а уж 100-10 тыс. лет назад, когда цивилизация в современном смысле могла существовать лишь в узкой полосе вдоль экватора… Короче, всё утонуло.
С ядерными бомбами тоже всё просто :-)
Забыли «чисто-термоядерное» оружие, т.е. такое, которое требует либо минимального количества плутония для инициации термоядерного взрыва, от 10 до 100 граммов.
Например, они использовались в СССР при промышленных взрывах.
Кстати, современные заряды как раз и содержат менее 0,5 кг плутония на устройство, так что современный ядерный конфликт, если таковой случится, будет как раз «криптоядерным», с т.з. аргументов статьи, разумеется. Ну, если не затронут АЭС, конечно.
В криптоисторики и любителя теории заговоров меня записывать не надо :-)
Это из любви к искусству, т.с.
По рабству в Северной Америке.
Рабство в Северной Америке перестало быть экономически эффективным только в 30х годах ДВАДЦАТОГО века (подчеркиваю — 20-го), после изобретения широкозахватных комбайнов.
По этой теме существует скандальное исследование одного американского ученого.
Так что рассуждения про рабство — в ту же топку, что рассуждения про Гракхов, которые добились абсолютно одинакового [не]успеха, как уже указывали выше.
А вот каждый лист каждой библии Иоганна Гуттенберга — абсолютно уникален.
И, помнится кто-то (из великих, не помню кто) искал скрытые сообщения в особенностях шрифта.
> Задача: Дана база данных по предприятиям отрасли в виде карточек-отдельных файлов html, которые надо отфильтровать и объединить в 1 файл Excel для расчета ряда показателей.
Не знаю, как там всё было устроено, но, возможно, задачу можно решить вообще без программирования, используя надстройку PowerQuery (не путать с PowerPivot).
В сравнении с nested loop — не ускорение. А уменьшение времени выборки в некоторых, весьма специфических условиях :-)
Вложенные циклы — вообще самый лёгкий, производительный и универсальный вариант соединения. Но на небольших объемах данных.
И, кстати, в версии 6.0 — 7.0, если мне память не изменяет, только он и был.
Но благодаря некоторым трюкам, как то организация хэш-таблиц, битмап-индексов, предварительной сортировке данных, на БОЛЬШИХ выборках удается получит выигрышь во времени выборки… за счет чего-то.
Например, построение хэш таблиц — очень охочее до процессора мероприятие, и MSSQLSERVER считает его дорогим и применяет неохотно.
Соединение слиянием требует отсортированных входящих потоков, что вообще-то, дорого.
И т.д.
И еще есть нюансы поведения этих вариантов соединения, в случае неадекватной статистики, и как следствие этого — неправильной оценки кардинальности. И это не считая того, что кардинальность может оцениваться неверно из-за каких то проблем в понимании запроса сервером и т.д.
Короче говоря — увидите в плане merge или hash — не спешите радоваться.
И уж, тем более, пользуясь конструкциями типа inner hash join или option (loop join) нужно понимать, зачем и почему вы это делаете, и почему без этого нельзя обойтись. Тем более, что скорее нужно обойтись.
Хэш-соединение иллюстрированно неверно.
Верная иллюстрация:
Делим скитлз и эмэмдэмс, каждый на 3 кучки: «холодные цвета», «теплые цвета», «нейтральные цвета». В которые сваливаем, соответственно, голубые-зеленые, красные-оранжевые-желтые, и коричневые конфетки. То, что кучки получились разные это нормально, функция хеширования так выбрана. :-)
Потом, каждый элемент каждой кучки последовательно сравниваем с каждым элементом соответствующей кучки, т.е. теплую кучку — с теплой, холодную — с холодной, нейтральную — с нейтральной, и, в случае совпадения цвета — отбираем в результирующую выборку.
Ускорение, в сравнении с nested loop достигается из-за того, что элементы, соответствующие данному, приходится искать не во всём соединяемом множестве, а в относительно узком подмножестве, «теплых цветах», например.
Но, зато обе кучи, скитлз и эмэмдемс необходимо предварительно просмотреть и разделить на «предварительные» кучки, на что тратится силы, время, и место.
Выигрыша по скорости в сравнением с merge — нету, но для merge на входе нужна уже предварительно отсортированная выборка.
Кстати, merge тоже неверно иллюстрирована.
Верная иллюстрация выглядит так:
Предположим, конфетки у нас уже отсортированы в линеечку, рядом друг с другом, в соответствие с правилом радуги, ну или палитрой художника.
Тогда соединять кучки можно одним движением руки, просто сгребая две рядом стоящие линейки одного цвета.
То, что они отсортированы — сильно облегчает дело, т.к. видно, где заканчивается один цвет, и начинается другой.
А в чем проблема? Ну из дыр и из дыр. Из заряженных дыр.
ОТО не запрещает дыре иметь заряд. Лептонный, барионный, кварковый.
И, соответственно, взаимодействие этих дыр определяется их зарядами.
:-)
А если таблицу Turnover хранить как кластерный секционированный колумнстор, не быстрее ли выйдет? Или, скажем так, не универсальнее ли в плане создания прочих, не представленных в примере запросов?
К тому же, если у вас энтерпрайз, он секции колумнстора еще и параллельно сканировать будет.
В 2014, правда, придется немного помучиться с загрузкой, например — грузить в отсоединенную секцию, а потом делать ее свитч в основную таблицу, но, в принципе, нечего особо страшного. Зато вся аналитика — мгновенна без ухищрений.
А почему бы не воспользоваться extended events?
Эвенты нормально создаются с помощью T-SQL.
И, соответственно, запустить/остановить сбор информации можно обычными средствами — заданием агента, например.
Кстати, я не понял, в чем подвох первой задачи?
Старое доброе сравнение id уже не работает (id левой записи > id правой) в join уже не работает?
Что там имелось ввиду то?
В порядке легкого троллинга собеседователей. :-)
На T-SQL:
if OBJECT_ID ('tempdb..#t') is not null
drop table #t
Create table #t (N int)
insert into #t (N)
Values (1), (2), (4), (6), (100)
;With s as
(Select 1 N
Union all
Select N+1 from s
Where N < any (Select N from #t))
Select * from s
except
Select * from #t
Option (maxrecursion 0)
А почему
datetime
datetime2
smalldatetime timestamp сопоставляются timestamp without time zone?
timestamp в MSSQLSERVER — ни разу не дата/время!
timestamp
Тип данных timestamp является синонимом типа данных rowversion и подчиняется правилам поведения синонимов типов данных. В инструкциях на языке описания данных DDL по возможности используйте rowversion вместо timestamp. Дополнительные сведения см. в статье Синонимы типов данных (Transact-SQL).
Тип данных Transact-SQL timestamp отличается от типа данных timestamp, определенного в стандарте ISO.
Примечание
Синтаксис timestamp является нерекомендуемым. Этот компонент находится в режиме обслуживания и может быть удален в будущей версии Microsoft SQL Server. Избегайте использования этого компонента в новых разработках и запланируйте изменение существующих приложений, в которых он применяется.
Вообще, в MSSQLSERVER — все манипуляции с датой и временем — только через функции даты и времени.
Нет, застарелые олдфаги еще помнят, что datetime можно привести к float, и что-то там делать, например — округлить:
SELECT CAST(FLOOR(CAST(GETDATE() AS FLOAT)) AS DATETIME)
Но тем, кто помоложе, гадостям учиться не надо. Не окупается.
Т.к. нет продуктов распада урана, плутония и трансурановых элементов.
Ну, точнее они есть, но в следовых количествах.
Например, в советских промышленных термоядерных зарядах степень «выгорания» плутония превышала 90%, при том, что собственно плутония там было менее 100 грамм.
А нейтронный поток лишь активирует окружающие легкие элементы, которые становятся радиоактивными на кратчайший срок.
Какой такой «бомбовый пик»?
И, кстати, заметьте, первое ядерное испытание — это 1945 год, а промышленные ядерные устройства — 1980. Т.е. 35 лет всего. Мгновение.
Еще один забавный момент.
Практически достоверно известно, что ЮАР провела 2 ядерных испытания в период разработки ЯО.
Но никто не знает, где и как.
А это было менее 40 лет назад.
Это к вопросу обнаружения отдаленных последствий взрыва.
:-)
Выступлю адвокатом дьявола :-)
Достаточно отнести «ядерную цивилизацию» в ледниковый период, т.е. 110-10 тыс. лет назад.
В то время уровень океана был на от 20 до 200 м ниже современного, так что все прибрежные города, и, вся промышленность сейчас находятся на 200 метровой глубине под слоем донных отложений.
Даже сейчас подавляющее число городов находятся в прибрежной полосе 100 км, а уж 100-10 тыс. лет назад, когда цивилизация в современном смысле могла существовать лишь в узкой полосе вдоль экватора… Короче, всё утонуло.
С ядерными бомбами тоже всё просто :-)
Забыли «чисто-термоядерное» оружие, т.е. такое, которое требует либо минимального количества плутония для инициации термоядерного взрыва, от 10 до 100 граммов.
Например, они использовались в СССР при промышленных взрывах.
Кстати, современные заряды как раз и содержат менее 0,5 кг плутония на устройство, так что современный ядерный конфликт, если таковой случится, будет как раз «криптоядерным», с т.з. аргументов статьи, разумеется. Ну, если не затронут АЭС, конечно.
В криптоисторики и любителя теории заговоров меня записывать не надо :-)
Это из любви к искусству, т.с.
Рабство в Северной Америке перестало быть экономически эффективным только в 30х годах ДВАДЦАТОГО века (подчеркиваю — 20-го), после изобретения широкозахватных комбайнов.
По этой теме существует скандальное исследование одного американского ученого.
Так что рассуждения про рабство — в ту же топку, что рассуждения про Гракхов, которые добились абсолютно одинакового [не]успеха, как уже указывали выше.
А вот каждый лист каждой библии Иоганна Гуттенберга — абсолютно уникален.
И, помнится кто-то (из великих, не помню кто) искал скрытые сообщения в особенностях шрифта.
Были DAT-кассеты
Не знаю, как там всё было устроено, но, возможно, задачу можно решить вообще без программирования, используя надстройку PowerQuery (не путать с PowerPivot).
Вложенные циклы — вообще самый лёгкий, производительный и универсальный вариант соединения. Но на небольших объемах данных.
И, кстати, в версии 6.0 — 7.0, если мне память не изменяет, только он и был.
Но благодаря некоторым трюкам, как то организация хэш-таблиц, битмап-индексов, предварительной сортировке данных, на БОЛЬШИХ выборках удается получит выигрышь во времени выборки… за счет чего-то.
Например, построение хэш таблиц — очень охочее до процессора мероприятие, и MSSQLSERVER считает его дорогим и применяет неохотно.
Соединение слиянием требует отсортированных входящих потоков, что вообще-то, дорого.
И т.д.
И еще есть нюансы поведения этих вариантов соединения, в случае неадекватной статистики, и как следствие этого — неправильной оценки кардинальности. И это не считая того, что кардинальность может оцениваться неверно из-за каких то проблем в понимании запроса сервером и т.д.
Короче говоря — увидите в плане merge или hash — не спешите радоваться.
И уж, тем более, пользуясь конструкциями типа inner hash join или option (loop join) нужно понимать, зачем и почему вы это делаете, и почему без этого нельзя обойтись. Тем более, что скорее нужно обойтись.
Как то так.
Верная иллюстрация:
Делим скитлз и эмэмдэмс, каждый на 3 кучки: «холодные цвета», «теплые цвета», «нейтральные цвета». В которые сваливаем, соответственно, голубые-зеленые, красные-оранжевые-желтые, и коричневые конфетки. То, что кучки получились разные это нормально, функция хеширования так выбрана. :-)
Потом, каждый элемент каждой кучки последовательно сравниваем с каждым элементом соответствующей кучки, т.е. теплую кучку — с теплой, холодную — с холодной, нейтральную — с нейтральной, и, в случае совпадения цвета — отбираем в результирующую выборку.
Ускорение, в сравнении с nested loop достигается из-за того, что элементы, соответствующие данному, приходится искать не во всём соединяемом множестве, а в относительно узком подмножестве, «теплых цветах», например.
Но, зато обе кучи, скитлз и эмэмдемс необходимо предварительно просмотреть и разделить на «предварительные» кучки, на что тратится силы, время, и место.
Выигрыша по скорости в сравнением с merge — нету, но для merge на входе нужна уже предварительно отсортированная выборка.
Кстати, merge тоже неверно иллюстрирована.
Верная иллюстрация выглядит так:
Предположим, конфетки у нас уже отсортированы в линеечку, рядом друг с другом, в соответствие с правилом радуги, ну или палитрой художника.
Тогда соединять кучки можно одним движением руки, просто сгребая две рядом стоящие линейки одного цвета.
То, что они отсортированы — сильно облегчает дело, т.к. видно, где заканчивается один цвет, и начинается другой.
Как то так :-)
ОТО не запрещает дыре иметь заряд. Лептонный, барионный, кварковый.
И, соответственно, взаимодействие этих дыр определяется их зарядами.
:-)
К тому же, если у вас энтерпрайз, он секции колумнстора еще и параллельно сканировать будет.
В 2014, правда, придется немного помучиться с загрузкой, например — грузить в отсоединенную секцию, а потом делать ее свитч в основную таблицу, но, в принципе, нечего особо страшного. Зато вся аналитика — мгновенна без ухищрений.
Эвенты нормально создаются с помощью T-SQL.
И, соответственно, запустить/остановить сбор информации можно обычными средствами — заданием агента, например.
Гулиа. В поисках энергетической капсулы.
n-t.ru/ri/gl/ek.htm
Басподобно. Волшебно. Физично.
Любимая книга моего детства.
Ну… Митсуми классик уже не продается :-(
Старое доброе сравнение id уже не работает (id левой записи > id правой) в join уже не работает?
Что там имелось ввиду то?
На T-SQL:
Можно и что-то более идиотское придумать.
qaru.site/questions/1294542/what-is-the-equivalent-of-timestamprowversion-sql-server-with-postgresql
datetime
datetime2
smalldatetime
timestamp сопоставляются timestamp without time zone?
timestamp в MSSQLSERVER — ни разу не дата/время!
Тип данных Transact-SQL timestamp отличается от типа данных timestamp, определенного в стандарте ISO.
Примечание
Синтаксис timestamp является нерекомендуемым. Этот компонент находится в режиме обслуживания и может быть удален в будущей версии Microsoft SQL Server. Избегайте использования этого компонента в новых разработках и запланируйте изменение существующих приложений, в которых он применяется.
docs.microsoft.com/ru-ru/sql/t-sql/functions/getdate-transact-sql?view=sql-server-2017
Вообще, в MSSQLSERVER — все манипуляции с датой и временем — только через функции даты и времени.
Нет, застарелые олдфаги еще помнят, что datetime можно привести к float, и что-то там делать, например — округлить:
SELECT CAST(FLOOR(CAST(GETDATE() AS FLOAT)) AS DATETIME)
Но тем, кто помоложе, гадостям учиться не надо. Не окупается.