Хотелось бы получить ссылки на заявления и в дальнейшем на иски, а также ссылки в будущем о ходе разбирательств. Это будут факты, а не просто эмоции и личные переписки.
Вопрос в лоб: т е не делалась проверка гипотезы, что с новым индексом будет лучше и что вообще новый индекс будет использоваться?
Здесь проблема значительно шире, а именно что не делается проверка гипотезы в том числе даже если написано так в документации. Нет! Всё нужно перепроверять с учётом специфики системы.
В части 15.1 документации про резервное копирование: https://soqol.ru/dokumentatsiya/ написано, что перед резервным копированием, нужно остановить работу самой базы данных. Но как тогда делать резервное копирование на постоянной основе без простоя? Эта особенность явно не делает данную СУБД конкурентоспособной по отношению к другим известным СУБД, таким как MySQL, PostgreSQL, MS SQL, Oracle и др. Тем более что лицензия платная. Когда примерно планируется реализовать возможность резервного копирования на лету как всей базы данных, так и конкретной дельты-напр, последнего фрагмента журнала транзакций? Ещё бы реализовать возможность непрерывного резервного копирования с возможностью быстрого восстановления на каждый нужный момент времени как это уже реализовано в современных известных СУБД в том числе для реализации отказоустойчивых решений и для быстрой доступности.
А что будет с такими сервисами как gmail? Как работать в андроид? Или у нас уже есть полностью отечественные мобильные устройства с полностью отечественными ОС и ПО, а также с полностью отечественными запчастями к устройствам или хотя бы из дружественных к РФ стран?
Может надо сделать так, что бы все люди мира стремились жить в РФ? По мне так главный показатель благополучия населения во всех сферах, это когда люди со всего мира стремятся жить именно там. А пока...а пока все больше умных покидают страну и остаются все остальные. За редким исключением. Ну это как в шутке: "мы отбираем лучшие зерна, а остальное отправляем вам". И у нас да, все больше мигрантов из Азии со своей культурой и менталитетом, который чужд русским людям. Такими темпами Россия скоро или уже перестанет быть для русских.
По каким критериям будут определять в ИТ работал специалист или нет? Особенно до того как ввели коды должностей и тем более до того как ввели обязанность их проставлять в электронную трудовую книжку.
Интересно, что в голосовании перевалил сильно вариант: "Это положительное технологическое нововведение, которое следует развивать". Стоит задуматься либо у нас общество настолько свободное в своих нравах, либо аморальное.
Поддерживаю, мы сейчас вообще уходим от рекурсивных CTE в пользу развертывания кода по конечному числу итераций. Но в список рекомендаций пока не вошёл, т к должно пройти время после использования подхода для его оценки.
Я не самый авторитетный и мы часто обсуждаем и спорим особенно на ревью решения. Мы просто не ставим авторитетов выше себя: всегда все перепроверяем. В данном случае, книга хорошая, но местами её подходы естественным образом устарели. И добавлю (уже где-то писал): любая книга/публикация и т д есть отражение опыта его/её автора/авторов, а значит заранее ограничена именно опытом конкретных специалистов. Т е где-то материал будет полезен, а где-то не очень. А общая унификация вообще может жить только в вакууме и в реалии весьма вредна. И книги авторитетов не являются исключением.
Вас тоже с праздниками! Данный пример для си-языков, а здесь мы T-SQL рассматриваем. И не смотря на почетную книженцию, в данном примере есть риск, что из цикла можно вообще никогда не выйти. Т е не смотря на авторитет автора и с учетом риска бесконечного зацикливания кода, позволю себе не согласиться. Может раньше так и было можно, а сейчас больше за предсказуемый по выполнению и безопасный код.
Жаль, что не смог Вас убедить. Кстати, CTE тоже лучше на лево и направо не раскидываться особенно если таблицы-участницы большие. Но опять же понятие "большие" относительно.
Понимаю, у всех нагрузка большая. Потому я в основном пишу на выходных. Но в любом случае Ваш материал будет интересно изучить, потому надеюсь и буду ждать публикации. Спасибо!
select 1 показывает, что проблем с производительностью СУБД нет. Значит, все остальные рекомендации про оптимизацию являются неверными раз найдены исключения, опровергающие это.
Хотелось бы получить ссылки на заявления и в дальнейшем на иски, а также ссылки в будущем о ходе разбирательств. Это будут факты, а не просто эмоции и личные переписки.
Когда примерно будет готово?
Вопрос в лоб: т е не делалась проверка гипотезы, что с новым индексом будет лучше и что вообще новый индекс будет использоваться?
Здесь проблема значительно шире, а именно что не делается проверка гипотезы в том числе даже если написано так в документации. Нет! Всё нужно перепроверять с учётом специфики системы.
В части 15.1 документации про резервное копирование: https://soqol.ru/dokumentatsiya/ написано, что перед резервным копированием, нужно остановить работу самой базы данных. Но как тогда делать резервное копирование на постоянной основе без простоя? Эта особенность явно не делает данную СУБД конкурентоспособной по отношению к другим известным СУБД, таким как MySQL, PostgreSQL, MS SQL, Oracle и др. Тем более что лицензия платная. Когда примерно планируется реализовать возможность резервного копирования на лету как всей базы данных, так и конкретной дельты-напр, последнего фрагмента журнала транзакций? Ещё бы реализовать возможность непрерывного резервного копирования с возможностью быстрого восстановления на каждый нужный момент времени как это уже реализовано в современных известных СУБД в том числе для реализации отказоустойчивых решений и для быстрой доступности.
А что будет с такими сервисами как gmail? Как работать в андроид? Или у нас уже есть полностью отечественные мобильные устройства с полностью отечественными ОС и ПО, а также с полностью отечественными запчастями к устройствам или хотя бы из дружественных к РФ стран?
Может надо сделать так, что бы все люди мира стремились жить в РФ? По мне так главный показатель благополучия населения во всех сферах, это когда люди со всего мира стремятся жить именно там. А пока...а пока все больше умных покидают страну и остаются все остальные. За редким исключением. Ну это как в шутке: "мы отбираем лучшие зерна, а остальное отправляем вам". И у нас да, все больше мигрантов из Азии со своей культурой и менталитетом, который чужд русским людям. Такими темпами Россия скоро или уже перестанет быть для русских.
По каким критериям будут определять в ИТ работал специалист или нет? Особенно до того как ввели коды должностей и тем более до того как ввели обязанность их проставлять в электронную трудовую книжку.
Да, лень - двигатель прогресса, а удовольствие - творчества.
Интересно, что в голосовании перевалил сильно вариант: "Это положительное технологическое нововведение, которое следует развивать". Стоит задуматься либо у нас общество настолько свободное в своих нравах, либо аморальное.
Взаимно!
Имелось в виду в общем
Мандарины в голове уже.
С Новым Годом!
Поддерживаю, мы сейчас вообще уходим от рекурсивных CTE в пользу развертывания кода по конечному числу итераций. Но в список рекомендаций пока не вошёл, т к должно пройти время после использования подхода для его оценки.
Я не самый авторитетный и мы часто обсуждаем и спорим особенно на ревью решения. Мы просто не ставим авторитетов выше себя: всегда все перепроверяем. В данном случае, книга хорошая, но местами её подходы естественным образом устарели. И добавлю (уже где-то писал): любая книга/публикация и т д есть отражение опыта его/её автора/авторов, а значит заранее ограничена именно опытом конкретных специалистов. Т е где-то материал будет полезен, а где-то не очень. А общая унификация вообще может жить только в вакууме и в реалии весьма вредна. И книги авторитетов не являются исключением.
Вас тоже с праздниками! Данный пример для си-языков, а здесь мы T-SQL рассматриваем. И не смотря на почетную книженцию, в данном примере есть риск, что из цикла можно вообще никогда не выйти. Т е не смотря на авторитет автора и с учетом риска бесконечного зацикливания кода, позволю себе не согласиться. Может раньше так и было можно, а сейчас больше за предсказуемый по выполнению и безопасный код.
Данный пример опасен тем, что можно просто ошибиться и никогда не выйти из цикла
Так что мелочиться то, сразу goto делать вместо всех циклов for и while во всех языках программирования. Удобно для унификации.
Кстати, не напомните номер страницы книги, где упоминается именно о том, что Вы написали?
Жаль, что не смог Вас убедить. Кстати, CTE тоже лучше на лево и направо не раскидываться особенно если таблицы-участницы большие. Но опять же понятие "большие" относительно.
Понимаю, у всех нагрузка большая. Потому я в основном пишу на выходных. Но в любом случае Ваш материал будет интересно изучить, потому надеюсь и буду ждать публикации. Спасибо!
select 1 показывает, что проблем с производительностью СУБД нет. Значит, все остальные рекомендации про оптимизацию являются неверными раз найдены исключения, опровергающие это.
Тем не менее, union тяжеловат сам по себе. И если есть альтернативы, а они есть, то лучше ими воспользоваться.