Абсолютно всё иначе. При беге корпус наклонен вперёд, чтобы вынести центр тяжести. Бег - это последовательные падения вперёд, предотвращаемые выставлением ноги. А на беговой дорожке падения нет, там просто прыжки вверх.
Вы когда-нибудь видели человека, который, первый раз в жизни встав на беговую дорожку, сразу устойчиво побежал на ней? Мне пока такого видеть не приходилось. А всё потому, что техника другая, а тело пытается бежать, как привыкло. Робота при попытке бежать вперёд, а не на месте, ждёт строго обратная... необходимость приспосабливаться.
Очень интересно, а может он развить такую скорость не на беговой дорожке, а при реальном беге не на шнурке (пусть и по достаточно гладкой поверхности)? Более того - он вообще не на беговой дорожке бегать способен? Там совсем иная техника бега, иное положение корпуса...
Признаться, мне сомнительно. И вообще кажется, что при реальном беге сей робот загремит "голова-ноги" задолго до заветных 10 метров в секунду...
Мой личный опыт говорит о том, что вся проблема - в юзере.
Уже два раза я покупал два абсолютно одинаковых смартфона - себе и супруге. Мой - работает как часы, её - через полгода начинает тормозить, и раз в год нужно менять батарею. Ей и сыну купили два совершенно одинаковых ноута - у сына до сих пор летает, у супруги же - регулярно тормозит, и спасает только полный откат в исходное состояние.
И у меня перед глазами ещё не один и не два аналогичных примера. Так что я лично убеждён - проблема не модели и даже не в экземпляре.
Проверка - выборочная. Метод выбора не указан, т.е. выбирается исполнителем по своему разумению, и полностью случайный - ничем не хуже прочих. Никакого основания не требуется. Будешь настаивать - дождёшься какой-нибудь гадости в свой адрес, вроде "морда мне твоя подозрительная слишком". Кстати, вполне себе нормальное обоснование, пусть и не очень вежливо сформулированное.
36. Досмотр радио- и телеаппаратуры, фото-, видео и киноаппаратуры, аудио- и видеотехники, мобильных телефонов, персональных компьютеров, в дополнение к применению средств досмотра проводится посредством включения и проверки работоспособности.
Но вот что интересно - приказ ну совершенно не говорит о том, что будет в случае, если устройство неработоспособно. А неработоспособность - нигде не указана в качестве причины, запрещающей провоз. То есть если следовать тексту приказа, то проверяющий просто узна́ет, работоспособно устройство или нет, но если оно неработоспобно, то на основании приказа он не может запретить провоз этого устройства.
Т.е. это был контролируемый процесс против неконтролируемого процесса, который происходит в движке СУБД, когда он решает перенести данные.
Не так. Контролируемый кодом против контролируемого движком. И я сторонник как раз того, чтобы контролировала СУБД.
представьте, вы решили секционировать таблицу по статусам. Как вы будете подчищать данные?
Я не понял, что имеется в виду под термином "подчищать". Но если вы имеете в виду удаление, то я этого делать не буду в принципе. А ещё я вспомню о субсекционировании.
Я бы сказал, что аномалии это следствие плохой декомпозиции
Да в том и дело, что автор вместо исследования предметной области и нормализации модели почему-то пытается идти от данных к схеме. Крайне странное мероприятие.
При явном WHERE прошлые периоды сами обрежутся, на то и partition pruning. Главное, чтобы парсер по тексту мог легко понять, что условие отбора (или какая-то его часть) точно соответствует выражению секционирования.
То есть, по-вашему, таскать из одной таблицы в другую - нормально, а из секции в секцию, которые по сути такие же таблицы (у нас же постгресс) - это уже моветон? Вот совсем не понимаю. Зато понимаю, что, как только потребуется что-то без оглядки на статус, придётся лезть в две отдельные таблицы и объединять полученные субнаборы. То есть от двух таблиц, как по мне, никакого профиту и геморрой на горизонте. Да и хранение одной сущности в нескольких таблицах - это ещё меньший best practices, кмк.
Любая БД является моделью некоего процесса, отображением значений и зависимостей характеристик этого процесса. Зависимости в значения данных, о которых вы ведёте речь, являются следствиями зависимостей внутри процесса, который моделируется. В связи с чем стремление "забыть" об исходнике и придумывать эти зависимости только на основе данных модели - по меньшей мере странно и не очень разумно. Хотя бы потому, что объём данных почти наверняка не покрывает область допустимых значений параметров. Собственно изъяны ака аномалии и есть следствие этой неполноты.
И поневоле возникает вопрос - а нафига оно вообще такое надо? К сожалению, именно на этот вопрос ответа в статье я не вижу.
Во-первых, сервер БД работает с данными более эффективно, чем фреймворк - как-никак, он для этого создан. И к тому же он как раз заточен на выполнение пакетных операций. Итерации для него не очень естественны, хотя и вполне возможны.
Во-вторых, вместо двух валидаций (в клиентском коде и затем на стороне СУБД) вы получаете одну. Оформляете её в хранимую процедуру и выполняете, когда потребуется. Не надо ни воркеров, ни листенеров, ни чего-то ещё - послал запрос на выполнение, передав имя исходного файла, и жди готового результата, просто и плоско, как блин. К тому же если потребуется вносить изменения в код - у вас всего одна точка его хранения и выполнения, не надо прыгать с обновлением клиентов на вашем компьютерном зоопарке.
В третьих, вы можете после валидации и вставки, в том же запросе, удалить вставленные данные из такой промежуточной таблицы, и сразу получить набор записей, которые не прошли валидацию и требуют ручной обработки (ну или могут быть использованы иным путём). Или, если валидация показала критически кривые данные, откатить вообще всё нафиг лёгким движением руки, а не трясти бэкапы.
PostgreSQL умеет импортировать CSV-файлы в таблицу простейшим запросом COPY. Причём для исключения проблем импорта (особенно если исходный файл потенциально ну очень кривой и может организовать проблемы вроде несовпадения типов или там кодировок) можно просто тянуть всю строку в один блоб и потом на стороне же SQL парсить. Кстати, именно по причине возможности таких недостатков исходных данных и не советую использовать врапперы для подключения внешнего CSV как таблицы.
А для снижения вероятности блокировок рабочих таблиц - импорт в блоб, парсинг, валидация и вставка в структурную копию рабочей таблицы, вставка обработанных и валидированных данных в рабочую таблицу. Минимум интерференций с другими процессами.
??? Вот сейчас не понял, причём совсем. И, кмк, потому, что вы меня поняли неправильно.
Валидация в питоновском коде у вас есть по-любому, и по-любому же она построчная. Так что в этом вопросе разницы я не вижу вообще - хоть построчно вставляем, хоть пакетами. А вот уже потом отвалидированные на уровне python-кода строки вы вставляете в таблицу, т.е. пересылаете наконец на SQL-сервер. И именно на этой стадии у вас при пакетной вставке появляется то, что вы называете "хрупкостью". И об альтернативной реализации именно этой стадии я и говорю - с одной стороны, вставка выполняется пусть и построчно, но внутри транзакции, следовательно, фиксация вставленных строк будет пакетная, с другой стороны, не прошедшая для отдельных записей валидация на уровне SQL-схемы (констрейнты и внешние ключи) не приводит к отказу от вставки всего пакета, отказ выполняется только для невалидных с точки зрения схемы БД отдельных записей.
К сожалению, Постгресс, в отличие от некоторых других СУБД, безусловно считает транзакцию проваленной и требующей отката, если в ходе выполнения запросов транзакции возникла ошибка, и не допускает мысли, что ошибка при выполнении одного из запросов может быть штатным течением транзакции. Но это можно пофиксить вложенными транзакциями. В SQL-коде это выглядит пусть и монстрообразно, но оно работоспособно.
create table test (id int, check (id < 10));
begin;
begin;
insert into test values (1); -- запись вставляется
commit;
begin;
insert into test values (11); -- ошибка ограничения
commit; -- субтранзакция откатывается
begin;
insert into test values (5); -- запись вставляется
commit;
commit; -- фиксируется вставка 2 записей
select * from test;
Внешняя транзакция коммиттится, сохраняя в таблицу записи со значениями 1 и 5, несмотря на то, что внутри при добавлении записи со значением 11 возникла ошибка - она маскируется откатом вложенной транзакции.
Такой подход позволяет, с одной стороны, выполнять вставку пусть и по одной записи, но внутри транзакции, что может оказаться быстрее, чем простая построчная вставка, и в то же время решить вопрос с невалидными записями.
Будет ли это быстрее или медленнее, чем простая построчная запись - не скажу, а протестировать не на чем. И уж тем более не скажу, будет ли это быстрее из программного кода. Но подход в принципе имеет право на существование.
PS. Например, в MySQL такой подход сильно ускоряет построчную вставку - но там не требуются вложенные транзакции.
Да бред... вот как постоянно включённый VPN у меня может принести описанные проблемы какому-то (да вообще абстрактному) подростку и аннулировать усилия государства?
Абсолютно всё иначе. При беге корпус наклонен вперёд, чтобы вынести центр тяжести. Бег - это последовательные падения вперёд, предотвращаемые выставлением ноги. А на беговой дорожке падения нет, там просто прыжки вверх.
Вы когда-нибудь видели человека, который, первый раз в жизни встав на беговую дорожку, сразу устойчиво побежал на ней? Мне пока такого видеть не приходилось. А всё потому, что техника другая, а тело пытается бежать, как привыкло. Робота при попытке бежать вперёд, а не на месте, ждёт строго обратная... необходимость приспосабливаться.
Очень интересно, а может он развить такую скорость не на беговой дорожке, а при реальном беге не на шнурке (пусть и по достаточно гладкой поверхности)? Более того - он вообще не на беговой дорожке бегать способен? Там совсем иная техника бега, иное положение корпуса...
Признаться, мне сомнительно. И вообще кажется, что при реальном беге сей робот загремит "голова-ноги" задолго до заветных 10 метров в секунду...
Мой личный опыт говорит о том, что вся проблема - в юзере.
Уже два раза я покупал два абсолютно одинаковых смартфона - себе и супруге. Мой - работает как часы, её - через полгода начинает тормозить, и раз в год нужно менять батарею. Ей и сыну купили два совершенно одинаковых ноута - у сына до сих пор летает, у супруги же - регулярно тормозит, и спасает только полный откат в исходное состояние.
И у меня перед глазами ещё не один и не два аналогичных примера. Так что я лично убеждён - проблема не модели и даже не в экземпляре.
Проверка - выборочная. Метод выбора не указан, т.е. выбирается исполнителем по своему разумению, и полностью случайный - ничем не хуже прочих. Никакого основания не требуется. Будешь настаивать - дождёшься какой-нибудь гадости в свой адрес, вроде "морда мне твоя подозрительная слишком". Кстати, вполне себе нормальное обоснование, пусть и не очень вежливо сформулированное.
А чё? Трамваи вон уже на автопилоте ездят же. Да и Буран на автопилоте летал - а было это вообще чёрт те когда...
Нашёл и почитал текст этого приказа.
Но вот что интересно - приказ ну совершенно не говорит о том, что будет в случае, если устройство неработоспособно. А неработоспособность - нигде не указана в качестве причины, запрещающей провоз. То есть если следовать тексту приказа, то проверяющий просто узна́ет, работоспособно устройство или нет, но если оно неработоспобно, то на основании приказа он не может запретить провоз этого устройства.
Не так. Контролируемый кодом против контролируемого движком. И я сторонник как раз того, чтобы контролировала СУБД.
Я не понял, что имеется в виду под термином "подчищать". Но если вы имеете в виду удаление, то я этого делать не буду в принципе. А ещё я вспомню о субсекционировании.
Да в том и дело, что автор вместо исследования предметной области и нормализации модели почему-то пытается идти от данных к схеме. Крайне странное мероприятие.
При явном WHERE прошлые периоды сами обрежутся, на то и partition pruning. Главное, чтобы парсер по тексту мог легко понять, что условие отбора (или какая-то его часть) точно соответствует выражению секционирования.
То есть, по-вашему, таскать из одной таблицы в другую - нормально, а из секции в секцию, которые по сути такие же таблицы (у нас же постгресс) - это уже моветон? Вот совсем не понимаю. Зато понимаю, что, как только потребуется что-то без оглядки на статус, придётся лезть в две отдельные таблицы и объединять полученные субнаборы. То есть от двух таблиц, как по мне, никакого профиту и геморрой на горизонте. Да и хранение одной сущности в нескольких таблицах - это ещё меньший best practices, кмк.
Любая БД является моделью некоего процесса, отображением значений и зависимостей характеристик этого процесса. Зависимости в значения данных, о которых вы ведёте речь, являются следствиями зависимостей внутри процесса, который моделируется. В связи с чем стремление "забыть" об исходнике и придумывать эти зависимости только на основе данных модели - по меньшей мере странно и не очень разумно. Хотя бы потому, что объём данных почти наверняка не покрывает область допустимых значений параметров. Собственно изъяны ака аномалии и есть следствие этой неполноты.
И поневоле возникает вопрос - а нафига оно вообще такое надо? К сожалению, именно на этот вопрос ответа в статье я не вижу.
Почему не секционирование?
SHOW CREATE TABLE не может показать ЭТУ проблему в принципе.
0.04 ms и 40 миллисекунд не одно и то же, они различаются... на 3 порядка.
Угу... сделайте звук на динамике погромче и расположите его поближе к приёмной антенне часов. По-моему, это можно воспринимать только как курьёз.
На самом деле преимущества-то, наверное, имеются.
Во-первых, сервер БД работает с данными более эффективно, чем фреймворк - как-никак, он для этого создан. И к тому же он как раз заточен на выполнение пакетных операций. Итерации для него не очень естественны, хотя и вполне возможны.
Во-вторых, вместо двух валидаций (в клиентском коде и затем на стороне СУБД) вы получаете одну. Оформляете её в хранимую процедуру и выполняете, когда потребуется. Не надо ни воркеров, ни листенеров, ни чего-то ещё - послал запрос на выполнение, передав имя исходного файла, и жди готового результата, просто и плоско, как блин. К тому же если потребуется вносить изменения в код - у вас всего одна точка его хранения и выполнения, не надо прыгать с обновлением клиентов на вашем компьютерном зоопарке.
В третьих, вы можете после валидации и вставки, в том же запросе, удалить вставленные данные из такой промежуточной таблицы, и сразу получить набор записей, которые не прошли валидацию и требуют ручной обработки (ну или могут быть использованы иным путём). Или, если валидация показала критически кривые данные, откатить вообще всё нафиг лёгким движением руки, а не трясти бэкапы.
PostgreSQL умеет импортировать CSV-файлы в таблицу простейшим запросом COPY. Причём для исключения проблем импорта (особенно если исходный файл потенциально ну очень кривой и может организовать проблемы вроде несовпадения типов или там кодировок) можно просто тянуть всю строку в один блоб и потом на стороне же SQL парсить. Кстати, именно по причине возможности таких недостатков исходных данных и не советую использовать врапперы для подключения внешнего CSV как таблицы.
А для снижения вероятности блокировок рабочих таблиц - импорт в блоб, парсинг, валидация и вставка в структурную копию рабочей таблицы, вставка обработанных и валидированных данных в рабочую таблицу. Минимум интерференций с другими процессами.
??? Вот сейчас не понял, причём совсем. И, кмк, потому, что вы меня поняли неправильно.
Валидация в питоновском коде у вас есть по-любому, и по-любому же она построчная. Так что в этом вопросе разницы я не вижу вообще - хоть построчно вставляем, хоть пакетами. А вот уже потом отвалидированные на уровне python-кода строки вы вставляете в таблицу, т.е. пересылаете наконец на SQL-сервер. И именно на этой стадии у вас при пакетной вставке появляется то, что вы называете "хрупкостью". И об альтернативной реализации именно этой стадии я и говорю - с одной стороны, вставка выполняется пусть и построчно, но внутри транзакции, следовательно, фиксация вставленных строк будет пакетная, с другой стороны, не прошедшая для отдельных записей валидация на уровне SQL-схемы (констрейнты и внешние ключи) не приводит к отказу от вставки всего пакета, отказ выполняется только для невалидных с точки зрения схемы БД отдельных записей.
К сожалению, Постгресс, в отличие от некоторых других СУБД, безусловно считает транзакцию проваленной и требующей отката, если в ходе выполнения запросов транзакции возникла ошибка, и не допускает мысли, что ошибка при выполнении одного из запросов может быть штатным течением транзакции. Но это можно пофиксить вложенными транзакциями. В SQL-коде это выглядит пусть и монстрообразно, но оно работоспособно.
Внешняя транзакция коммиттится, сохраняя в таблицу записи со значениями 1 и 5, несмотря на то, что внутри при добавлении записи со значением 11 возникла ошибка - она маскируется откатом вложенной транзакции.
Такой подход позволяет, с одной стороны, выполнять вставку пусть и по одной записи, но внутри транзакции, что может оказаться быстрее, чем простая построчная вставка, и в то же время решить вопрос с невалидными записями.
Будет ли это быстрее или медленнее, чем простая построчная запись - не скажу, а протестировать не на чем. И уж тем более не скажу, будет ли это быстрее из программного кода. Но подход в принципе имеет право на существование.
PS. Например, в MySQL такой подход сильно ускоряет построчную вставку - но там не требуются вложенные транзакции.
Да бред... вот как постоянно включённый VPN у меня может принести описанные проблемы какому-то (да вообще абстрактному) подростку и аннулировать усилия государства?
Эммм... не понял, у кого ИИ - у мойки или у обуви?