Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Работа Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 [8] 9   вперед  Ctrl      все
 Re: Ночные дежурства  [new]
hVostt
Member

Откуда:
Сообщений: 19318
Ночные дежурства на крупных проектах это
Норма
25,0%
 (13)
Редкость
75,0%
 (39)
Голосование открыто только для зарегистрированных пользователей.
Проголосовало: 52  

Melkomyagkii_newbi
что даст ее вынос подальше от системы хранения


Если уж именно этот вопрос вас интересует. Колоссальное количество возможностей даст, вменяемый ЯП, тулинг, широченные возможности декомпозиции, возможность выбирать ЯП и платформу под задачи, работать с множеством источником данных как единым целым, оркестрировать бизнес-процессы, размазанные по системам, компаниям, континентам. И т.д. и т.п. тут материала на книгу хватит.
6 май 21, 23:12    [22319382]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 2042
hVostt
Melkomyagkii_newbi
в том числе для логики которая связана с данными, что даст ее вынос подальше от системы хранения - не очень понятно.


На деле очень сильные и толковые ребята


это ваша субъективная оценка, может они бестолковые и хотят других технологий потому что эти не осилили, а с другими рынок шире - на любой уровень (бес)толковости проще найти место)

hVostt

Тем более, на код хранимок обычно без кровавых слёз не взглянешь. Хуже T/PL-SQL только ABAP, который придумали наследники Гитлера, чтобы люди страдали :)

это ваша субъективная оценка, я вот чаще плачу кровавыми слезами от кода на java, objective-с и питона.

hVostt
Ситуации, когда ХП может помочь: либо временное решение, либо как подпорка, либо как очень действенная точечная оптимизация.

Размещение же логики в БД в ином случае (а это 99%) — в этом нет никакого смысла и нет никакой нужды.


любую логику можно запилить и в базе и выносить ее нет смысла и нужды - все в одном месте, удобненько, кратчайшие раундтрипы до данных которые придется обработать) огромное количество систем - тому подтверждение.
6 май 21, 23:44    [22319388]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 2042
hVostt
Melkomyagkii_newbi
что даст ее вынос подальше от системы хранения


возможность выбирать ЯП и платформу под задачи

а если у меня задача сделать биллинг, или процессинг или управление складом какое-то и я выбрал платформу субд оракл, где всё для решения этих задач есть?
hVostt

оркестрировать бизнес-процессы, размазанные по системам, компаниям, континентам

это как? можно пример бизнес процесса который размазан по компаниям, мог быть сделан на хранимках, но вывод его в приложение(я?) позволил его оркестрировать?
6 май 21, 23:56    [22319391]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
hVostt
Member

Откуда:
Сообщений: 19318
Melkomyagkii_newbi
это ваша субъективная оценка, может они бестолковые и хотят других технологий потому что эти не осилили, а с другими рынок шире - на любой уровень (бес)толковости проще найти место)


Да кто ж спорит? Только вы тут носитель исключительно объективных оценок
Ну а "не осилили" — это просто безапелляционный аргумент. Так можно сказать о чём угодно. Почему лбом гвозди не забиваете? Наверное потому что не осилили :)

Melkomyagkii_newbi
это ваша субъективная оценка, я вот чаще плачу кровавыми слезами от кода на java, objective-с и питона.


Тут всё предельно очевидно. Вы не осилили :)

Melkomyagkii_newbi
любую логику можно запилить и в базе и выносить ее нет смысла и нужды - все в одном месте, удобненько, кратчайшие раундтрипы до данных которые придется обработать) огромное количество систем - тому подтверждение.


Бизнесу абсолютно наплевать с высоченной колокольни на ваши раундтрипы. Стоимость разработки ПО на хранимках — дорогое удовольствие. Выхлопа никакого нет. Желающих погружаться в это (имхо, УГ) с каждым годом всё меньше и меньше. Огромное количество задач как в разработке, так и в эксплуатации на хранимках тупо не решается и приходится пилить аппликейшен слой, размазывая логику по системам. То ещё "удовольствие" :)

Melkomyagkii_newbi
а если у меня задача сделать биллинг, или процессинг или управление складом какое-то и я выбрал платформу субд оракл, где всё для решения этих задач есть?


Ну и флаг в руки. Не навязываю лично вам свои взгляды, вполне возможно вы запилите отличный биллинг. Но и мы запилим не менее отличный биллинг без хранимок. И для этого всё есть и даже намного больше.

Melkomyagkii_newbi
hVostt
оркестрировать бизнес-процессы, размазанные по системам, компаниям, континентам

это как? можно пример бизнес процесса который размазан по компаниям, мог быть сделан на хранимках, но вывод его в приложение(я?) позволил его оркестрировать?


Ну как, мы не ограничены рамками одной БД, задача с одной стороны становится сложнее. С другой стороны её решение делает систему на порядки гибче. В разработке дешевле, надёжнее и с прекрасными перспективами развития.
7 май 21, 00:40    [22319396]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
xerxf
Member

Откуда:
Сообщений: 261
hVostt

Ну как, мы не ограничены рамками одной БД, задача с одной стороны становится сложнее. С другой стороны её решение делает систему на порядки гибче. В разработке дешевле, надёжнее и с прекрасными перспективами развития.

БД все разные. то, что летает на одной, вполне может жутко тормозить на другой. И наоборот. Универсальный подход обычно означает универсально плохой. Если бизнес это устраивает - ну это его решение. В огромном количестве случаев бизнесу плевать - задачи не особо критичные, универсально фиговые решения их вполне тянут, а фанаты микросервисов убеждают, что в 21 году правильные пацаны делают всё и всегда исключительно на микросервисах ( хотя практически в любой литературе по микросервисам всё начинается с того, что это не "серебрянная пуля" и подумайте - надо ли оно вам?).
А вот когда универсальное решение упирается в свои пределы -тогда уже оказывается, что возможны варианты. Но в огромном количестве случаев до этих пределов как до луны пешком. и это позволяет огромному количеству народа утверждать, что этих пределов не существует. и всё покрывается универсальностью. ну и вообще - уж не знаю к счастью или к сожалению для 99,(9)% разработки прошли времена, когда считали байты и такты процессора. мегабайт туда, мегабайт сюда, десяток библиотек подгрузить на всякий случай, наплевать на оптимизации - железо шустрое и так потянет. Главное быстрее, дешевле, гибче...

Сообщение было отредактировано: 7 май 21, 00:51
7 май 21, 00:56    [22319397]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 2042
hVostt
и приходится пилить аппликейшен слой, размазывая логику по системам. То ещё "удовольствие" :)

а у вас значит не размазанная будет - монолитный аппликейшн?


Melkomyagkii_newbi
пропущено...

это как? можно пример бизнес процесса который размазан по компаниям, мог быть сделан на хранимках, но вывод его в приложение(я?) позволил его оркестрировать?


Ну как, мы не ограничены рамками одной БД, задача с одной стороны становится сложнее. С другой стороны её решение делает систему на порядки гибче. В разработке дешевле, надёжнее и с прекрасными перспективами развития.[/quot]

я ему про пример бизнес процесса, он мне маркетинг булщит.
Чем гибче, отсутсвием вендор лока? ок, но какой ценой(а надо ли оно, если и с ним никаких проблем)? Дешевле ли разработка выйдет вместе с решением этой задачи? Почему надежнее?
7 май 21, 00:58    [22319398]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
xerxf
Member

Откуда:
Сообщений: 261
Melkomyagkii_newbi

Чем гибче, отсутсвием вендор лока? ок, но какой ценой(а надо ли оно, если и с ним никаких проблем)? Дешевле ли разработка выйдет вместе с решением этой задачи? Почему надежнее?

по моему это тоже нечто сродни религии - "наше приложение гибко, оно может легко переключаться на разные базы данных"
Хотя на деле обычно всё равно используют одну единожды выбранную

Сообщение было отредактировано: 7 май 21, 00:58
7 май 21, 01:06    [22319399]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
hVostt
Member

Откуда:
Сообщений: 19318
xerxf
БД все разные. то, что летает на одной, вполне может жутко тормозить на другой. И наоборот.


Вот именно! Значит мы можем для разных задач поместить данные в разные БД и разные системы хранения.
А логика будет там где ей место — в приложениях.

xerxf
Универсальный подход обычно означает универсально плохой. Если бизнес это устраивает - ну это его решение.


Не конструктивно. Универсальный значит в первую очередь дешёвый.

xerxf
а фанаты микросервисов убеждают, что в 21 году правильные пацаны делают всё и всегда исключительно на микросервисах ( хотя практически в любой литературе по микросервисам всё начинается с того, что это не "серебрянная пуля" и подумайте - надо ли оно вам?).


В этом есть вполне определённый практический и экономический смысл.
Это проверено на практике, это работает. Зарекомендовало себя и работает прекрасно во многих аспектах.

xerxf
наплевать на оптимизации - железо шустрое и так потянет. Главное быстрее, дешевле, гибче...


Именно. Фух :)
7 май 21, 01:40    [22319401]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
hVostt
Member

Откуда:
Сообщений: 19318
xerxf
по моему это тоже нечто сродни религии - "наше приложение гибко, оно может легко переключаться на разные базы данных"
Хотя на деле обычно всё равно используют одну единожды выбранную


Во-первых. Если вы не сталкивались, то я сталкивался с заменой БД. Меняли оракл на постгрес. Если честно, вот скажу прямо на духу. Это было хреновое решение, но мы справились, в разумные сроки.

Но. Там не было логики в ХП. Если бы она там была, сроки были бы равны практически написанию системы с нуля, т.е. раз эдак в 10 больше.

Не сказать бы, что это прям рядовая ситуация, типа каждый день СУБД меняют как перчатки, просто показательная.

Во-вторых. Речь идёт обычно не о замене СУБД. А о использовании сразу нескольких систем хранения, заточенных под свои задачи. А ещё о изоляции. Получается вы ограничены одной единственной СУБД, а мы нет. Можем работать с чем угодно.

Melkomyagkii_newbi
я ему про пример бизнес процесса, он мне маркетинг булщит.
Чем гибче, отсутсвием вендор лока? ок, но какой ценой(а надо ли оно, если и с ним никаких проблем)? Дешевле ли разработка выйдет вместе с решением этой задачи? Почему надежнее?


Вендор лок, это не самоцель, а следствие. Какой ценой? Дешевле! Надёжней, потому что логику можно и нужно развести по ограниченным изолированным контекстам, пилить отдельными независимыми командами, даже на разных технологиях. Заменяемость. Отказоустойчивость, так нет единой точки отказа.

Можно продолжать очень и очень долго.
7 май 21, 01:52    [22319402]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
hVostt
Member

Откуда:
Сообщений: 19318
Я всё же позволю себе сказать какое-нибудь заключительное слово. Ну правда, пепелище вот таких холиворов уже давно остыло.

Это моё субъективное мнение. Оно основано конечно на большом опыте, наблюдениях, общению с коллегами, партнёрами, на различных площадках и коммьюнити. Но всё равно это имхо.

Не вижу предмета спора лучше-хуже. Для меня лично и многих-многих других тут уже вопрос чисто целесообразности. Целесообразность помещения логики в БД стремится к нулю. По огромному числу причин.

У вас (оппонирующих мне) другое мнение и оно также имеет право на жизнь, я это признаю и уважаю. Необходимость в таких специалистах ещё на наш век хватит, так что беспокоиться не о чем :)
7 май 21, 02:03    [22319403]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
monsenior
Member

Откуда: Москва
Сообщений: 930
hVostt

Во-вторых. Речь идёт обычно не о замене СУБД. А о использовании сразу нескольких систем хранения, заточенных под свои задачи. А ещё о изоляции. Получается вы ограничены одной единственной СУБД, а мы нет. Можем работать с чем угодно.


Это работает только когда можно залить ваше решение ресурсами.

Видел проект где было много разных баз как склад данных, и аппсервера с логикой и т.д и т.п.
По мере роста нагрузки, добавлялись инстанты аппсерверов - быстро, удобно, и даже менять бизнес код достаточно удобно.

Но, но в один момент времени цена железа для аппсерверов стала запредельна(не за штуку, а за объем).
Спасло переписывание логики на бд и хранимки.

Финансовый результат был примерно такой:
1) Выросли цена лицензий.
2) Сильно вырос ФОТ разрабов + админов(потребовались хорошие спецы по базам).
3) Цена на железо упала в 3 раза, при этом пиковый запас мощности вырос на 50%.

Выгода от п.3 превышала расходы на п1.+п2. где то в 2.5 раза.
7 май 21, 13:45    [22319519]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Nelrum
Member

Откуда:
Сообщений: 351
monsenior
hVostt

Во-вторых. Речь идёт обычно не о замене СУБД. А о использовании сразу нескольких систем хранения, заточенных под свои задачи. А ещё о изоляции. Получается вы ограничены одной единственной СУБД, а мы нет. Можем работать с чем угодно.


Это работает только когда можно залить ваше решение ресурсами.

Видел проект где было много разных баз как склад данных, и аппсервера с логикой и т.д и т.п.
По мере роста нагрузки, добавлялись инстанты аппсерверов - быстро, удобно, и даже менять бизнес код достаточно удобно.

Но, но в один момент времени цена железа для аппсерверов стала запредельна(не за штуку, а за объем).
Спасло переписывание логики на бд и хранимки.

Финансовый результат был примерно такой:
1) Выросли цена лицензий.
2) Сильно вырос ФОТ разрабов + админов(потребовались хорошие спецы по базам).
3) Цена на железо упала в 3 раза, при этом пиковый запас мощности вырос на 50%.

Выгода от п.3 превышала расходы на п1.+п2. где то в 2.5 раза.


Обычно такое случается когда те кто ни на чем кроме SQL писать вменяемый код не в состоянии пытаются писать код на чем-то кроме SQL.
8 май 21, 02:05    [22319771]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Ведущий профессионал
Member

Откуда: Санкт-Петербург
Сообщений: 170
redkij
Всем привет. Я бэкендер. На текущем месте работы столкнулся с таким явлением как ночное дежурство. Условно, раз в пару недель (будни, выходные, неважно) наступает твоя очередь, когда тебе могут позвонить ночью, если в проде что-то развалилось. Надо просыпаться и пытаться фиксить в экстренном порядке. Теперь мучает вопрос - если хочешь быть разрабом на масштабном проекте, который используется 24/7, это прям норма и в большинстве топовых мест будет так же, или все же скорее редкость?
За 20 лет работы никогда с таким не сталкивался. Даже днём дёргать разраба - это верх бардака и некомпетентности руководства. А уж ночью... Я программист, а не авиадиспетчер.
9 май 21, 03:47    [22319808]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 4995
hVostt
Melkomyagkii_newbi
в том числе для логики которая связана с данными, что даст ее вынос подальше от системы хранения - не очень понятно.


Бизнес-логика всегда связана с данными. Если смотреть в ретроспективе, то заявленные преимущества размещения логики в БД оказались покрыты толстым слоем минусов. Иначе бы сейчас все писали код в БД.

На деле очень сильные и толковые ребята, на собеседованиях, немножечко напрягаясь, спрашивают: "надеюсь у вас там не на хранимках всё написано? а то, вы меня извините конечно, я к вам не пойду".

По моей личной статистике около 10-15% кандидатов меняют место работы по той причине, что устали сопровождать доставшийся им по недоразумению проект, написанный на хранимках. Говорят, это дно и надеются найти работу с современными подходами к построению информационных систем.

Моя практика показывает, что такое отношение к хранимкам в целом как к чему-то плохому обычно говорит о том, что человек ничего в жизни сложнее select * from table не писал. А еще эти люди любят orm. Зачем мол sql знать, orm все за тебя сделает, зато можно в парадигме ооп писать...
9 май 21, 15:06    [22319889]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 4995
hVostt
Стоимость разработки ПО на хранимках — дорогое удовольствие.

Можете объяснить почему? Почему это дороже, чем не на хранимках?

P. S. У меня на ум приходит только вариант, что фанаты не хранимок просто плохо умеют sql.
Хотел бы ваш вариант услышать?
9 май 21, 15:15    [22319892]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 4995
xerxf
ну и вообще - уж не знаю к счастью или к сожалению для 99,(9)% разработки прошли времена, когда считали байты и такты процессора. мегабайт туда, мегабайт сюда, десяток библиотек подгрузить на всякий случай, наплевать на оптимизации - железо шустрое и так потянет. Главное быстрее, дешевле, гибче...

Я встречал случаи, когда добавление железа уже не помогало. Впрочем это связано не столько с использованием хп, а с нормальным проектированием и оптимизацией в целом.
9 май 21, 15:18    [22319893]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 4995
hVostt
.
Во-вторых. Речь идёт обычно не о замене СУБД. А о использовании сразу нескольких систем хранения, заточенных под свои задачи. А ещё о изоляции. Получается вы ограничены одной единственной СУБД, а мы нет. Можем работать с чем угодно.

Мы у себя используем 3 разных субд: ms sql, postgresql, mysql. В 2х из них многое сделано на хранимках. Интеграция есть: все данные со сторонних бд сливаются в головной ms sql. Как видите, мы себя в субд не ограничивали. :)
9 май 21, 15:27    [22319896]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Nelrum
Member

Откуда:
Сообщений: 351
Megabyte
hVostt
Стоимость разработки ПО на хранимках — дорогое удовольствие.

Можете объяснить почему? Почему это дороже, чем не на хранимках?

Для примера это постоянно изобретение колес. С библиотеками готовыми в ХП какбы всё плохо. Чаще это просто выливается в копи-паст хранимок непонятно откуда, без вменяемой версионности, без вообще какихто каналов релиза.

Версионность, тоже так себе. Как откроешь базу так куча хранимок с суфиксами типа _v1, _v2, _v100500. И Хорошо если в коментах внутри вообще описано в чем проблема предудущей версии. И старую версию тоже не удалишь т.к. непонятно что её может и где использовать и что развалится. Ведь постоянно видна картина когда ХП просто каскадом вызывают одна другую и концов не отыскать нормально.

Интеграция с VCS относительно новое явление и то не повсеместное.

Я уж молчу про обычай зайти в базу и в продакшене что-то пофиксить. В SAP хоть встроеная история есть и можно увидеть что и кто когда менял. В PostgreSQL и сервере потом никогда не отыщеш что и когда делалось.

Ну и естесно всё это разбавлено миллионом вьюх, которые тоже цепляются друг за друга.


Megabyte

P. S. У меня на ум приходит только вариант, что фанаты не хранимок просто плохо умеют sql.
Хотел бы ваш вариант услышать?


Вы до сих пор считаете SQL (или любой из его диалектов) тайным знанием которым тяжело овладеть? Вы реально думаете что программисты пишут софт на C++/Java/Python/... да даже долбаном JS, потому что они просто плохо умеют SQL?

Сообщение было отредактировано: 9 май 21, 17:21
9 май 21, 17:28    [22319923]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3413
Nelrum
Версионность, тоже так себе. Как откроешь базу так куча хранимок с суфиксами типа _v1, _v2, _v100500. И Хорошо если в коментах внутри вообще описано в чем проблема предудущей версии. И старую версию тоже не удалишь т.к. непонятно что её может и где использовать и что развалится. Ведь постоянно видна картина когда ХП просто каскадом вызывают одна другую и концов не отыскать нормально.
О да, я на такое насмотрелся. Приходишь на новый контракт, а у них там в базах черт ногу сломит. Но ничего, затягиваю схему в проект SSDT, отлавливаю зависимости, вычищаю этих временщиков, после чего показываю, как это интегрируется с Git и как делать релизы.
Остаются очень благодарны :)
9 май 21, 18:41    [22319930]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Nelrum
Member

Откуда:
Сообщений: 351
Ennor Tiegael
Nelrum
Версионность, тоже так себе. Как откроешь базу так куча хранимок с суфиксами типа _v1, _v2, _v100500. И Хорошо если в коментах внутри вообще описано в чем проблема предудущей версии. И старую версию тоже не удалишь т.к. непонятно что её может и где использовать и что развалится. Ведь постоянно видна картина когда ХП просто каскадом вызывают одна другую и концов не отыскать нормально.
О да, я на такое насмотрелся. Приходишь на новый контракт, а у них там в базах черт ногу сломит. Но ничего, затягиваю схему в проект SSDT, отлавливаю зависимости, вычищаю этих временщиков, после чего показываю, как это интегрируется с Git и как делать релизы.
Остаются очень благодарны :)


SSDT это в принципе прекрасно, но требует винду как минимум для себя, даже если Сервер на Линуксе. Ну и в принципе нативно расчитан именно на окружение МС.
sqitch кросплатформеный но даже рядом с SSDT не стоял по возможностям.

И SSDT не панацея. Разгрести больее менее средних размеров базу можно, особенно если там не совсем треш в хранимках. Из того что видел я в реальности, работы и согласований высчитывалось столько что просто прнималось решение поддерживать что есть, постепенно перенося с новую систему, где также весь новый функционал добавлялся.

И все были довольны. Особенно пред-пенсия которая наплодила эти самые ХП. У них появлялось легаси которое они успешно поддерживали еще несколько лет, пока новая система не перехватила весь функционал.

Самая дикая дичь которую видел, это бизнес логика в ХП и напрямую работающий с базой через ХП и вьюхии клиент на Дельфи, где тоже часть логики. И что с этим делать непонятно. Толи пытаться в этот самый клиент еще коннект к новому серверу добавить, но в макаронах этих никто капаться нехочет. Толи в новом серваке реверс инженерить работу со старой базой. Что в общем тоже особо никто не горел желанием делать.
9 май 21, 19:50    [22319940]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Eleanor
Member

Откуда:
Сообщений: 3385
На проектах c Sql Server мы тоже пользуемся TFS, SSDT, но суффиксы типа _v1, _v2 иногда есть.
Они используются, чтобы при выкладке релиза не делать прерывания работы, когда старая версия сервиса (их обычно несколько штук, и они последовательно друг за другом заменяются на новую версию) не совместима с новой версией ХП.
Логики в ХП по большому счету нет - только подготовка данных, чтобы одним обращением забирать\класть всё, что нужно.
Клиент использует .Net Core. Совместно с Sql Server используется MongoDb, Elastic, Redis.
9 май 21, 20:06    [22319941]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
monsenior
Member

Откуда: Москва
Сообщений: 930
Nelrum
monsenior
пропущено...


Это работает только когда можно залить ваше решение ресурсами.

Видел проект где было много разных баз как склад данных, и аппсервера с логикой и т.д и т.п.
По мере роста нагрузки, добавлялись инстанты аппсерверов - быстро, удобно, и даже менять бизнес код достаточно удобно.

Но, но в один момент времени цена железа для аппсерверов стала запредельна(не за штуку, а за объем).
Спасло переписывание логики на бд и хранимки.

Финансовый результат был примерно такой:
1) Выросли цена лицензий.
2) Сильно вырос ФОТ разрабов + админов(потребовались хорошие спецы по базам).
3) Цена на железо упала в 3 раза, при этом пиковый запас мощности вырос на 50%.

Выгода от п.3 превышала расходы на п1.+п2. где то в 2.5 раза.


Обычно такое случается когда те кто ни на чем кроме SQL писать вменяемый код не в состоянии пытаются писать код на чем-то кроме SQL.


Там были хорошие спецы на javaб базистов пришлось докупать.
До переписывания, код на SQL был из серии select * from, insert, update, delete
11 май 21, 10:39    [22320294]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
monsenior
Member

Откуда: Москва
Сообщений: 930
Nelrum


Megabyte

P. S. У меня на ум приходит только вариант, что фанаты не хранимок просто плохо умеют sql.
Хотел бы ваш вариант услышать?


Вы до сих пор считаете SQL (или любой из его диалектов) тайным знанием которым тяжело овладеть? Вы реально думаете что программисты пишут софт на C++/Java/Python/... да даже долбаном JS, потому что они просто плохо умеют SQL?

SQL не является сакральным знанием как и C++/Java/Python/... да даже добланный JS))
Просто народ забивает гвозди телескопом, и там где нужно использовать SQL используют
C++,C#,JAVA(нужно подчеркнуть или дописать), работает и наоборот, бывает что там где
нужно C++,C#,JAVA(нужно подчеркнуть или дописать используется SQL.

Гибкость языков + дешевые ресурсы позволяют это делать говнокод.
И это делают на 99% проектов, в т.ч. и на Вашем!
11 май 21, 10:54    [22320305]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 2337
monsenior
И это делают на 99% проектов, в т.ч. и на Вашем!

Истинно так!
11 май 21, 11:31    [22320331]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 2337
Megabyte
Моя практика показывает, что такое отношение к хранимкам в целом как к чему-то плохому обычно говорит о том, что человек ничего в жизни сложнее select * from table не писал.

Писал сложнее чем select * from table, к хранимкам, orm и жоопэ отношусь херово. При этом ничего сложнее select * from a join b join c писать принципиально не хочу. Спрашивайте ваши ответы.

Сообщение было отредактировано: 11 май 21, 11:26
11 май 21, 11:34    [22320334]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 [8] 9   вперед  Ctrl      все
Все форумы / Работа Ответить