Такая архитектура позволяет передавать данные из технологического сегмента сети и сохранить физический и логический разрыв между цехом и офисом.
Ну если логический разрыв на этой схеме я ещё худо-бедно могу себе представить (точнее, представить могу, в виде двойной безадресной однонаправленной трансляции, но вот видеть - не вижу), то что вы разумеете под физическим разрывом, я вообще не понимаю.
Увы, но у меня как-то нет желания впрягаться в этот воз (а тут нужно или по-серьёзному впрягаться, или вообще не лезть, чтобы не получилось чего непотребного). К тому же структурные претензии заведомо разведут книгу и курс. Нам бы что попроще - контакт, куда можно заслать список того, что считаешь требующим рихтовки, а дальше пусть автор думает, прислушаться или проигнорировать..
Книга произвела весьма приятное впечатление. Язык простой и понятный. Хотя терминологические и даже структурные претензии (по счастью, в подавляющем большинстве своём - минорного характера) имеются.
Курс не смотрел - там требуется регистрация, а я не любитель лишних регистраций.
Из-за этого плоский формат требует постоянной ручной доработки.
Позволю себе не согласиться. Все три описанные проблемы - это явно проблемы на присылающей стороне. Причём если последние две - результат неправильно выбранного формата ячеек, то откуда взялась первая и что она есть, я вообще не понимаю, её просто не должно существовать. И вместо того, чтобы надавать менеджеру по шее за некачественную работу, вы предлагаете по-тихому исправить все допущенные им косяки, и пусть его халтурит дальше.
Чтобы добиться такой же стабильности внутри хранимой процедуры на SQL, придется писать обработчик ошибок
Это ещё зачем?
просто автоматически заменит проблемные места на NaN и спокойно зальет таблицу дальше
А вот это уже плохо. Получается, что скрипт по-тихому, никому не сообщая, сохраняет на сервере заведомо некорректные данные. ИМХО единственное правильное поведение в случае любой погрешности - это пропуск импорта проблемной записи с занесением её исходных данных в соотв. лог. Совсем хорошо - копирование "сырых" данных в специально предназначенную для этого таблицу. А если данные имеют внутренние ссылки, то процесс вообще должен быть остановлен до устранения выявленных проблем в исходных данных.
Ручные манипуляции с CSV ломают структуру данных на первом же текстовом поле, где внутри ячейки окажутся обычные запятые или кавычки.
Ну это заведомо неверное утверждение. Будь так - CSV не был бы стандартным средством переноса информации. Все текстовые поля (а при необходимости - вообще все поля) оборачиваются в кавычки, а кавычки внутри значения удваиваются либо экранируются - и никаких проблем ни с запятыми, ни с кавычками.
Заставлять Linux-сервер бд тратить процессорное время на парсинг внутри хранимых процедур - значит положить СУБД при росте нагрузок.
Описанная вами процедура - одноразовая. Это не однотипные запросы, которые летят от кучи клиентов большим и непредсказуемым потоком. Посему опасности "положить сервер" просто нет. Вот если бы импортировался, не приведи господи, XML, тогда да - процедура парсинга и импорта в MySQL тяжёлая и крайне по памяти прожорливая (кто импортировал ФИАС - знает).
И учтите ещё один момент. Сервер БД специально приспособлен и оптимизирован для пакетной обработки данных, его собственно для этого и создавали. А уж по производительности и имеющимся ресурсам он вообще кроет клиента как бык овцу. К тому же передача одного CSV и передача набора записей - это несколько различающиеся нагрузки на сетевую подсистему.
PS. К слову - а как ваш скрипт поведёт себя, если передаваемые данные содержат минорные форматные погрешности?
Моё личное мнение - много лишнего. Уже ж гарантированно есть два достаточно мощных инструмента - MySQL и Excel, которых более чем достаточно для решения задачи, так какой великий смысл наворачивать ещё кучу инструментов (pandas, sqlalchemy и openpyxl)? Особенно если их (а то ещё и python до кучи) в системе изначально не имеется. Хотя надо-то всего лишь в Excel (вручную либо VBA-процедурой) пересохранить файл в CSV, или загрузить данные из того же формата, а с конвертацией в обе стороны (и созданием таблицы при необходимости) прекрасно справится достаточно несложная хранимая процедура на MySQL.
Пожалуйста, отформатируйте нормально тексты запросов - сейчас они совершенно нечитаемы.
Для авто поиска уязвимых финансовых полей
По-моему, попытка отбирать поля по подстроке в имени поля - весьма неудачное решение. Да и причина объявления "неудачным" типа данных INT также совершенно непонятна.
И да, "автопоиск" - это одно слово, а не два.
Поиск изолированных таблиц
А вот зависшие "острова" таблиц такая метода не найдёт. Зато найдёт и подсветит таблицы-справочники, хранилище строк для работы мультиязычного интерфейса и прочие самостоятельные и независимые источники данных.
В процессе тестирования часто создаются временные таблицы (temp_users, debug_table). Их накатывают на базу, а после успешного деплоя забывают удалить.
Вре́менные таблицы автоматически удаляются после закрытия соединения, в котором они были созданы.
Но даже если вы говорите о статических таблицах, созданных для технических целей и не нужных на этапе эксплуатации, то всё равно весьма странно, почему бы почистить их от записей озаботились, а удалить - нет. Тут скорее следовало бы ожидать "или всё, или ничего".
По-моему, автор сделала абсолютно всё, чтобы показывать и объяснять что угодно, но только не утверждение, сформулированное в самом начале. Нет, я понимаю, если бы исходное утверждение было бы сложно или вообще невозможно воплотить на практике, но что может быть проще воды, текущей в изогнутой стеклянной трубке? Да, возникли бы определённые сложности с измерением давления, но они вполне решаемы. Но вместо (условно) несжимаемой жидкости (воды) почему-то используется то электроток, то очень хорошо сжимаемый воздух, а когда дело дошло-таки до воды, то трубку взяли ну очень малопрозрачную..
Честное слово: я многократно пробовал пройти этот квест с помощью нескольких принадлежащих мне телефонных номеров и разных браузеров, результат во всех случаях был одинаковый: регистрация на «Рамблере» не работает.
Странно, что у вас за проблема с неудавшейся авторизацией через СберID. Я без проблем прошёл процесс авторизации. Правда, попробовав создать новый ящик, в самом конце упёрся в плашку, которая вполне открыто и честно сообщает:
Не, ну рассказ в стиле "автомобиль съехал с горки не быстрее велосипеда, а потом мы завелись...". Как по мне - вообще ни о чём, чисто ради плюсадина в публикации.
Весьма оптимистично. Я в жизни с таким сталкивался ровно дважды - и оба раза не то что получать информацию с устройств сети, и уж тем более заниматься их конфигурированием, но даже подключиться к ним не удавалось. Шторм отличается не только избыточным количеством дублирующихся пакетов, но и катастрофическим процентом потерь, при котором интерфейс управления устройством - несбыточная мечта. И приходится начинать именно с разрыва физики.
При чём тут сортировка? Она выполняется безусловно, я же не о ней веду речь-то. Я о том, что блокирование выполняется после сортировки, но в процессе отбора, а не после него. А по завершении отбора, когда записи заблокированы - всё, порядок блокирования утрачен. Настала пора отдавать итоговый результат, с отобранными записями и списком блокировок, наружу. И, поскольку это подзапрос, то отдача записей из него должна обеспечить полноту отобранного набора, но не порядок, который обеспечил внутренний ORDER BY. То есть блокирование записей выполнено в установленном нами порядке, но вот совпадение этого порядка с тем порядком, в котором они будут обрабатываться во внешнем запросе - этой гарантии я не вижу, за исключением физического порядка размещения ссылок в оперативной памяти, чему гарантии я тоже не вижу. То есть мы опираемся не на логику, а на особенность реализации. А это ненадёжно, хотя и работает. Пока что работает..
Впрочем, для первого случая это, наверное, уже неважно. Нам важен порядок блокирования, а не порядок высвобождения.
Ну если логический разрыв на этой схеме я ещё худо-бедно могу себе представить (точнее, представить могу, в виде двойной безадресной однонаправленной трансляции, но вот видеть - не вижу), то что вы разумеете под физическим разрывом, я вообще не понимаю.
Увы, но у меня как-то нет желания впрягаться в этот воз (а тут нужно или по-серьёзному впрягаться, или вообще не лезть, чтобы не получилось чего непотребного). К тому же структурные претензии заведомо разведут книгу и курс. Нам бы что попроще - контакт, куда можно заслать список того, что считаешь требующим рихтовки, а дальше пусть автор думает, прислушаться или проигнорировать..
Угу, прощайте, кастомные настройки, пользовательские переменные, вре́менные таблицы, и всё прочее со scope=connection.
Книга произвела весьма приятное впечатление. Язык простой и понятный. Хотя терминологические и даже структурные претензии (по счастью, в подавляющем большинстве своём - минорного характера) имеются.
Курс не смотрел - там требуется регистрация, а я не любитель лишних регистраций.
И не понял, что делает в списке тегов SQLite.
Ну вообще-то объёма, а не массы. Сохранение ещё и массы - всего лишь следствие несжимаемости, т.е. постоянства плотности.
Позволю себе не согласиться. Все три описанные проблемы - это явно проблемы на присылающей стороне. Причём если последние две - результат неправильно выбранного формата ячеек, то откуда взялась первая и что она есть, я вообще не понимаю, её просто не должно существовать. И вместо того, чтобы надавать менеджеру по шее за некачественную работу, вы предлагаете по-тихому исправить все допущенные им косяки, и пусть его халтурит дальше.
Это ещё зачем?
А вот это уже плохо. Получается, что скрипт по-тихому, никому не сообщая, сохраняет на сервере заведомо некорректные данные. ИМХО единственное правильное поведение в случае любой погрешности - это пропуск импорта проблемной записи с занесением её исходных данных в соотв. лог. Совсем хорошо - копирование "сырых" данных в специально предназначенную для этого таблицу. А если данные имеют внутренние ссылки, то процесс вообще должен быть остановлен до устранения выявленных проблем в исходных данных.
Ну это заведомо неверное утверждение. Будь так - CSV не был бы стандартным средством переноса информации. Все текстовые поля (а при необходимости - вообще все поля) оборачиваются в кавычки, а кавычки внутри значения удваиваются либо экранируются - и никаких проблем ни с запятыми, ни с кавычками.
Описанная вами процедура - одноразовая. Это не однотипные запросы, которые летят от кучи клиентов большим и непредсказуемым потоком. Посему опасности "положить сервер" просто нет. Вот если бы импортировался, не приведи господи, XML, тогда да - процедура парсинга и импорта в MySQL тяжёлая и крайне по памяти прожорливая (кто импортировал ФИАС - знает).
И учтите ещё один момент. Сервер БД специально приспособлен и оптимизирован для пакетной обработки данных, его собственно для этого и создавали. А уж по производительности и имеющимся ресурсам он вообще кроет клиента как бык овцу. К тому же передача одного CSV и передача набора записей - это несколько различающиеся нагрузки на сетевую подсистему.
PS. К слову - а как ваш скрипт поведёт себя, если передаваемые данные содержат минорные форматные погрешности?
Моё личное мнение - много лишнего. Уже ж гарантированно есть два достаточно мощных инструмента - MySQL и Excel, которых более чем достаточно для решения задачи, так какой великий смысл наворачивать ещё кучу инструментов (pandas, sqlalchemy и openpyxl)? Особенно если их (а то ещё и python до кучи) в системе изначально не имеется. Хотя надо-то всего лишь в Excel (вручную либо VBA-процедурой) пересохранить файл в CSV, или загрузить данные из того же формата, а с конвертацией в обе стороны (и созданием таблицы при необходимости) прекрасно справится достаточно несложная хранимая процедура на MySQL.
Точечный впрыск красителя позволит пронаблюдать динамику движения жидкости. И траекторию, и скорость.
Какое это имеет отношение к статье?
Как и почему - я знаю. Но если у автора было желание рассказать и показать наглядно, то эта затея, имхо, с треском провалена.
Пожалуйста, отформатируйте нормально тексты запросов - сейчас они совершенно нечитаемы.
По-моему, попытка отбирать поля по подстроке в имени поля - весьма неудачное решение. Да и причина объявления "неудачным" типа данных INT также совершенно непонятна.
И да, "автопоиск" - это одно слово, а не два.
А вот зависшие "острова" таблиц такая метода не найдёт. Зато найдёт и подсветит таблицы-справочники, хранилище строк для работы мультиязычного интерфейса и прочие самостоятельные и независимые источники данных.
Вре́менные таблицы автоматически удаляются после закрытия соединения, в котором они были созданы.
Но даже если вы говорите о статических таблицах, созданных для технических целей и не нужных на этапе эксплуатации, то всё равно весьма странно, почему бы почистить их от записей озаботились, а удалить - нет. Тут скорее следовало бы ожидать "или всё, или ничего".
По-моему, автор сделала абсолютно всё, чтобы показывать и объяснять что угодно, но только не утверждение, сформулированное в самом начале. Нет, я понимаю, если бы исходное утверждение было бы сложно или вообще невозможно воплотить на практике, но что может быть проще воды, текущей в изогнутой стеклянной трубке? Да, возникли бы определённые сложности с измерением давления, но они вполне решаемы. Но вместо (условно) несжимаемой жидкости (воды) почему-то используется то электроток, то очень хорошо сжимаемый воздух, а когда дело дошло-таки до воды, то трубку взяли ну очень малопрозрачную..
Не шутка ни разу. Сейчас красиво материться без подсказок мало кто умеет..
Странно, что у вас за проблема с неудавшейся авторизацией через СберID. Я без проблем прошёл процесс авторизации. Правда, попробовав создать новый ящик, в самом конце упёрся в плашку, которая вполне открыто и честно сообщает:
Дипфэйк умершего родственника? ну да, это можно считать жизнью, наверное..
Пропущен пункт в голосовании, с формулировкой типа "SO для людей трансформируется в SO для агентов".
Уже сейчас SO гораздо менее интересен. Действительно качественных вопросов кот наплакал.
Не, ну рассказ в стиле "автомобиль съехал с горки не быстрее велосипеда, а потом мы завелись...". Как по мне - вообще ни о чём, чисто ради плюсадина в публикации.
Когда - не скажу. Но вот только с чего ты думаешь, что если оно закончится, то именно так, как ты хочешь?
Весьма оптимистично. Я в жизни с таким сталкивался ровно дважды - и оба раза не то что получать информацию с устройств сети, и уж тем более заниматься их конфигурированием, но даже подключиться к ним не удавалось. Шторм отличается не только избыточным количеством дублирующихся пакетов, но и катастрофическим процентом потерь, при котором интерфейс управления устройством - несбыточная мечта. И приходится начинать именно с разрыва физики.
А это отдельно.
Интересно, совпадает ли список излишне (до OFFSET) заблокированных записей в случаях:
и
Или во втором случае избытка не будет?
При чём тут сортировка? Она выполняется безусловно, я же не о ней веду речь-то. Я о том, что блокирование выполняется после сортировки, но в процессе отбора, а не после него. А по завершении отбора, когда записи заблокированы - всё, порядок блокирования утрачен. Настала пора отдавать итоговый результат, с отобранными записями и списком блокировок, наружу. И, поскольку это подзапрос, то отдача записей из него должна обеспечить полноту отобранного набора, но не порядок, который обеспечил внутренний ORDER BY. То есть блокирование записей выполнено в установленном нами порядке, но вот совпадение этого порядка с тем порядком, в котором они будут обрабатываться во внешнем запросе - этой гарантии я не вижу, за исключением физического порядка размещения ссылок в оперативной памяти, чему гарантии я тоже не вижу. То есть мы опираемся не на логику, а на особенность реализации. А это ненадёжно, хотя и работает. Пока что работает..
Впрочем, для первого случая это, наверное, уже неважно. Нам важен порядок блокирования, а не порядок высвобождения.