Принято. В целом, так и есть, по ходу дальнейшего изучения рождаются правки статьи, так как вижу, что что-то использовал без объяснений, например пакет dbms_output.
Повторюсь, введение не значит объяснение всего. Скорее это первичные знания, которые позволят чуть-чуть ориентироваться в теме, чтобы понимать, что дальше читать, стоит ли дальше читать и такого плана задачи.
Вдобавок, ссылки оставлялись в том числе с надеждой на то, что станет интересно почитать иные ресурсы, особенно зарубежные.
В нынешнем состоянии статья весьма далека от идеала и не соответствует своему названию.
Если это касается не только вопросов, которые были подняты вами в предыдущем комментарии, можете чуть расширить тезис? Казалось, что достаточно доступно изложено
Бывало. Сперва при изменении PK, затем из-за нежданчиков с кодировкой систем-источника. А про NUMBER - изменились хотелки в части округления. То есть событие нечастое, да, но все же имеет место. Добавил указание на то, что чаще пригождается то, что вы описали.
Почему только SQL-запросы? А логика, циклы, вызов других функций итд?
А здесь руководствовался тем, что, если их упомянуть, то придется хотя бы мельком обозреть, что увеличит объем статьи. Изначально хотел поместить это в следующей, некоторое углубление. Думаете, лучше сразу это указывать? Возможно, из-за нехватки опыта в написании статей рассуждаю однобоко.
Как-то криво сформулировали. Он перехватывает не ошибки, а исключения. И не "не указанные явно", а которые не были обработаны
Вы правы, так проще и прямолинейнее.
Чего?
Дополнил. Имел в виду, что присвоение значения не через ввод с клавиатуры во всплывающее окно происходит внутри блока PL/SQL, а вот создать можно где угодно.
И что, если я повешу процедуру на триггер, то сервак мне напишет в телеграмм и попросит ввести значение?
Вот именно поэтому так делать не стоит:)
Пока это плохой материал, которым новичкам лучше игнорировать. А вам стоит подучить матчасть. И вам пока рано в курсоры и триггеры, разберитесь с основами.
Возможно, это следовало из ваших комментариев, но пока не понял, почему же. Прошу пояснить, если будет возможность.
Такое не написано. В том и дело, что структура повторяется и ошибка выпадет в том случае, если вызываемый из ROWTYPE атрибут будет удален.
А куда происходит переход точки выполнения по завершении кода этого блока? Возврат в точку возникновения? в точку после точки возникновения? в указанную точку? или выполнение процедуры прерывается окончательно и безусловно?
И ещё - что происходит, если ошибка возникает при выполнении кода блока EXCEPTION?
А это интересно, спасибо, буду разбираться)
А где собственно демонстрация разницы-то?
Про часть вы и сами написали -- в статье указано, что может создаваться вне блока;
Текст ниже: "Присваивать значение переменной не обязательно – Oracle, если не найдет что подставить вместо :var_name, выведет окошко с предложением ввести подстановочный текст. ", чего не происходит с обычной переменной.
Раньше по тексту явно было сказано, что переменные определяются в DECLARE
Это касалось базового типа переменных, а здесь описание именно замещающей. Нужно было явно прописать, спасибо!
Опять непонятно, откуда что взялось. Что за типы PL/SQL и VAR - про них не было сказано ни полслова. Куда делось DECLARE?
Спасибо, исправил, и правда некорректно.
Вот чего в ней хорошего? опять - акцент на неописанные выше ACCEPT и VARIABLE. И никаких пояснений...
Я исходил из того, что нет смысла пытаться уместить абсолютно все в одну статью. На хабре лежит подробнейшая статья отдельно про триггеры с кучей примеров -- если разбирать каждый элемент этой статьи в такой формате, то выйдет очень длинное чтиво, которое окажется уже и не совсем введением.
А за такие вещи как предложение пойти на другой сайт за частью материала, и вовсе бить надо. Вы зачем статью пишете?
Предыдущие комментарии по делу, а тут..
Очевидно, что таблица не моя - > указываю ее источник. Ссылка на документацию - в целом первоисточник всего, аргументация того, почему ее не пересказываю в статье, аналогична предыдущему блоку.
В любом случае, спасибо за подробный разбор! Приметил несколько моментов, где понимаю, что нет ответа. Да что там, даже не задался такими вопросами)
Про транскрибацию - пробовал через Google Colab и библиотеку от самого гугла, но у них встроенный лимит на число токенов и долгий бан, так что, если и правда рабочая бесплатная штука, вообще кайф, не находил)
В целом и один человек сможет сделать все, дело во времени и специализации. Если разработчику придется вникать в смежные области и тратить на ту же отчетность свое время, то.. что-то случится недоброе:)
Это не совсем специфика софта, скорее некий элемент теоретический, который по методологии Scrum должен присутствовать. По ссылке - переведенное руководство.
Если кратко, то в идеализированном подходе вместе с командой разработки есть несколько человек - Scrum Master и Product Owner. То есть их наличие обусловленно исключительно форматом разработки, принятом в компании, а в "жизни" это иные названия для более привычных спецов - того же Project Manager.
Соответственно, поскольку это все же западные веяния, такая узкая специализация есть их специфика - под каждое дело должен быть свой профильный специалист, а у нас, насколько я вижу, это не закрепилось, потому функционал этих теоретических ролей у других лиц.
Итоговый потребитель продукта - бизнес-заказчик или другой подразделение компании, потому вердикт о достижении/недостижении поставленной задачи ставят они. PO может оценить это, исходя из удовлетворения требований, которые были получены на старте или в процессе.
Скорее здесь имел в виду не максимум как конечное, пиковое значение, а процесс максимизации, что можно оценить, в случае приложения или сайта, по времени отклика, удержанию аудитории, удобству эксплуатации (аля числовой оценке).
Ответственность, конечно, скорее моральная/корпоративная, так сказать. Ибо защита результатов проделанной работы, отчет о трудозатратах конкретной скрам-команды ложится на его плечи. То есть это его работа, его обязанности, с которыми нужно справляться
Да так и есть, в пожалуй. Все аналитики, в зависимости от сферы деятельности компании (или стека технологий), могут даже не иметь отношения к ИТ, так что это условно, в некотором смысле
Я не смог определиться с тем, куда их отнести в рамках парадигмы "разработка - аналитика".
С одной стороны, они моделируют структуру того, что будет разрабатываться, а с другой - учитывают требования заказчика и истинные потребности бизнеса чуть ли не напрямую.
Буду признателен, если меня поправите и тезисно расскажете об иных архитекторах, которых не хватает, а я все дополню:)
Принято. В целом, так и есть, по ходу дальнейшего изучения рождаются правки статьи, так как вижу, что что-то использовал без объяснений, например пакет dbms_output.
Спасибо за рекомендации!
Повторюсь, введение не значит объяснение всего. Скорее это первичные знания, которые позволят чуть-чуть ориентироваться в теме, чтобы понимать, что дальше читать, стоит ли дальше читать и такого плана задачи.
Вдобавок, ссылки оставлялись в том числе с надеждой на то, что станет интересно почитать иные ресурсы, особенно зарубежные.
Если это касается не только вопросов, которые были подняты вами в предыдущем комментарии, можете чуть расширить тезис? Казалось, что достаточно доступно изложено
Бывало. Сперва при изменении PK, затем из-за нежданчиков с кодировкой систем-источника. А про NUMBER - изменились хотелки в части округления. То есть событие нечастое, да, но все же имеет место. Добавил указание на то, что чаще пригождается то, что вы описали.
А здесь руководствовался тем, что, если их упомянуть, то придется хотя бы мельком обозреть, что увеличит объем статьи. Изначально хотел поместить это в следующей, некоторое углубление. Думаете, лучше сразу это указывать? Возможно, из-за нехватки опыта в написании статей рассуждаю однобоко.
Вы правы, так проще и прямолинейнее.
Дополнил. Имел в виду, что присвоение значения не через ввод с клавиатуры во всплывающее окно происходит внутри блока PL/SQL, а вот создать можно где угодно.
Вот именно поэтому так делать не стоит:)
Возможно, это следовало из ваших комментариев, но пока не понял, почему же. Прошу пояснить, если будет возможность.
Спасибо за замечания!
Такое не написано. В том и дело, что структура повторяется и ошибка выпадет в том случае, если вызываемый из ROWTYPE атрибут будет удален.
А это интересно, спасибо, буду разбираться)
Про часть вы и сами написали -- в статье указано, что может создаваться вне блока;
Текст ниже: "Присваивать значение переменной не обязательно – Oracle, если не найдет что подставить вместо :var_name, выведет окошко с предложением ввести подстановочный текст. ", чего не происходит с обычной переменной.
Это касалось базового типа переменных, а здесь описание именно замещающей. Нужно было явно прописать, спасибо!
Спасибо, исправил, и правда некорректно.
Я исходил из того, что нет смысла пытаться уместить абсолютно все в одну статью. На хабре лежит подробнейшая статья отдельно про триггеры с кучей примеров -- если разбирать каждый элемент этой статьи в такой формате, то выйдет очень длинное чтиво, которое окажется уже и не совсем введением.
Предыдущие комментарии по делу, а тут..
Очевидно, что таблица не моя - > указываю ее источник. Ссылка на документацию - в целом первоисточник всего, аргументация того, почему ее не пересказываю в статье, аналогична предыдущему блоку.
В любом случае, спасибо за подробный разбор! Приметил несколько моментов, где понимаю, что нет ответа. Да что там, даже не задался такими вопросами)
Спрашивайте)
Звучит здорово, надо ручками пощупать
Про транскрибацию - пробовал через Google Colab и библиотеку от самого гугла, но у них встроенный лимит на число токенов и долгий бан, так что, если и правда рабочая бесплатная штука, вообще кайф, не находил)
Это ведь не топ, а попытка классификации)
Как говорится, last but not least
В целом и один человек сможет сделать все, дело во времени и специализации. Если разработчику придется вникать в смежные области и тратить на ту же отчетность свое время, то.. что-то случится недоброе:)
А там еще вроде остаются человеко-часы разработчиков на поддержке, нет?
А как))
Я был бы рад более.. правильным с точки зрения смысла определениям)
Это не совсем специфика софта, скорее некий элемент теоретический, который по методологии Scrum должен присутствовать. По ссылке - переведенное руководство.
Если кратко, то в идеализированном подходе вместе с командой разработки есть несколько человек - Scrum Master и Product Owner. То есть их наличие обусловленно исключительно форматом разработки, принятом в компании, а в "жизни" это иные названия для более привычных спецов - того же Project Manager.
Соответственно, поскольку это все же западные веяния, такая узкая специализация есть их специфика - под каждое дело должен быть свой профильный специалист, а у нас, насколько я вижу, это не закрепилось, потому функционал этих теоретических ролей у других лиц.
Постарался учесть рекомендации, буду признателен, если пробежитесь и скажете, где соврал, а где стало лучше)
Пожалуй, так:
Итоговый потребитель продукта - бизнес-заказчик или другой подразделение компании, потому вердикт о достижении/недостижении поставленной задачи ставят они. PO может оценить это, исходя из удовлетворения требований, которые были получены на старте или в процессе.
Скорее здесь имел в виду не максимум как конечное, пиковое значение, а процесс максимизации, что можно оценить, в случае приложения или сайта, по времени отклика, удержанию аудитории, удобству эксплуатации (аля числовой оценке).
Ответственность, конечно, скорее моральная/корпоративная, так сказать. Ибо защита результатов проделанной работы, отчет о трудозатратах конкретной скрам-команды ложится на его плечи. То есть это его работа, его обязанности, с которыми нужно справляться
Сделаю
Благодарю!
Да так и есть, в пожалуй. Все аналитики, в зависимости от сферы деятельности компании (или стека технологий), могут даже не иметь отношения к ИТ, так что это условно, в некотором смысле
Я не смог определиться с тем, куда их отнести в рамках парадигмы "разработка - аналитика".
С одной стороны, они моделируют структуру того, что будет разрабатываться, а с другой - учитывают требования заказчика и истинные потребности бизнеса чуть ли не напрямую.
Буду признателен, если меня поправите и тезисно расскажете об иных архитекторах, которых не хватает, а я все дополню:)
Возможно, вы правы, просто я с таким не столкнулся, потому не понимаю, почему ж аналитики лапшу вешают (
И какая именно классификация неудачна?