Комментарии 10
Меньше кода на решение задачи = больше сделанного функционала за ту же зарплату.
Если дубликат появился 1 раз, то это следствие не самого лучше подхода к архитектуре, что может привести к появлению ещё большего числа повторяющегося кода.
Чем больше дублей, тем выше шанс упустить очередное повторение при модификации или дебагинге модуля. Каждая следующая встреча с таким куском кода будет вынуждать проходить по всем возможным местам, где тоже нужно вносить те же изменения.
Третий пункт тут следует поставить первым. А остальные два выкинуть, и вы придете к пониманию.
На наш совет "создавать накладные меньшим объёмом, ведь разницы никакой" мы услышали лишь "хотим так".
Потому что деньги зарабатывает не программа, а пользователь, которые выписывает накладные. И если он за 3 минуты может выписать одну накладную или 10, разница в прибыли может быть в 10 раз. Поэтому тут нужно было искать консенсус, а не указывать бизнесу с какой скоростью зарабатывать деньги.
Делать нечего, пришлось убрать общую транзакцию, заменив на построчные.
Ну вы нашли такой способ. Кто-то мог бы ну не знаю, купить сервер побыстрее, увеличить кеш оперативки на работу с базой, у вас почему-то только один вариант решения проблемы, причем такой, на который вы жалуетесь.
подтверждающих потребность хоть иногда делать кривые системы или писать код не по шаблону, так как того просит бизнес
Бизнес не просит вас писать кривые системы. Бизнес хочет зарабатывать деньги. То, что бизнес не дает достаточно времени или денег на разработку хороших методов и ровных систем, это уже проблема и проджект менеджера, который не может с бизнесом договориться о дедлайнах, и о жадности конкретных заказчиков от бизнеса. Но потребность эта не является каким-то абстрактным правилом для всех. Решение разное в каждом конкретном случае.
Нет, у них не мерялась зарплата в этих накладных, это сугубо локальный документ, который передается между отделами. Возможно чуть более мощный сервер решил бы эту проблему, но ускорение должно было быть не в 2-3 раза, а раз в 20 (иначе бы и его не хватало, ведь ждать даже 15 секунд никто не хочет), при том что в других местах он вполне нас устраивал. Переписать 1 процедуру как то менее болезненно чем выпрашивать у руководства таких гигантов.
Если они смогли у руководства выпросить ускорение процедуры, а вы не смогли руководству доказать, что скорость вполне всех устраивает и не надо ничего менять, значит вы проиграли, или "нас устраивал" это непонятно кого. Бизнес, судя по всему, он не устраивал.
Нет, у них не мерялась зарплата в этих накладных,
Это может быть не зарплата а прибыль компании, или банально свободное время, когда ты накладные сделал за 10 минут, а не за 30 минут. И целых 20 минут можно, например, ничего не делать. За это можно и побороться, например накатать заявку к начальству и настучать на ленивых разработчиков.
Очень крутая статья, обязательно буду ждать ещё!
..мы добавили в нашу систему кучу костылей и необходимость помнить..
Значит бизнес-логика этого склада плохо соответствует модели данных в вашей базе.
Принципы хорошие, но все это приходит с опытом. Без знания конкретной технологии это не поможет. В первом примере, с cte: не ощущается что есть понимание того, что cte это синтаксический сахар, который разворачивается на одном из ранних этапов исполнения (иначе откуда этот опус: "CTE имеет свои meta данные, что позволяет оптимизатору обрабатывать эти данные как отдельную таблицу. Это сильно может ускорить работу запроса."??)
Второе, если так сильно хотелось cte, и если джоины теже самые в агрегациях и деталях (а похоже что так), то это проще решить (обычно решается) каскадными cte: то что у Вас основной запрос — это первая cte, тут и фильтр - один раз; то что у Вас основной запрос это вторая cte- агрегация из первой from cte1 (поэтому называется каскадной). Основной запрос (или cte3): cte1 join cte2. Максимально наглядно и понятно, причем как программисту так и оптимизатору!
Но, да, безусловно, SQL это наверное самое неудачное место применения этих принципов!)
Когда «сделать плохо» == «сделать лучше»