Может поможете? У детей на Ipad был установлен клиент на дом с Алисой. И у обоих он перестал отвечать по - русски. Т.е распознование речи переключен на английский. Как-то вернуть назад можно? Я бы хотел, что бы дети говорили по русски с кем то :)
Светодиоды нагреваются очень несущественно: после тридцатиминутного прогрева температура отрезка ленты, наклеенной на стальную пластину, не превышает 34 градусов, этот же отрезок без какой-либо подложки за полчаса нагрелся до 46 градусов. Такую ленту можно использовать без теплоотвода.
Это сильно зависит от частоты, которая используется в диммере. (Возможно блока питания так же, если мощность недостаточная, то она не нагревается ) Возможно без диммера вообще это так же так.
НО я проверил минуту назад и для диммера на частоте 8000 Hz она нагревается до 60С за одну минуту. Дальше я ее выключил :)
Мы ведь не верим, что все ящики на кухне будут открыты одновременно? поэтом запас 20% наверное избыточен на видео видно ,что лента светит черезчур ярко и мне кажется, что лента 4,8-9,6Вт/м была бы предпочтительней. и в принципе все в этом проекте выполнено по верхней границе. Но вот скажите, зачем здесь использовать дорогущие Модули Wb-led? Если никакой автоматизации здесь не предусмотрено. Я бы мог остановится на ультра слим электромагнитные реле с алиэкспресс по цене 1$ за штуку. ПРи этом они могут использовать герконы как и нормально открытые так и нормально закрытые, т.е и на герконах бы сэкономили.
Будем честны 1С это в основном OLTP нагрузка и параллелизм ей часто противопоказан. Поэтому я бы сразу начинал с повышения порогового значения затрат для параллелизма cost threshold for parallelism особенно если у вас высокое значение ожидания SOS_SCHEDULER_YIELD
У тебя всегда будет имя констреинта, который сработал Ну и кто тебе мешает использовать Use of Detailed Error Handling в самом SQL? Опять жеж в разных движках баз данных бывают разные синтетические сахара, для примера PostgreSQL есть ON CONFLICT решений просто море
>>Если обсудить недостатки этого метода, то они таковы:
Возможны проблемы с производительностью при относительно высокой задержке.
Common, Это сколько же новых пользователей вы собираетесь в секунду привлекать?
>> Частое выполнение запросов SELECT для проверки уникальности имен пользователей, и каждый запрос потребляет ресурсы базы данных, включая ресурсы процессора и ввода-вывода. Иными словами, нагрузка на базу данных м.б. чрезмерна.
Никто для этого SELECT не использует. Добавьте CONSTRAINT - и вы получите эксепшн, что запись не уникальна, а т.к для этого используется индекс, что чтение будет ничтожно.
>> Низкая масштабируемость, т.к. базы данных имеют ограничения на количество одновременных подключений.
Вы уже используете приложение, которое имеет подключение к базе данных.
И если вы будете использовать клиент, как точку контроля уникальности, а таких клиентов будет несколько - вот здесь вас ждет развлечение.
С чувством времени ЧАТ'у еще нужно учиться. Человек с яблоками наврядли сделает ляп и если они только цветут, то не могут их уже собрать... раве что размышление заняло вечность
Я понимаю зачем автор статьи использует этот хинт, но в Enterprise версии сервера он не нужен. Во всех остальных да, его необходимо указывать, что бы Сиквел использовал вьюшку, зря что ли мы ее создавали? :)
На самом деле димамический SQL сильно помогает бороться с пунктом 6 (Оператоты OR and IN) и резко сокращает сложность запроса и время его выполнения. Да писать его сложно, сопровождать еще сложнее, но порой без него (особенно в различных веб приложениях с множественными фильтрами) жизнь немыслима :)
Ну это ведь неправда... Настолько неправда, что пришлось быстро тест подготовить.
Имеем не самую большую таблицу(примерно 400 млн записей):
SELECT count(*) FROM [dbo].[SourceProviders] WITH (NOLOCK)
--393222888
ну и сам тест:
CREATE TABLE tempdb.dbo.SourceProviders1 ([StagingProviderID] [bigint] CONSTRAINT [PK_SourceProviders1] PRIMARY KEY CLUSTERED ([StagingProviderID] ASC))
GO
SET STATISTICS TIME ON
PRINT '--1 pre-created table --'
INSERT INTO tempdb.dbo.SourceProviders1
SELECT [StagingProviderID]
FROM [dbo].[SourceProviders]
GO
PRINT '-- END 1 --'
PRINT '--2 Select Into table --'
SELECT [StagingProviderID]
INTO tempdb.dbo.SourceProviders2
FROM [dbo].[SourceProviders] WITH (TABLOCK)
GO
CREATE CLUSTERED INDEX IX_SourceProviders2_SourceProviders ON tempdb.dbo.SourceProviders2 ([StagingProviderID] ASC)
WITH (
MAXDOP = 8
,sort_in_tempdb = ON
)
GO
PRINT '-- END 2 --'
Результат:
--1 pre-created table --
SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times: CPU time = 367485 ms, elapsed time = 496638 ms.
(393222888 rows affected) SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 1 ms. -- END 1 --
SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. --2 Select Into table --
SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times: CPU time = 200172 ms, elapsed time = 89096 ms.
(393222888 rows affected) SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times: CPU time = 406719 ms, elapsed time = 82332 ms. SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 0 ms. -- END 2 --
SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms.
Если в этой таблице создавать еще кластерный индекс, то выигрыш через SELECT INTO будет еще на один порядок больше чем через таблицу с кластерным индексом
В любом случае, у нас есть кейс, в котором испльзование SELECT INTO предпочтительней исходя из времени. Т.е у нас появляются варианты когда мы хотим использовать один или другой подход. И это то место, где универсализм неуместен
Как по мне очень глупый поинт. Если индекс не монотонно возрастающий, то добро пожаловать в сплит страниц. (Никому не пожелаю в высоконагруженных приложениях)
Может поможете?
У детей на Ipad был установлен клиент на дом с Алисой. И у обоих он перестал отвечать по - русски. Т.е распознование речи переключен на английский. Как-то вернуть назад можно? Я бы хотел, что бы дети говорили по русски с кем то :)
Светодиоды нагреваются очень несущественно: после тридцатиминутного прогрева температура отрезка ленты, наклеенной на стальную пластину, не превышает 34 градусов, этот же отрезок без какой-либо подложки за полчаса нагрелся до 46 градусов. Такую ленту можно использовать без теплоотвода.
Это сильно зависит от частоты, которая используется в диммере. (Возможно блока питания так же, если мощность недостаточная, то она не нагревается )
Возможно без диммера вообще это так же так.
НО я проверил минуту назад и для диммера на частоте 8000 Hz она нагревается до 60С за одну минуту. Дальше я ее выключил :)
Мы ведь не верим, что все ящики на кухне будут открыты одновременно? поэтом запас 20% наверное избыточен
на видео видно ,что лента светит черезчур ярко и мне кажется, что лента 4,8-9,6Вт/м была бы предпочтительней.
и в принципе все в этом проекте выполнено по верхней границе.
Но вот скажите, зачем здесь использовать дорогущие Модули Wb-led? Если никакой автоматизации здесь не предусмотрено.
Я бы мог остановится на ультра слим электромагнитные реле с алиэкспресс по цене 1$ за штуку. ПРи этом они могут использовать герконы как и нормально открытые так и нормально закрытые, т.е и на герконах бы сэкономили.
Мне одному кажется, что блок питания в два раза превышает необходимую мощность?
У Google как у Microsoft 15 продуктов.
Мне кажется их Chat больше похож на Skype чем Meet
Мне интересней такое же испытание, но в верхней границе диапазона
как в вашей спецификации объявляется +80°C
Можно?
.
Будем честны 1С это в основном OLTP нагрузка и параллелизм ей часто противопоказан. Поэтому я бы сразу начинал с повышения порогового значения затрат для параллелизма cost threshold for parallelism особенно если у вас высокое значение ожидания SOS_SCHEDULER_YIELD
Если не сложно, подскажите так же что за датчик "входной группы и ступенек" тот что по пересечению
Спасибо
Не из коробки, но несложно через Add-Ons
У меня не получилось ни через outlook ни через google. Зато на почту яндекса пришел код моментально
У тебя всегда будет имя констреинта, который сработал
Ну и кто тебе мешает использовать Use of Detailed Error Handling в самом SQL?
Опять жеж в разных движках баз данных бывают разные синтетические сахара, для примера PostgreSQL есть ON CONFLICT
решений просто море
>>Если обсудить недостатки этого метода, то они таковы:
Возможны проблемы с производительностью при относительно высокой задержке.
Common, Это сколько же новых пользователей вы собираетесь в секунду привлекать?
>> Частое выполнение запросов
SELECTдля проверки уникальности имен пользователей, и каждый запрос потребляет ресурсы базы данных, включая ресурсы процессора и ввода-вывода. Иными словами, нагрузка на базу данных м.б. чрезмерна.Никто для этого SELECT не использует. Добавьте CONSTRAINT - и вы получите эксепшн, что запись не уникальна, а т.к для этого используется индекс, что чтение будет ничтожно.
>> Низкая масштабируемость, т.к. базы данных имеют ограничения на количество одновременных подключений.
Вы уже используете приложение, которое имеет подключение к базе данных.
И если вы будете использовать клиент, как точку контроля уникальности, а таких клиентов будет несколько - вот здесь вас ждет развлечение.
С чувством времени ЧАТ'у еще нужно учиться.
Человек с яблоками наврядли сделает ляп и если они только цветут, то не могут их уже собрать... раве что размышление заняло вечность
Отличная ссылка. Спасибо!
Я понимаю зачем автор статьи использует этот хинт, но в Enterprise версии сервера он не нужен. Во всех остальных да, его необходимо указывать, что бы Сиквел использовал вьюшку, зря что ли мы ее создавали? :)
На самом деле димамический SQL сильно помогает бороться с пунктом 6 (Оператоты OR and IN) и резко сокращает сложность запроса и время его выполнения.
Да писать его сложно, сопровождать еще сложнее, но порой без него (особенно в различных веб приложениях с множественными фильтрами) жизнь немыслима :)
Ну это ведь неправда...
Настолько неправда, что пришлось быстро тест подготовить.
Имеем не самую большую таблицу(примерно 400 млн записей):
ну и сам тест:
Результат:
Итого 500000 ms против примерно 200000 ms
Если в этой таблице создавать еще кластерный индекс, то выигрыш через SELECT INTO будет еще на один порядок больше чем через таблицу с кластерным индексом
В любом случае, у нас есть кейс, в котором испльзование SELECT INTO предпочтительней исходя из времени.
Т.е у нас появляются варианты когда мы хотим использовать один или другой подход. И это то место, где универсализм неуместен
В скорости вставки.
SELECT INTO гораздо быстрей если вы накладываете эксклюзивную блокировкиу на читающую таблицу
Как по мне очень глупый поинт. Если индекс не монотонно возрастающий, то добро пожаловать в сплит страниц. (Никому не пожелаю в высоконагруженных приложениях)
Извините, я о пункте 6 хотел написать... Ошибочный copy\past