Evgeniy S, а какие варианты?
1. Сидеть, бояться и ждать. Каждый раз слушать ответы из серии "приходите завтра". Ныть что разработчики плохие и ничего не делать.
Ну наверное это приемлемо в некоторых случаях.... Но в целом, ИМХО, ущербно
2. Сделать работу за руководителя разработки - разобраться в чем проблема и принять меры.
Тоже вариант. Но если руководишь большой организацией, то вряд ли возьмешься налаживать работу отдела разработки, т.к. своей работы полно.
3. Поменять руководителя разработки, ждать результата от нового руководителя. Повторить эту последовательность действий до достижения удовлетворительного результата.
На мой взгляд, самый правильный вариант.
Кстати, все три варианта не взаимоисключающие.
Можно делегировать полномочия, но делегировать ответственность нельзя (т.е. валить все на разработчика - беспонтово). Т.е. ошибка менеджера. Хотел бы минимизировать риск ошибки провел бы какой-нибудь "покер планирования" или поспрашивал бы оценку у других спецов. В защиту менеджера можно сказать, что даже все эти мероприятия не гарантируют отсутствия ошибок... не ошибается только тот кто ничего не делает...
Если в кратце:
UNION ALL - объединяет результаты двух запросов
UNION - обединяет результаты двух запросов, а так же удаляет дубли и сортирует.
По этому, UNION ALL почти всегда будет работать быстрее.
Причем тут email я совсем не понял....
Неожиданно, думал этот ажиотаж уже стих, но если хочется погрузиться, то предлагаю гуглить фразу "Semantic Web". Лет 15-20 назад была целая религия на эту тему. Идея была очень красивая, но на мой взгляд она -либо утопична в принципе, либо просто опередила свое время.
Проблема заключалась в том, что для того что бы научить комп понимать (действительно понимать!) тексты по какой то тематике, необходимо слаженная работа кучи лингвистов, которые задаю правила разбора текста. И таких куч лингвистов должно быть много - для каждого языка и предметной области.... А энтузиастов столько не набралось.... но теперь их стало на один больше! удачи)))
Когда то вот в этой компании была неплохая школа семантических технологий (не реклама), как сейчас - не знаю.
Да какая разница как у нас?! Скорее всего мы находимся в разных исторических контекстах: разные цели, разные задачи, разные ресурсы - разное все.
Если речь идет не о переменах ради перемен, то надо исходить из проблемы. Вот Вы сказали "Появилось предложение разделить команды по профилям..." и "Пока не понимаем эффективна ли такая модель "... У меня в ответ на это возникает вопрос: "а зачем тогда что то менять?". Какую проблему пытаетесь решить?
Если попытаться конструктивно порассуждать о предлагаемом варианте организации, то необходимо понимать и уметь решать следующие задачи:
1. Обычно всегда есть задачи по автоматизации процессов, которые насквозь проходят через фронт, мидл и бэк. Соответственно, в предложенной Вами структуре (поскольку во фронте, мидле и бэке у вас работают разные команды) возрастают требования к координации, устранению конфликтов, устранению разрывов при выпуске релизов и т.д. Т.е. по мимо тимлидов команд, вам нужны еще и координаторы изменений. По моим ощущениям, одного PM вам будет недостаточно (не уверен, что он сможет отследить технологические зависимости между тасками в разных беклогах). Возможно ошибаюсь.
2. Если разнесете по разным беклогам, то сложнее будет отслеживать технологические и ресурсные зависимости между тасками. Хотя, возможно, все будет зависеть от используемого инструмента.
DELETE возможно решит задачу, но лучше использовать TRUNCATE. Кашернее.... В этом случае у Вас еще и размер таблицы в БД уменьшится практически до 0 байт.
Вы спросили - я ответил. Вариант/не вариант - решать Вам.
Не понятно как вы их спокойно используете с операциями +/-.... По моему это возможно только во внешних запросах (по отношению к тому запросу в котором Вы их определяете), но это ровно то, что я Вам предложил. Ну да ладно.
В поезде в одном купе едут священник и бизнесмен. Бизнесмен сразу открыл ноутбук, начал работать с документами. Священник посмотрел на него, подумал, потом говорит:
— Сын мой, а не прогуляться ли нам до вагона-ресторана, посмотреть, что в меню?
— Нет, батюшка, не голоден я.
Священник идёт в ресторан один. Через час возвращается довольный и улыбающийся, в руке несёт бутылку дорогого коньяка.
— Сын мой, а не отведать ли нам этого пятизвёздочного напитка?
— Нет, батюшка, простите, не пью.
Священник наливает себе полстакана коньяку, смакуя, медленно выпивает. Вытирает губы, выходит в коридор. Через пятнадцать минут заходит обратно.
— Сын мой, через одно купе от нас две молодые миряночки едут. Может быть, заглянем к ним в гости, побеседуем о высоком?
— Нет, батюшка, я женат, да и с документами мне работать надо.
Священник берёт со стола бутылку коньяка, выходит. Возвращается уже под утро, довольный, как мартовский кот. Бизнесмен, который всё это время работал, поднимает на него глаза.
— Скажите, святой отец, как же так? Я не пью, не курю, блюду свой моральный облик. Работаю как вол. Неужели я неправильно живу?
Священник вздыхает.
— Правильно, сын мой. Но… Зря…
Баланс важен, ИМХО....
В целом согласен: учиться, учиться и учиться (с) В.И.
О сколько нам открытий чудных
Готовят просвещенья дух
И опыт, сын ошибок трудных,
И гений, парадоксов друг,
И случай, бог изобретатель..
(с) А.С.
clients_addresses.id_address IS NULL
В таблице клиентских адресов найти строку в которой собственно ссылка на адрес пуста...
сильно удивлюсь если под такое условие попадает хотя бы одна строка....
а должны? индексы не всегда гуд...
Вы не знаете ни сколько процентов строк из каждой таблицы извлекается, ни упорядоченность данных в таблицах, ни настройки БД...
поверхностно весьма... имхо, без доп. данных не разобраться
Добрый день! конечно не уверен.... может быть так будет правильнее:
SELECT * FROM securities t
WHERE t.change_date IN (SELECT Max(t1.change_date) FROM securities t1 WHERE t.characteristic=t1.characteristic)
Я же не знаю что у вас означают данные в том или ином столбце.... Вы не дали описания данных, дали только описание структуры...
1. Сидеть, бояться и ждать. Каждый раз слушать ответы из серии "приходите завтра". Ныть что разработчики плохие и ничего не делать.
Ну наверное это приемлемо в некоторых случаях.... Но в целом, ИМХО, ущербно
2. Сделать работу за руководителя разработки - разобраться в чем проблема и принять меры.
Тоже вариант. Но если руководишь большой организацией, то вряд ли возьмешься налаживать работу отдела разработки, т.к. своей работы полно.
3. Поменять руководителя разработки, ждать результата от нового руководителя. Повторить эту последовательность действий до достижения удовлетворительного результата.
На мой взгляд, самый правильный вариант.
Кстати, все три варианта не взаимоисключающие.