Любопытно, есть несколько вопросов.
1. Как вы пришли к решению создавать ХП, а не отдавать параллелизм на сторону приложения?
2. К примеру, если в одном потоке транзакция аварийно откатывается, данные автоматически становятся несогласованными? Как вы обрабатываете такие случаи? Или бизнес-логика в вашем примере не критична и допускает просто повторный запуск процедуры?
Я один не понимаю, как BGP влияет на скорость развертывания NFV?
Из протоколов динамической маршрутизации я бы выделил RIP и OSPF именно для поддержки в виртуальных сетевых функциях, потому как BGP — это обмен маршрутами между большими AS (в терминологии RFC1930), то есть для small/medium business не вариант.
Хорошую тему подняли.
Есть еще несколько видов преобразований cbo, которые достойны статей. На примере 11g:
— генерация и добавление в план filter-предикатов на основании check или not-null constraints, которые должны быть в состоянии enabled и validated;
— преобразование set-to-join (ему посвящен даже отдельный хинт set_to_join/no_set_to_join);
— преобразование вложенных подзапросов в join (тоже есть отдельный хинт unnest / no_unnest).
Кстати самая кровавая вещь на моей памяти, которая вызвала много проблем производительности при миграции 10g -> 11g.
Господа, насколько серьезно вам помогают mindmap?
Я часто их использовал, но гораздо больше времени убил на выяснение «что же лучше» и «как это делают другие».
Любая аутсорсинговая компания рано или поздно начинает вводить внутри себя какие-то KPI. Идея кажется хорошей, но все эти оценки «360 градусов», тестирование и прочее скоро начинают «подгоняться» под конкретных людей. Всё равно получается необъективно.
И да, сталкивавшись с Джет по работе, могу предложить очень показательный критерий компетентности — отсутствие «ляпов» и ошибок в работе. Чем сложнее задачи и чем меньше ошибок, тем квалифицированнее сотрудник. Других метрик мне сложно придумать.
Кстати, а как много уникальных адресов, с которых регистрируются пользователи? Тех доменов, с которых регистрируется 95% пользователей, не больше десятка.
Странные какие-то случаи, не понимаю негодования. Когда ты последний раз видел поле для ввода e-mail с максимальным количеством символов? Homepage не в счёт.
Писать или не писать regexp для проверки e-mail? А вот смотря зачем. Давайте подумаем.
Если для сервиса с двухступенчатой валидацией — можно вроде бы и не писать, но давайте поставим себя на место легитимного пользователя, который хочет действительно зарегистрироваться на ресурсе и воспользоваться его услугами? Как он узнает, что он опечатался в адресе при регистрации и не сможет зарегистрироваться? Сколько он будет ждать прихода письма на свой ящик? Он просто плюнет и уйдет на конкурирующий ресурс, недолго думая. Решения принимаются в течение нескольких минут, особенно, если пользователь спешит.
Поэтому мой выбор — всё-таки проверять и выдавать пользователю сообщение о некорректном адресе СРАЗУ. Другое дело, что криворукими или сложными такие проверки не должны быть.
p.s. кстати, статистика показывает, что пользователи могут опечатываться в адресе при вводе два раза подряд, и даже четыре.
В качестве плюсов могут быть:
* удобство установки;
* удобство использования (просто, быстро, негде ошибиться, не над чем ломать голову).
Памяти кушает явно не гигабайты, я даже поначалу не задавался этим вопросом. У меня отъедает порядка 60 Мб оперативной памяти при трёх одновременных загрузках.
Притом, что работа — это, как правило, восемь часов в сутки, посреди которого час на обед и некоторое время, чтобы добраться «туда» и «обратно, домой». Заметный такой кусок жизни, который нельзя не учитывать. Что касается лично меня, то у меня в списке дел не только работа, конечно же. Но это уже мало относится к теме прокрастинации.
Ох, сколько же в разное время уже было написано слов о том, как заставить себя работать…
Не усложняйте. Если работа вам нравится — вы будете ее делать без принуждения и с радостью. Если не нравится — увы и ах, у меня плохие новости.
1. Как вы пришли к решению создавать ХП, а не отдавать параллелизм на сторону приложения?
2. К примеру, если в одном потоке транзакция аварийно откатывается, данные автоматически становятся несогласованными? Как вы обрабатываете такие случаи? Или бизнес-логика в вашем примере не критична и допускает просто повторный запуск процедуры?
Из протоколов динамической маршрутизации я бы выделил RIP и OSPF именно для поддержки в виртуальных сетевых функциях, потому как BGP — это обмен маршрутами между большими AS (в терминологии RFC1930), то есть для small/medium business не вариант.
Есть еще несколько видов преобразований cbo, которые достойны статей. На примере 11g:
— генерация и добавление в план filter-предикатов на основании check или not-null constraints, которые должны быть в состоянии enabled и validated;
— преобразование set-to-join (ему посвящен даже отдельный хинт set_to_join/no_set_to_join);
— преобразование вложенных подзапросов в join (тоже есть отдельный хинт unnest / no_unnest).
Кстати самая кровавая вещь на моей памяти, которая вызвала много проблем производительности при миграции 10g -> 11g.
Но напрашивается другой вопрос: слабо на работе именно работать?)
Я часто их использовал, но гораздо больше времени убил на выяснение «что же лучше» и «как это делают другие».
И да, сталкивавшись с Джет по работе, могу предложить очень показательный критерий компетентности — отсутствие «ляпов» и ошибок в работе. Чем сложнее задачи и чем меньше ошибок, тем квалифицированнее сотрудник. Других метрик мне сложно придумать.
Скажу только, что я бы наверняка не стал это копипастить в свой код…
Если для сервиса с двухступенчатой валидацией — можно вроде бы и не писать, но давайте поставим себя на место легитимного пользователя, который хочет действительно зарегистрироваться на ресурсе и воспользоваться его услугами? Как он узнает, что он опечатался в адресе при регистрации и не сможет зарегистрироваться? Сколько он будет ждать прихода письма на свой ящик? Он просто плюнет и уйдет на конкурирующий ресурс, недолго думая. Решения принимаются в течение нескольких минут, особенно, если пользователь спешит.
Поэтому мой выбор — всё-таки проверять и выдавать пользователю сообщение о некорректном адресе СРАЗУ. Другое дело, что криворукими или сложными такие проверки не должны быть.
p.s. кстати, статистика показывает, что пользователи могут опечатываться в адресе при вводе два раза подряд, и даже четыре.
* удобство установки;
* удобство использования (просто, быстро, негде ошибиться, не над чем ломать голову).
Памяти кушает явно не гигабайты, я даже поначалу не задавался этим вопросом. У меня отъедает порядка 60 Мб оперативной памяти при трёх одновременных загрузках.
Перехватывает открытие (не загрузку) .torrent-файла в браузере.
Не усложняйте. Если работа вам нравится — вы будете ее делать без принуждения и с радостью. Если не нравится — увы и ах, у меня плохие новости.