1) Я как раз про дополнительную обработку всего и вся рекурсивно, включая select секцию и не только.
2) Синтаксис Oracle SQL, PL/SQL в стандартном наборе действительно стал значительно лучше в последнее время. Только я не вижу некоторых новых конструкции из Oracle 12c (навскидку WITH_PLSQL, MATCH_RECOGNIZE). А между прочим расширенная поддержка 11g заканчивается уже в этом месяце.
Я вообще к чему это всё, инструмент — рабочий, общую картину увидеть позволяет. Но к сожалению от 10% до 30% связей мы не увидим. Частично из-за старой граматики (это как раз исправимо, пиши граматику сам), а вот проблема с динамическим кодом неразрешима.
В итоге получается, что инструменту на 100% доверять нельзя и всё-равно приходится посмотривать весь код глазами. Поиграться — да, надёжный инструмент — нет.
У Информатики даже продукт готовый есть за много тысяч долларов — Metadata Manager, увы, с той же степенью надёжности.
В случае с Oracle, если код в хранимых процедурах, то гораздо проще пользоваться таблицей ALL_DEPENDENCIES (пролема с динамикой остаётся). Если код в SVN, то только ANTRL.
Писал аналогичный скрипт для PL/SQL на Python. Подскажите, как решались проблемы с:
1) Сложными конструкциями в блоках select и for
2) Устаревшим синтаксисом в стандартном наборе ANTRL
В CS вице президент, он же VP — менеджер среднего звена, под ним только AVP и обычные работники. У Credit Suisse около 50 тыс. работников, не могут они быть все перечислены на сайте.
Основная проблема в получении ГК — это работодатель, который будет готов запариться по этому поводу а так же гора документов, которые у вас должны быть, кроме того их надо собрать и перевести.
Так вот при переезде из, например, Чехии в Германию (или куда вы там хотите) вам всё это надо будет начинать заново, начиная с работодателя и заканчивая переводами.
Плюс наличия ГК только в том, что вы будет проще ездить на собеседования.
Могла бы быть плюсом возможность отработать в одной стране допустим 3 года, потом в другой (например в Германии) ещё 2, итого 5 и сразу получить постоянный вид на жительства во второй стране. Это изначально заявлялось как преимущество ГК, но на практике такая возможность не работает. В частности с Германией на данный момент не работает.
Кроме весьма сомнительных плюсов есть и минусы, такие как минимальная зарплата. Для сеньёр ИТ специалистов это не проблема, а вот для джунов и даже мидлов это может стать проблемой. Проблема может возникнуть не только при устройстве на работу, но и при смене работы, на позицию с небольшой зарплатой, вы просто не сможете пойти.
Для кого-то это очевидно, но возможно не для всех. Вам дают ГК (как и ВНЖ по работе) только при условии, что вы работаете. Если вы увольняетесь, то вы должны в течение определённого срока (скажем месяц) найти другую работу соответствующую всем условиям или уехать домой. Вы привязаны к работе.
Про профильное образование — тут уже писали. Иногда даже наличия диплома не достаточно.
В целом, идея то здравая, но практика показывает, что на данный момент система с ГК работает не так, как многим бы хотелось. Тем не менее работает и в реальности ± соответствует временному ВНЖ.
По-моему, Оракл — изначально неверный выбор БД для мэйл сервиса. Я себе слабо представляю, за счёт чего можно окупить энтерпрайз версию на бесплатном почтовом сервисе. Оракл — надёжный, удобный и быстрый — спору нет, но мне кажется, что с помощью хорошей архитектуры изначально можно было реализовать продукт соответствующий всем требованиям хорошего мэйл сервиса используя более дешёвые компоненты.
— Легаси кода — много
— Даже если вы пишите что-то новое — вы всё-равно должны интегрироваться с легаси системами.
— Передовые технологии используются редко, в банках отдают предпочтение проверенным временем и надёжным вещам.
— Проекты большие, кому-то всё-равно придётся передавать данные с БД клиенту.
— Что надо делать диктует бизнес, они заказывают музыку, пишут музыку аналитики — вы её играете.
Меня расстраивает, когда тюнингом называют замену колпаков и других элементов кузова. Я понимаю, что это слово прижилось в определённых кругах.
Даже в IT среде это слово означает тонкую настройку и как правило связано с повышением производительности и вряд ли кто-то рефакторинг будет называть тюнингом кода.
Это называется «Магия» а не решение проблемы. Вы где-то полазили, что-то поменяли, это кажется помогло. В чём на самом деле была причина вы не разобрались и лечили симптомы.
Во всех высокоразвитых странах высокие налоги, часто шкала прогрессивная, чем больше зарабатываете, тем больше ставка налога. Поэтому, если вас интересуют только деньги, то переезжать куда-либо не стоит (максимум в свою столицу). Уровень зарплат обычно коррелирует со стоимостью жизни. Например высокие ИТ зарплаты в долине, Лондоне и Швейцарии компенсируются огромными ценами буквально на всё в округе.
Жаловаться на высокие налоги в сочетании с хорошими дорогами, высоким уровнем безопасности и развитой инфраструктурой как минимум глупо.
Систему можно попробовать обмануть работая удалённо. Но это не всем подходит, во-первых есть риск в любой момент остаться без работы, а во-вторых, критически важные проекты обычно не доверяют людям, которых сложно контролировать.
Т.е. платформу вы уже сменили, а что делать с данными ещё только определяетесь? Отличное планирование.
Критичные данные необходимые вам самим для дальнейшей работы обычно мигрируют прямо в новую систему. Это долго, дорого но абсолютно необходимо.
Менее критичные, но необходимые, например для регулирующих органов данные часто переносят куда-либо на новую платформу и передоставляют доступ в виде репортов. Это часто требует меньше трудозатрат.
Если данные никому не нужны, либо никто в этом не признаётся, тем не менее есть риск ..., то делаются бекапы, архивы и всё переносится на виртуалки. Трудозатраты обычно минимальные.
Я бы начал снизу вверх. Т.е. сделал бы архивы и бекапы, перенёс бы существующую систему на виртуальную машину в любом случае, а вот остальное уже дополнительно и по необходимости.
Далее, есть несколько моментов на которые стоит обратить внимание:
— Как долго у вас будут работать сотрудники, которые разбираются в старой системе? Через некоторое время можется оказаться так, что никто не знает, как старая система работает и где там что найти.
— Сейчас у всех навязчивая идея хранить всё, что только можно, и потом анализировать это, строить отчёты и прогнозы. Делать это проще, если данные будут в какой-либо совсеменной базе данных.
Ну и в итоге it is up to the Customer — сколько человекочасов, а в конечном итоге денег они готовы на это потратить.
В теории вставка или модификация (смотря какая) каждой строки будет происходить в среднем в 1600 раз медленнее, чем без индексов. На деле, пока всё это будет помещаться в буферы — быстрее, а потом медленее.
Не могли бы вы пояснить, каким образом грамотно построенные индексы и партиционирование могли бы ускорить процесс при выполнении схожего приведённому в примере запроса?
Я не специалист в Postgresql, но есть подозрение, что в приведённом примере индексы могут только ухудшить время выполнения запроса, а партиционирование скорее всего повлияет никак.
В других случаях — возможно, но для приведённых примеров с математической точки зрения и то и другое выглядит бесполезно. Что я пропускаю?
2) Синтаксис Oracle SQL, PL/SQL в стандартном наборе действительно стал значительно лучше в последнее время. Только я не вижу некоторых новых конструкции из Oracle 12c (навскидку WITH_PLSQL, MATCH_RECOGNIZE). А между прочим расширенная поддержка 11g заканчивается уже в этом месяце.
Я вообще к чему это всё, инструмент — рабочий, общую картину увидеть позволяет. Но к сожалению от 10% до 30% связей мы не увидим. Частично из-за старой граматики (это как раз исправимо, пиши граматику сам), а вот проблема с динамическим кодом неразрешима.
В итоге получается, что инструменту на 100% доверять нельзя и всё-равно приходится посмотривать весь код глазами. Поиграться — да, надёжный инструмент — нет.
У Информатики даже продукт готовый есть за много тысяч долларов — Metadata Manager, увы, с той же степенью надёжности.
В случае с Oracle, если код в хранимых процедурах, то гораздо проще пользоваться таблицей ALL_DEPENDENCIES (пролема с динамикой остаётся). Если код в SVN, то только ANTRL.
Писал аналогичный скрипт для PL/SQL на Python. Подскажите, как решались проблемы с:
1) Сложными конструкциями в блоках select и for
2) Устаревшим синтаксисом в стандартном наборе ANTRL
А новость конечно странная, да.
Так вот при переезде из, например, Чехии в Германию (или куда вы там хотите) вам всё это надо будет начинать заново, начиная с работодателя и заканчивая переводами.
Плюс наличия ГК только в том, что вы будет проще ездить на собеседования.
Могла бы быть плюсом возможность отработать в одной стране допустим 3 года, потом в другой (например в Германии) ещё 2, итого 5 и сразу получить постоянный вид на жительства во второй стране. Это изначально заявлялось как преимущество ГК, но на практике такая возможность не работает. В частности с Германией на данный момент не работает.
Кроме весьма сомнительных плюсов есть и минусы, такие как минимальная зарплата. Для сеньёр ИТ специалистов это не проблема, а вот для джунов и даже мидлов это может стать проблемой. Проблема может возникнуть не только при устройстве на работу, но и при смене работы, на позицию с небольшой зарплатой, вы просто не сможете пойти.
Для кого-то это очевидно, но возможно не для всех. Вам дают ГК (как и ВНЖ по работе) только при условии, что вы работаете. Если вы увольняетесь, то вы должны в течение определённого срока (скажем месяц) найти другую работу соответствующую всем условиям или уехать домой. Вы привязаны к работе.
Про профильное образование — тут уже писали. Иногда даже наличия диплома не достаточно.
В целом, идея то здравая, но практика показывает, что на данный момент система с ГК работает не так, как многим бы хотелось. Тем не менее работает и в реальности ± соответствует временному ВНЖ.
Рассказываю как обладатель ГК.
— Легаси кода — много
— Даже если вы пишите что-то новое — вы всё-равно должны интегрироваться с легаси системами.
— Передовые технологии используются редко, в банках отдают предпочтение проверенным временем и надёжным вещам.
— Проекты большие, кому-то всё-равно придётся передавать данные с БД клиенту.
— Что надо делать диктует бизнес, они заказывают музыку, пишут музыку аналитики — вы её играете.
Рутина это или нет — решайте сами.
Зато Firebird бесплатный.
Даже в IT среде это слово означает тонкую настройку и как правило связано с повышением производительности и вряд ли кто-то рефакторинг будет называть тюнингом кода.
Жаловаться на высокие налоги в сочетании с хорошими дорогами, высоким уровнем безопасности и развитой инфраструктурой как минимум глупо.
Систему можно попробовать обмануть работая удалённо. Но это не всем подходит, во-первых есть риск в любой момент остаться без работы, а во-вторых, критически важные проекты обычно не доверяют людям, которых сложно контролировать.
Критичные данные необходимые вам самим для дальнейшей работы обычно мигрируют прямо в новую систему. Это долго, дорого но абсолютно необходимо.
Менее критичные, но необходимые, например для регулирующих органов данные часто переносят куда-либо на новую платформу и передоставляют доступ в виде репортов. Это часто требует меньше трудозатрат.
Если данные никому не нужны, либо никто в этом не признаётся, тем не менее есть риск ..., то делаются бекапы, архивы и всё переносится на виртуалки. Трудозатраты обычно минимальные.
Я бы начал снизу вверх. Т.е. сделал бы архивы и бекапы, перенёс бы существующую систему на виртуальную машину в любом случае, а вот остальное уже дополнительно и по необходимости.
Далее, есть несколько моментов на которые стоит обратить внимание:
— Как долго у вас будут работать сотрудники, которые разбираются в старой системе? Через некоторое время можется оказаться так, что никто не знает, как старая система работает и где там что найти.
— Сейчас у всех навязчивая идея хранить всё, что только можно, и потом анализировать это, строить отчёты и прогнозы. Делать это проще, если данные будут в какой-либо совсеменной базе данных.
Ну и в итоге it is up to the Customer — сколько человекочасов, а в конечном итоге денег они готовы на это потратить.
Я не специалист в Postgresql, но есть подозрение, что в приведённом примере индексы могут только ухудшить время выполнения запроса, а партиционирование скорее всего повлияет никак.
В других случаях — возможно, но для приведённых примеров с математической точки зрения и то и другое выглядит бесполезно. Что я пропускаю?