ну поехали.... В первом пункте сначала говорите про избыточность, потом приводите довольно неудачный пример, который может быть совсем не про избыточность (если номера не уникальны)... Ну и потом еще фразы: " мы разбиваем таблицу на части или делаем декомпозицию, приводя таким образом таблицу к нормальной форме" и "декомпозиция - это одна из вариаций нормализации"... Декомпозиция это не вариация нормализации, а всего лишь инструмент, а читая ваш текст создается впечатление что разбить данные на таблицы = нормализация...
Так MongoDB может выигрывать у PostrgeSQL в запросах, которые подразумевают много связей и за которыми постгрес полезет в другие таблицы
Тут вы отождествляете РСУБД и реляционную модель данных, что немного не верно... А если в реляционной СУБД хранить данные в не нормализованном виде, скажем в 1 таблице id и json с объектом, тогда уже не надо лазить по таблицам и все становится не так однозначно...
Транзакция - это элементарная операция в базе данных. Однако транзакция может состоять и из нескольких операций
Что? Транзакция - не элементарная операция, а атомарная тогда уж...
Повлиять на скорость выполнения запроса можно различными способами. Я запомнил их так: изменить зам sql-запрос, обновить статистику планировщика, денормализация и 4 вариации изменения параметров планировщика:
и дальше не 4, а 7 пунктов частично повторяющих только что сказанное... Обновление статистики - это какая-то разовая оптимизация, это вопрос регламентного обслуживания или вы предлагаете перед каждым запросом обновлять статистику?
денормализация: создание временных таблиц или создание индексов
Вы уверены что это про денормализацию?
изменение параметров планировщика...
Слышал про такое... ) На практике ни разу не приходилось вмешиваться в работу планировщика (правда это были не postgresql), обычно планировщик лучше знает как ему выбирать данные, а все проблемы решаются исправлением своих рук и мозгов
Какие есть концепции масштабируемости БД Я всегда выделял 2 основных.
Ожидал сейчас прочитать: вертикальное и горизонтальное, а тут...
SELECT в интернетах выполняются во много раз чаще, чем INSERT'ы, на этом фоне репликация выглядит привлекательнее
не увидел прямой связи...
Все выше сказанное относится к теме "Повышение отказоустойчивости"
да ну? а я знаю примеры решающие задачи оптимизации и даже репликации для ограничения доступа в другой сетевой сегмент.
Я рекомендую её к прочтению разработчикам любого уровня
Прям не знаю... книга такая плохая или вы недопоняли материал...
Ужасные объяснения, вы сами перечитывали свое сумбурное повествование? Вот например абзац:
Давайте посмотрим, как теперь сортировка слиянием разбивает массив.
Теперь? Что-то изменилось, я что то пропустил?
Когда алгоритм сортировки слиянием задается в массиве,
алгоритм задается в массиве?
первое, что он делает, это берет этот массив и разбивает его на составляющие его наименьшие части, поэтому он берет каждый элемент этого массива и создает массив самого себя,
Помимо корявых фраз, непонятно, что такое массив самого себя?
в основном путем непрерывного деления на два, пока он не сократит этот массив до наименьших элементов (отдельных чисел) в массиве.
А не в основном? Несколько раз перечитал абзац - ничего не понял... Уж простите за докапывание, но ведь это всего лишь объяснения базовых алгоритмов...
Вот и все, друзья, которых вы только что покорили и только что прошлись по всем основным алгоритмам сортировки.
трёхмесячный курс по обучению профессии IT-архитектора
принимаются студенты бакалавриата 3-4 курсов, 1-2 курсов магистратуры и выпускники технической, экономической или IT-специальности
Кандидат на поступление должен понимать, что такое low-code платформа, хорошо знать математику и владеть основами программирования в купе с английским языком
научатся создавать приложения на low-code BPM-платформе
Но «привет», по моему мнению, будет уместно в любом случае. Даже если после будет «вы».
По мне так немного странно: Привет, вы бы...
У меня был случай, когда система заглючила, и рассылка 50 кандидатам ушла без имен.
Вам стало стыдно только когда вы спалились с автоматической рассылкой? А пока система работает исправно, то все нормально? Для чего это все притворство???
Некоторые примеры из моего опыта, которые получили неплохой отклик.
Я Дина, ИТ рекрутер. Нам, рекрутерам не всегда везет с настроением адресатов) Я искренне надеюсь, у вас сегодня замечательный день, как минимум обычный, но если вдруг что-то пошло не так и все идет наперекосяк, не переживайте, в итоге все точно будет хорошо!
По мне так это просто напрягающая, пустая болтовня из которой даже не понятно что тут хотели закреативить. Креатив конечно может расположить к себе, но он должен быть лаконичный и понятным, буквально, например, пошутить одной фразой... Думаю со мной многие it-шники согласятся, т.к. это люди в основном прагматичные.
И все то у вас хорошо и красиво, и минусов то никаких нет... Это просто Павел со своим сынком не хотят терять свои пригретые местечки....
Если что, я никакого отношения к вашему Павлу не имею, просто не понятно почему вы так все описали однобоко? Почему микросервисы? Какую задачу они решают в конкретной организации? Какова цена (я не про деньги)?
Польза лидирующей запятой точно такая же как и вред (ну либо польза от лидирующей такая же как от завершающающей), разница только в том когда мы словами ошибку, при удалении первого поля в запросе, либо последнего...
Но если Вам нужно именно выключить, то всё будет еще короче, а именно 47 байт. Просто вторая строка будет выглядеть:
shutdown -s -t 00
Зачем заменять вторую строку, если вы сами же в ней и указываете параметр -t. Просто укажите «shutdown -s -t 1200» без первой строки. Таким образом «программа» стала еще короче.
Можно, кстати, вместо TInterfacedObject использовать базовый класс без подсчёта ссылок и рулить памятью вручную, никто не запрещал.
но при этом истратить на это единственную возможность отнаследоваться.
Любой из обходных путей не дает в Delphi нормально пользоваться интерфейсами. А решение могло быть таким простым: голый Interface и унаследованный от него какой-нибудь ComInterface с подсчетом ссылок. Поэтому и возникает вопрос кто это сделал??? Почему желая использовать интерфейсы я вынужден зависеть от не нужной мне функциональности.
Мне кажется с интерфейсами в delphi сделали какой то ужас… Вот тебе Делфи с ручным управлением памятью и вот тебе на… интерфейсы с подсчетом ссылок и с ними тебе надо работать по другому, не так как ты работаешь обычно с классами… Вот это полиморфизм, вот это тебе все ваши эти ООП… Кто это сотворил?
Создалось впечатление что вы ловите каждую минуту что бы использовать ее с пользой для саморазвития себя в профессиональной сфере. Ну ок, но:
1. Не все люди такие фанатики как вы и это не значит что они плохие специалисты. Самое здесь плохое что вы ровняете всех по себе и при этом упрекаете их за это!
2. Почему вы решили что расширение кругозора это изучение проф информации? Кто то читает классику, путешествует, катается на лыжах, наблюдает за звездами,…
3. И нет, черт возьми, я не хочу катаясь на лыжах, или при поездки с работы, слушать проф. информацию, я хочу отдохнуть, подумать о чем то другом. Люди свободны и у них может быть куча других интересов и забот…
4. И никто не обязан развиваться в свое личное время, поэтому, как минимум, предъявлять им за это вы не имеете право. Время на развитие должен выделять работодатель, т.к. это и в его интересах.
5. Есть мнение (особенно в наше время), что не надо перегружать себя информацией… Почитал/послушал что то, необходимо сделать паузу, мозг должен переработать ее в фоновом режиме.
P.S. И нет, я не из тех кто не развивается и сидит на попе ровно, я так же нахожу время(в том числе и свое личное) для саморазвития в проф. сфере, но ваши суждения мне не понятны.
Объяснение:
7-я метка должна быть помещена в квадрат 5, который является выигрышной ситуацией как для X, так и для O. Следовательно, 6-я метка должна быть помещена в линию, уже содержащую две метки противников. Есть две такие возможности – 6-я отметка была бы либо О в квадрате 7, либо Х в квадрате 9.
Поскольку мы знаем, что оба игрока достаточно умны, 6-я отметка не может быть О в квадрате 7. Вместо этого он поместил бы О в квадрат 5 и выиграл бы.
Следовательно, шестая метка должна быть X, помещенная в квадрат 9. И седьмым ходом будет О. Таким образом, О выиграет игру.
Все так, но если уходить дальше в прошлое, то ни один из вариантов развития не является логичным с точки зрения одного из игроков. Поэтому либо они поумнели на последних шагах, либо, как я и говорил, такая расстановка никак не могла получится, и в любом случае задача не имеет однозначного решения.
Соглашусь с решением только если приведете полную партию по шагам (естественно с точки зрения достаточно умных игроков)
задача найти алгоритм, с помощью которого можно корректировать поведение программы
Если ИИ знает какой ему предстоит путь и что он не сможет вовремя произвести замену, лучше сделать это заранее, тем самым он сможет скорректировать график замены позже, и «добить» недоезженный ресурс на более коротких отрезках пути.
По сути алгоритм тот же, необходимо тратить ресурс покрышек равномерно на всех, по очереди, период замены можно менять:
если не добили какой то из периодов и известно что потребуется проехать не больше чем этот остаток то:
добиваем этот период на тех же колесах, на которых недоездили тот период
в противном случае оставляем на потом и начинаем новый цикл:
до замены осталось = остаток ресурса покрышки с максимальном износом / 4
если произвели досрочную замену на первой итерации в цикле:
можно провести замены в цикле с той же периодичностью, что и эту
Таким образом недоезженные периоды будут все время уменьшаться, т.е. минимизироваться не оптимальный случай
Ну так и вы туда же не скатывайтесь. В MS SQL тоже вполне себе "оптимизатор запросов" и джобы...
ну поехали....
В первом пункте сначала говорите про избыточность, потом приводите довольно неудачный пример, который может быть совсем не про избыточность (если номера не уникальны)...
Ну и потом еще фразы: " мы разбиваем таблицу на части или делаем декомпозицию, приводя таким образом таблицу к нормальной форме" и "декомпозиция - это одна из вариаций нормализации"... Декомпозиция это не вариация нормализации, а всего лишь инструмент, а читая ваш текст создается впечатление что разбить данные на таблицы = нормализация...
Тут вы отождествляете РСУБД и реляционную модель данных, что немного не верно... А если в реляционной СУБД хранить данные в не нормализованном виде, скажем в 1 таблице id и json с объектом, тогда уже не надо лазить по таблицам и все становится не так однозначно...
Что? Транзакция - не элементарная операция, а атомарная тогда уж...
и дальше не 4, а 7 пунктов частично повторяющих только что сказанное...
Обновление статистики - это какая-то разовая оптимизация, это вопрос регламентного обслуживания или вы предлагаете перед каждым запросом обновлять статистику?
Вы уверены что это про денормализацию?
Слышал про такое... ) На практике ни разу не приходилось вмешиваться в работу планировщика (правда это были не postgresql), обычно планировщик лучше знает как ему выбирать данные, а все проблемы решаются исправлением своих рук и мозгов
Ожидал сейчас прочитать: вертикальное и горизонтальное, а тут...
не увидел прямой связи...
да ну? а я знаю примеры решающие задачи оптимизации и даже репликации для ограничения доступа в другой сетевой сегмент.
Прям не знаю... книга такая плохая или вы недопоняли материал...
Сочувствую... )
Теперь понятно, только вряд ли будет понятна здесь (для не поляков). Есть предложение пометить это как-то, типа "(местный польский юмор)".
Вы сами переходили по своей ссылке HWDP??? Вы ничего не перепутали?
Ужасные объяснения, вы сами перечитывали свое сумбурное повествование? Вот например абзац:
Теперь? Что-то изменилось, я что то пропустил?
алгоритм задается в массиве?
Помимо корявых фраз, непонятно, что такое массив самого себя?
А не в основном?
Несколько раз перечитал абзац - ничего не понял... Уж простите за докапывание, но ведь это всего лишь объяснения базовых алгоритмов...
Жесть конечно...
расходимся...
По мне так немного странно: Привет, вы бы...
Вам стало стыдно только когда вы спалились с автоматической рассылкой? А пока система работает исправно, то все нормально? Для чего это все притворство???
По мне так это просто напрягающая, пустая болтовня из которой даже не понятно что тут хотели закреативить. Креатив конечно может расположить к себе, но он должен быть лаконичный и понятным, буквально, например, пошутить одной фразой... Думаю со мной многие it-шники согласятся, т.к. это люди в основном прагматичные.
P.S. извините если показался резким
И все то у вас хорошо и красиво, и минусов то никаких нет... Это просто Павел со своим сынком не хотят терять свои пригретые местечки....
Если что, я никакого отношения к вашему Павлу не имею, просто не понятно почему вы так все описали однобоко? Почему микросервисы? Какую задачу они решают в конкретной организации? Какова цена (я не про деньги)?
Польза лидирующей запятой точно такая же как и вред (ну либо польза от лидирующей такая же как от завершающающей), разница только в том когда мы словами ошибку, при удалении первого поля в запросе, либо последнего...
Зачем заменять вторую строку, если вы сами же в ней и указываете параметр -t. Просто укажите «shutdown -s -t 1200» без первой строки. Таким образом «программа» стала еще короче.
p.s. мог бы голосовать, поставил бы вам +
но при этом истратить на это единственную возможность отнаследоваться.
Любой из обходных путей не дает в Delphi нормально пользоваться интерфейсами. А решение могло быть таким простым: голый Interface и унаследованный от него какой-нибудь ComInterface с подсчетом ссылок. Поэтому и возникает вопрос кто это сделал??? Почему желая использовать интерфейсы я вынужден зависеть от не нужной мне функциональности.
1. Не все люди такие фанатики как вы и это не значит что они плохие специалисты. Самое здесь плохое что вы ровняете всех по себе и при этом упрекаете их за это!
2. Почему вы решили что расширение кругозора это изучение проф информации? Кто то читает классику, путешествует, катается на лыжах, наблюдает за звездами,…
3. И нет, черт возьми, я не хочу катаясь на лыжах, или при поездки с работы, слушать проф. информацию, я хочу отдохнуть, подумать о чем то другом. Люди свободны и у них может быть куча других интересов и забот…
4. И никто не обязан развиваться в свое личное время, поэтому, как минимум, предъявлять им за это вы не имеете право. Время на развитие должен выделять работодатель, т.к. это и в его интересах.
5. Есть мнение (особенно в наше время), что не надо перегружать себя информацией… Почитал/послушал что то, необходимо сделать паузу, мозг должен переработать ее в фоновом режиме.
P.S. И нет, я не из тех кто не развивается и сидит на попе ровно, я так же нахожу время(в том числе и свое личное) для саморазвития в проф. сфере, но ваши суждения мне не понятны.
Все так, но если уходить дальше в прошлое, то ни один из вариантов развития не является логичным с точки зрения одного из игроков. Поэтому либо они поумнели на последних шагах, либо, как я и говорил, такая расстановка никак не могла получится, и в любом случае задача не имеет однозначного решения.
Соглашусь с решением только если приведете полную партию по шагам (естественно с точки зрения достаточно умных игроков)
Если предположить, что оба игрока достаточно умны, то я не могу представить ситуации, при которой поле могло оказаться в такой конфигурации…
В том числе
Если ИИ знает какой ему предстоит путь и что он не сможет вовремя произвести замену, лучше сделать это заранее, тем самым он сможет скорректировать график замены позже, и «добить» недоезженный ресурс на более коротких отрезках пути.
По сути алгоритм тот же, необходимо тратить ресурс покрышек равномерно на всех, по очереди, период замены можно менять:
если не добили какой то из периодов и известно что потребуется проехать не больше чем этот остаток то:
добиваем этот период на тех же колесах, на которых недоездили тот период
в противном случае оставляем на потом и начинаем новый цикл:
до замены осталось = остаток ресурса покрышки с максимальном износом / 4
если произвели досрочную замену на первой итерации в цикле:
можно провести замены в цикле с той же периодичностью, что и эту
Таким образом недоезженные периоды будут все время уменьшаться, т.е. минимизироваться не оптимальный случай