рекурсивный запрос на такую глубину быстро превращается в нечитаемое месиво
Да ладно, что там нечитаемого-то? преобразуем список рёбер в список полных квалифицированных путей, а там любая задача решается по щелчку пальцев простейшим поиском по шаблону, или, в худшем случае, поиском максимальной общей подстроки. Да, с оптимальностью может быть плоховато, но вот с читаемостью запроса всё в порядке.
Ааа... то есть то, что в описании графа закодировано как SOURCE / DESTINATION, на самом деле есть NODE_1 / NODE_2, а вот уже в тексте запроса задаётся направление отношения. Ну тогда это получается вполне логично - для ненаправленных графов. И требует соответствующей внимательности для направленных, ибо контроль не просто отсутствует, а в принципе синтаксически невозможен.
Судя по структуре хранения вершин и рёбер выше, не содержащих никаких ограничений, поддерживаются кратные и циклические рёбра (петля). А для ненаправленного графа придётся ребро описывать дважды, с различающимися направлениями.
И, поскольку граф есть надстройка над таблицами, на этом уровне вообще никаких констрейнтов не предусмотрено.
как читать направление
То есть получается, что направление задаётся дважды. В структуре - существующее, в запросе.. ммм.. ну, скажем, требуемое. И они обязаны совпадать - иначе будет какая-нибудь бяка типа syntax error или ещё чего. Так, что ли? Если да - то избыточно и странно. А если нет - нужно бы по этому моменту отдельное пояснение.
То есть мало того, что узаконивается звонковый спам, так ещё он теперь обязан будет сопровождаться спамом СМСовским? Вот уж воистину не оскудеет земля русская идиотами.
Прочитал.. Если откровенно - этот процесс надо бы назвать словом "продрался". Ну просто-таки поток неструктурированного сознания. Даже понимая, о чём речь, приходится потратить много внимания, чтобы полностью понять сделанное. И в конце концов оказывается, что статья посвящена решению ну абсолютно стандартной задачи по поиску компонент связности.
В процессе разработки мы протестировали два алгоритма для поиска таких дублирующихся групп
А почему только эти? тем более в PostgreSQL, где есть несколько альтернативных подходов, для которых в СУБД имеются достаточно эффективные средства.
Здесь важен не точный синтаксис SQL, а скорее сам процесс.
Для того, чтобы понять этот самый "скорее сам процесс", синтаксис - ВАЖЕН. Та ерунда, которая приведена как код, не имеет вообще никакого смысла - во-первых, из-за интерференции имён полей, что при отсутствии алиасов превращает код в бардак, во-вторых, из-за отсутствия исходных структур хранения данных. Плюс некоторые тонкости, важные для решения задачи, просто не озвучены - например, причины использования то UNION ALL, то UNION DISTINCT.
Ещё я бы дополнительно обратил внимание на цвет "железочек" для изъятия модуля из разъёма. У "одноглазых" модулей они разного цвета (например, зелёный и синий, или голубой и розовый) - в зависимости от того, какая длина волны Rx, а какая Tx. А у "двуглазых" одной модели - как правило, одинаковые.
Я бы сказал, что "жёлтый/белый". Белые встречаются и используются довольно часто, и порой более предпочтительны, ибо обычно у них допустим меньший радиус изгиба.
Бывают случаи, когда подключают MM оптику с SM-модулями.
Неудачная, даже непонятная, фраза. Видимо, имеется в виду "подключают SM-модули MM-патчкордами".
Ошибка №2. Неправильная длина волны
На иллюстрации в области для "1490nm Single-mode" изображён явно одноглазик.
Ошибка №3. Два одинаковых WDM модуля
На иллюстрации - двуглазики. Тогда как вы ещё в статье часть 3 указывали, что WDM работают на разных длинах волн по одному волокну.
К слову, я лично не видел двуглазиков с разными длинами волн..
Особенно обидно, когда на патч-корде стоит защелка и нужно пальцы сломать, чтобы её расщелкнуть.
Вы имеете в виду дуплексные кабели, где пара разъёмов удерживается вместе дополнительной защёлкой? Это да, вынимая разъёмы из защёлки, порой можно даже повредить кабель. Особенно если это SC-дуплекс - там защёлки дубовые, правда, они состоят из двух деталей и рассчитаны на то, что будут сниматься инструментом, а не голыми пальцами, и действительно, тонкая отвёртка или канцелярский резак сильно облегчают её снятие.
Или вы имеете в виду фиксатор разъёма, который удлиняют и делают в форме горбика/треугольника, облегчая вроде бы подключения-отключения, в случае, когда этот фиксатор ломается посередине и "задняя" половинка падает под переднюю, превращаясь в защёлку и затрудняя изъятие разъёма? С таким тоже пару раз сталкивался - ох, и матерился, вынимая.. помогает только аккуратная обрезка этой заклинивающей половинки канцелярским резаком или тонкими кусачками.
Коллеги, какие самые странные проблемы с SFP встречались у вас?
У меня самой странной была проблема, когда один SFP+ модуль (из 8 совершенно одинаковых) прекрасно работал в первом слоте двухпортовой серверной карты, но напрочь отказался работать во втором. Вот даже идей никаких, почему такое может быть, посему и разбираться не стал.
Такая архитектура позволяет передавать данные из технологического сегмента сети и сохранить физический и логический разрыв между цехом и офисом.
Ну если логический разрыв на этой схеме я ещё худо-бедно могу себе представить (точнее, представить могу, в виде двойной безадресной однонаправленной трансляции, но вот видеть - не вижу), то что вы разумеете под физическим разрывом, я вообще не понимаю.
Увы, но у меня как-то нет желания впрягаться в этот воз (а тут нужно или по-серьёзному впрягаться, или вообще не лезть, чтобы не получилось чего непотребного). К тому же структурные претензии заведомо разведут книгу и курс. Нам бы что попроще - контакт, куда можно заслать список того, что считаешь требующим рихтовки, а дальше пусть автор думает, прислушаться или проигнорировать..
Книга произвела весьма приятное впечатление. Язык простой и понятный. Хотя терминологические и даже структурные претензии (по счастью, в подавляющем большинстве своём - минорного характера) имеются.
Курс не смотрел - там требуется регистрация, а я не любитель лишних регистраций.
Из-за этого плоский формат требует постоянной ручной доработки.
Позволю себе не согласиться. Все три описанные проблемы - это явно проблемы на присылающей стороне. Причём если последние две - результат неправильно выбранного формата ячеек, то откуда взялась первая и что она есть, я вообще не понимаю, её просто не должно существовать. И вместо того, чтобы надавать менеджеру по шее за некачественную работу, вы предлагаете по-тихому исправить все допущенные им косяки, и пусть его халтурит дальше.
Чтобы добиться такой же стабильности внутри хранимой процедуры на SQL, придется писать обработчик ошибок
Это ещё зачем?
просто автоматически заменит проблемные места на NaN и спокойно зальет таблицу дальше
А вот это уже плохо. Получается, что скрипт по-тихому, никому не сообщая, сохраняет на сервере заведомо некорректные данные. ИМХО единственное правильное поведение в случае любой погрешности - это пропуск импорта проблемной записи с занесением её исходных данных в соотв. лог. Совсем хорошо - копирование "сырых" данных в специально предназначенную для этого таблицу. А если данные имеют внутренние ссылки, то процесс вообще должен быть остановлен до устранения выявленных проблем в исходных данных.
Ручные манипуляции с CSV ломают структуру данных на первом же текстовом поле, где внутри ячейки окажутся обычные запятые или кавычки.
Ну это заведомо неверное утверждение. Будь так - CSV не был бы стандартным средством переноса информации. Все текстовые поля (а при необходимости - вообще все поля) оборачиваются в кавычки, а кавычки внутри значения удваиваются либо экранируются - и никаких проблем ни с запятыми, ни с кавычками.
Заставлять Linux-сервер бд тратить процессорное время на парсинг внутри хранимых процедур - значит положить СУБД при росте нагрузок.
Описанная вами процедура - одноразовая. Это не однотипные запросы, которые летят от кучи клиентов большим и непредсказуемым потоком. Посему опасности "положить сервер" просто нет. Вот если бы импортировался, не приведи господи, XML, тогда да - процедура парсинга и импорта в MySQL тяжёлая и крайне по памяти прожорливая (кто импортировал ФИАС - знает).
И учтите ещё один момент. Сервер БД специально приспособлен и оптимизирован для пакетной обработки данных, его собственно для этого и создавали. А уж по производительности и имеющимся ресурсам он вообще кроет клиента как бык овцу. К тому же передача одного CSV и передача набора записей - это несколько различающиеся нагрузки на сетевую подсистему.
PS. К слову - а как ваш скрипт поведёт себя, если передаваемые данные содержат минорные форматные погрешности?
Моё личное мнение - много лишнего. Уже ж гарантированно есть два достаточно мощных инструмента - MySQL и Excel, которых более чем достаточно для решения задачи, так какой великий смысл наворачивать ещё кучу инструментов (pandas, sqlalchemy и openpyxl)? Особенно если их (а то ещё и python до кучи) в системе изначально не имеется. Хотя надо-то всего лишь в Excel (вручную либо VBA-процедурой) пересохранить файл в CSV, или загрузить данные из того же формата, а с конвертацией в обе стороны (и созданием таблицы при необходимости) прекрасно справится достаточно несложная хранимая процедура на MySQL.
Пожалуйста, отформатируйте нормально тексты запросов - сейчас они совершенно нечитаемы.
Для авто поиска уязвимых финансовых полей
По-моему, попытка отбирать поля по подстроке в имени поля - весьма неудачное решение. Да и причина объявления "неудачным" типа данных INT также совершенно непонятна.
И да, "автопоиск" - это одно слово, а не два.
Поиск изолированных таблиц
А вот зависшие "острова" таблиц такая метода не найдёт. Зато найдёт и подсветит таблицы-справочники, хранилище строк для работы мультиязычного интерфейса и прочие самостоятельные и независимые источники данных.
В процессе тестирования часто создаются временные таблицы (temp_users, debug_table). Их накатывают на базу, а после успешного деплоя забывают удалить.
Вре́менные таблицы автоматически удаляются после закрытия соединения, в котором они были созданы.
Но даже если вы говорите о статических таблицах, созданных для технических целей и не нужных на этапе эксплуатации, то всё равно весьма странно, почему бы почистить их от записей озаботились, а удалить - нет. Тут скорее следовало бы ожидать "или всё, или ничего".
По-моему, автор сделала абсолютно всё, чтобы показывать и объяснять что угодно, но только не утверждение, сформулированное в самом начале. Нет, я понимаю, если бы исходное утверждение было бы сложно или вообще невозможно воплотить на практике, но что может быть проще воды, текущей в изогнутой стеклянной трубке? Да, возникли бы определённые сложности с измерением давления, но они вполне решаемы. Но вместо (условно) несжимаемой жидкости (воды) почему-то используется то электроток, то очень хорошо сжимаемый воздух, а когда дело дошло-таки до воды, то трубку взяли ну очень малопрозрачную..
Да ладно, что там нечитаемого-то? преобразуем список рёбер в список полных квалифицированных путей, а там любая задача решается по щелчку пальцев простейшим поиском по шаблону, или, в худшем случае, поиском максимальной общей подстроки. Да, с оптимальностью может быть плоховато, но вот с читаемостью запроса всё в порядке.
Ааа... то есть то, что в описании графа закодировано как SOURCE / DESTINATION, на самом деле есть NODE_1 / NODE_2, а вот уже в тексте запроса задаётся направление отношения. Ну тогда это получается вполне логично - для ненаправленных графов. И требует соответствующей внимательности для направленных, ибо контроль не просто отсутствует, а в принципе синтаксически невозможен.
Судя по структуре хранения вершин и рёбер выше, не содержащих никаких ограничений, поддерживаются кратные и циклические рёбра (петля). А для ненаправленного графа придётся ребро описывать дважды, с различающимися направлениями.
И, поскольку граф есть надстройка над таблицами, на этом уровне вообще никаких констрейнтов не предусмотрено.
То есть получается, что направление задаётся дважды. В структуре - существующее, в запросе.. ммм.. ну, скажем, требуемое. И они обязаны совпадать - иначе будет какая-нибудь бяка типа syntax error или ещё чего. Так, что ли? Если да - то избыточно и странно. А если нет - нужно бы по этому моменту отдельное пояснение.
17 машин. По 3 патча. 51 конец. Пополам - не делится. Невозможно.
То есть мало того, что узаконивается звонковый спам, так ещё он теперь обязан будет сопровождаться спамом СМСовским? Вот уж воистину не оскудеет земля русская идиотами.
Прочитал.. Если откровенно - этот процесс надо бы назвать словом "продрался". Ну просто-таки поток неструктурированного сознания. Даже понимая, о чём речь, приходится потратить много внимания, чтобы полностью понять сделанное. И в конце концов оказывается, что статья посвящена решению ну абсолютно стандартной задачи по поиску компонент связности.
А почему только эти? тем более в PostgreSQL, где есть несколько альтернативных подходов, для которых в СУБД имеются достаточно эффективные средства.
Для того, чтобы понять этот самый "скорее сам процесс", синтаксис - ВАЖЕН. Та ерунда, которая приведена как код, не имеет вообще никакого смысла - во-первых, из-за интерференции имён полей, что при отсутствии алиасов превращает код в бардак, во-вторых, из-за отсутствия исходных структур хранения данных. Плюс некоторые тонкости, важные для решения задачи, просто не озвучены - например, причины использования то UNION ALL, то UNION DISTINCT.
Ещё я бы дополнительно обратил внимание на цвет "железочек" для изъятия модуля из разъёма. У "одноглазых" модулей они разного цвета (например, зелёный и синий, или голубой и розовый) - в зависимости от того, какая длина волны Rx, а какая Tx. А у "двуглазых" одной модели - как правило, одинаковые.
Я бы сказал, что "жёлтый/белый". Белые встречаются и используются довольно часто, и порой более предпочтительны, ибо обычно у них допустим меньший радиус изгиба.
Неудачная, даже непонятная, фраза. Видимо, имеется в виду "подключают SM-модули MM-патчкордами".
На иллюстрации в области для "1490nm Single-mode" изображён явно одноглазик.
На иллюстрации - двуглазики. Тогда как вы ещё в статье часть 3 указывали, что WDM работают на разных длинах волн по одному волокну.
К слову, я лично не видел двуглазиков с разными длинами волн..
Вы имеете в виду дуплексные кабели, где пара разъёмов удерживается вместе дополнительной защёлкой? Это да, вынимая разъёмы из защёлки, порой можно даже повредить кабель. Особенно если это SC-дуплекс - там защёлки дубовые, правда, они состоят из двух деталей и рассчитаны на то, что будут сниматься инструментом, а не голыми пальцами, и действительно, тонкая отвёртка или канцелярский резак сильно облегчают её снятие.
Или вы имеете в виду фиксатор разъёма, который удлиняют и делают в форме горбика/треугольника, облегчая вроде бы подключения-отключения, в случае, когда этот фиксатор ломается посередине и "задняя" половинка падает под переднюю, превращаясь в защёлку и затрудняя изъятие разъёма? С таким тоже пару раз сталкивался - ох, и матерился, вынимая.. помогает только аккуратная обрезка этой заклинивающей половинки канцелярским резаком или тонкими кусачками.
У меня самой странной была проблема, когда один SFP+ модуль (из 8 совершенно одинаковых) прекрасно работал в первом слоте двухпортовой серверной карты, но напрочь отказался работать во втором. Вот даже идей никаких, почему такое может быть, посему и разбираться не стал.
Ну если логический разрыв на этой схеме я ещё худо-бедно могу себе представить (точнее, представить могу, в виде двойной безадресной однонаправленной трансляции, но вот видеть - не вижу), то что вы разумеете под физическим разрывом, я вообще не понимаю.
Увы, но у меня как-то нет желания впрягаться в этот воз (а тут нужно или по-серьёзному впрягаться, или вообще не лезть, чтобы не получилось чего непотребного). К тому же структурные претензии заведомо разведут книгу и курс. Нам бы что попроще - контакт, куда можно заслать список того, что считаешь требующим рихтовки, а дальше пусть автор думает, прислушаться или проигнорировать..
Угу, прощайте, кастомные настройки, пользовательские переменные, вре́менные таблицы, и всё прочее со scope=connection.
Книга произвела весьма приятное впечатление. Язык простой и понятный. Хотя терминологические и даже структурные претензии (по счастью, в подавляющем большинстве своём - минорного характера) имеются.
Курс не смотрел - там требуется регистрация, а я не любитель лишних регистраций.
И не понял, что делает в списке тегов SQLite.
Ну вообще-то объёма, а не массы. Сохранение ещё и массы - всего лишь следствие несжимаемости, т.е. постоянства плотности.
Позволю себе не согласиться. Все три описанные проблемы - это явно проблемы на присылающей стороне. Причём если последние две - результат неправильно выбранного формата ячеек, то откуда взялась первая и что она есть, я вообще не понимаю, её просто не должно существовать. И вместо того, чтобы надавать менеджеру по шее за некачественную работу, вы предлагаете по-тихому исправить все допущенные им косяки, и пусть его халтурит дальше.
Это ещё зачем?
А вот это уже плохо. Получается, что скрипт по-тихому, никому не сообщая, сохраняет на сервере заведомо некорректные данные. ИМХО единственное правильное поведение в случае любой погрешности - это пропуск импорта проблемной записи с занесением её исходных данных в соотв. лог. Совсем хорошо - копирование "сырых" данных в специально предназначенную для этого таблицу. А если данные имеют внутренние ссылки, то процесс вообще должен быть остановлен до устранения выявленных проблем в исходных данных.
Ну это заведомо неверное утверждение. Будь так - CSV не был бы стандартным средством переноса информации. Все текстовые поля (а при необходимости - вообще все поля) оборачиваются в кавычки, а кавычки внутри значения удваиваются либо экранируются - и никаких проблем ни с запятыми, ни с кавычками.
Описанная вами процедура - одноразовая. Это не однотипные запросы, которые летят от кучи клиентов большим и непредсказуемым потоком. Посему опасности "положить сервер" просто нет. Вот если бы импортировался, не приведи господи, XML, тогда да - процедура парсинга и импорта в MySQL тяжёлая и крайне по памяти прожорливая (кто импортировал ФИАС - знает).
И учтите ещё один момент. Сервер БД специально приспособлен и оптимизирован для пакетной обработки данных, его собственно для этого и создавали. А уж по производительности и имеющимся ресурсам он вообще кроет клиента как бык овцу. К тому же передача одного CSV и передача набора записей - это несколько различающиеся нагрузки на сетевую подсистему.
PS. К слову - а как ваш скрипт поведёт себя, если передаваемые данные содержат минорные форматные погрешности?
Моё личное мнение - много лишнего. Уже ж гарантированно есть два достаточно мощных инструмента - MySQL и Excel, которых более чем достаточно для решения задачи, так какой великий смысл наворачивать ещё кучу инструментов (pandas, sqlalchemy и openpyxl)? Особенно если их (а то ещё и python до кучи) в системе изначально не имеется. Хотя надо-то всего лишь в Excel (вручную либо VBA-процедурой) пересохранить файл в CSV, или загрузить данные из того же формата, а с конвертацией в обе стороны (и созданием таблицы при необходимости) прекрасно справится достаточно несложная хранимая процедура на MySQL.
Точечный впрыск красителя позволит пронаблюдать динамику движения жидкости. И траекторию, и скорость.
Какое это имеет отношение к статье?
Как и почему - я знаю. Но если у автора было желание рассказать и показать наглядно, то эта затея, имхо, с треском провалена.
Пожалуйста, отформатируйте нормально тексты запросов - сейчас они совершенно нечитаемы.
По-моему, попытка отбирать поля по подстроке в имени поля - весьма неудачное решение. Да и причина объявления "неудачным" типа данных INT также совершенно непонятна.
И да, "автопоиск" - это одно слово, а не два.
А вот зависшие "острова" таблиц такая метода не найдёт. Зато найдёт и подсветит таблицы-справочники, хранилище строк для работы мультиязычного интерфейса и прочие самостоятельные и независимые источники данных.
Вре́менные таблицы автоматически удаляются после закрытия соединения, в котором они были созданы.
Но даже если вы говорите о статических таблицах, созданных для технических целей и не нужных на этапе эксплуатации, то всё равно весьма странно, почему бы почистить их от записей озаботились, а удалить - нет. Тут скорее следовало бы ожидать "или всё, или ничего".
По-моему, автор сделала абсолютно всё, чтобы показывать и объяснять что угодно, но только не утверждение, сформулированное в самом начале. Нет, я понимаю, если бы исходное утверждение было бы сложно или вообще невозможно воплотить на практике, но что может быть проще воды, текущей в изогнутой стеклянной трубке? Да, возникли бы определённые сложности с измерением давления, но они вполне решаемы. Но вместо (условно) несжимаемой жидкости (воды) почему-то используется то электроток, то очень хорошо сжимаемый воздух, а когда дело дошло-таки до воды, то трубку взяли ну очень малопрозрачную..
Не шутка ни разу. Сейчас красиво материться без подсказок мало кто умеет..