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

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

Вован Барабан
я хоть ярый противник хп и любой логики в базе, имею реальный опыт когда хп может хорошо работать, как наименьшее из зол. например в бытность работы на ржд было возможностью обеспечить хоть какой то контракт при интеграции, в отличие от того же data propagator с db2.


Аналогично, коллега. ХП не абсолютное зло в моём понимании, действительно бывают ситуации, когда использование этой способности оправдано. Никто их хоронить не собирался и не собирается. Речь о том, чтобы избегать по максимуму размещение логики в БД. Нет в этом никакого смысла и никакой нужды.
6 май 21, 01:11    [22319068]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Eleanor
Member

Откуда:
Сообщений: 3385
Экзадаты, Оракл, ХП - это дорогие вещи, а бизнес хочет быстро и дешево: orm, commodity железо, микросервисы, MongoDb.
Только "дешево" - это как-то не то, чем хочется гордиться, поэтому и начинаются рассказы про современность-продвинутость.
6 май 21, 07:48    [22319096]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
PsyMisha
Member

Откуда: другая столица
Сообщений: 828
fixxer
Видимо, не все понимают, что дежурство это не красноглазить перед монитором круглосуточно в ожидании, что сломается. Это просто быть досягаемым по телефону и с возможностью доступа к компьютеру/лаптопу. А так спи, пожалуйста или своими делами занимайся. У нас в компании есть ротация, предлагают (добровольно) после полугода или как готов будешь. И мало кто отказывается, потому что звонят от силы два-три раза в год, а полштуки евриков доплаты за то что ты 27/7 officer капает каждый месяц.


Просто с языка сняли. Ровно так и было на одной из прошлых работ, - позвонить могли индусы ночью, но звонки были крайне редки, а "on duty person" получал приятное дополнение к месячной зарплате.
Только у нас и в этом случае своими номерами не светились - был выделенный корпоративный айфон, который физически был в недельной ротации у членов команды в локальном хабе
6 май 21, 10:47    [22319129]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 2048
hVostt
Вован Барабан
я хоть ярый противник хп и любой логики в базе, имею реальный опыт когда хп может хорошо работать, как наименьшее из зол. например в бытность работы на ржд было возможностью обеспечить хоть какой то контракт при интеграции, в отличие от того же data propagator с db2.


Аналогично, коллега. ХП не абсолютное зло в моём понимании, действительно бывают ситуации, когда использование этой способности оправдано. Никто их хоронить не собирался и не собирается. Речь о том, чтобы избегать по максимуму размещение логики в БД. Нет в этом никакого смысла и никакой нужды.


Есть смысл логику держать ближе к данным, а не тягать данные по сети лишний раз. Люди оптимизируют даже лишние походы в буфферный кеш - кешируют что можно в пга(это если про pl/sql), минимизируют i/o внутри сервера ибо пропускная способность каналов i/o не соответствует производительности флеш массивов - exadata offloading (часть работы на процах прикрученых напрямую к стораджу).
6 май 21, 11:34    [22319151]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 2048
hVostt

Нормально живём. Вот, например мы, от аутсорсера, который годами писал систему в Оракле на ХП — отказываемся. Потому что за пол года полностью переписали систему без ХП, используя несколько систем хранения данных, под каждый класс задач. А отказываемся потому что цена любой грошовой доработки сейчас на этой системе, построенной на ХП стоит десятки миллионов и несколько месяцев.

И тормозит это убожество так, что не приведи Господь. А для отчётов уже давно ребята тупо вытягивают себе данные, раскладывают как надо и строят отчёты на чистом SQL-е, в режиме реалтайм.


вот я например как-то натюнил базу так, даже без особых переписываний логики-запросов что одно модное распределенное на сотню мощных аппликейшн серверов приложение так полетело в космос что оказалось что не нужна эта сотня серверов - и парочка справится) думаешь ооп/орм-говнокодеров меньше, чем процедурных?
6 май 21, 11:40    [22319153]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Вован Барабан
Member

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

далеко не вся логика может/должна быть завёрнута на базу, где-то надо в онлайне считать.
Архитектурно относиться к базе как просто к хранилке - норм решение. Вообще последнее время баз больше чем на 25 таблиц не видел, там и орм сойдёт. Большие бд обычно в легаси, зибель, хайперион, оракловые продукты, и т.п.
Тут даже на одном собесе требовали знание оптимизации запросов, оконные функции на память, от меня, от джависта, я сказал что для этого лучше нанять dba. Поэтому делаю вывод, что работа с дб считается нынче побочкой, типа знания пайтона.
6 май 21, 13:12    [22319194]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 2048
Вован Барабан
Melkomyagkii_newbi,

далеко не вся логика может/должна быть завёрнута на базу, где-то надо в онлайне считать.
Архитектурно относиться к базе как просто к хранилке - норм решение. Вообще последнее время баз больше чем на 25 таблиц не видел, там и орм сойдёт. Большие бд обычно в легаси, зибель, хайперион, оракловые продукты, и т.п.
Тут даже на одном собесе требовали знание оптимизации запросов, оконные функции на память, от меня, от джависта, я сказал что для этого лучше нанять dba. Поэтому делаю вывод, что работа с дб считается нынче побочкой, типа знания пайтона.


где-то побочка, где-то это основа и необходимость. но говорить что "устаревшая технология", если на каких-то проектах можно обойтись экселем - тупо.
6 май 21, 14:14    [22319226]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
DaniilSeryi
Member

Откуда:
Сообщений: 1935
Вован Барабан

Тут даже на одном собесе требовали знание оптимизации запросов, оконные функции на память, от меня, от джависта


Не ВТБ случаем?

Сообщение было отредактировано: 6 май 21, 14:16
6 май 21, 14:17    [22319228]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
PsyMisha
Member

Откуда: другая столица
Сообщений: 828
Вован Барабан

Вообще последнее время баз больше чем на 25 таблиц не видел


Это вы еще Microsoft Dynamix Axapta не ковыряли)
А в базе, между прочим, при её полторы тыщи таблиц - с внешними ключами не очень - логическая целостность делается на уровне приложения, а не БД
6 май 21, 14:27    [22319235]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Вован Барабан
Member

Откуда:
Сообщений: 230
Melkomyagkii_newbi
Вован Барабан
Melkomyagkii_newbi,

далеко не вся логика может/должна быть завёрнута на базу, где-то надо в онлайне считать.
Архитектурно относиться к базе как просто к хранилке - норм решение. Вообще последнее время баз больше чем на 25 таблиц не видел, там и орм сойдёт. Большие бд обычно в легаси, зибель, хайперион, оракловые продукты, и т.п.
Тут даже на одном собесе требовали знание оптимизации запросов, оконные функции на память, от меня, от джависта, я сказал что для этого лучше нанять dba. Поэтому делаю вывод, что работа с дб считается нынче побочкой, типа знания пайтона.


где-то побочка, где-то это основа и необходимость. но говорить что "устаревшая технология", если на каких-то проектах можно обойтись экселем - тупо.

моя сентенция лишь к тому, что профессия dba нынче сильно недооценена, что очень жаль
6 май 21, 14:41    [22319241]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Вован Барабан
Member

Откуда:
Сообщений: 230
DaniilSeryi
Вован Барабан

Тут даже на одном собесе требовали знание оптимизации запросов, оконные функции на память, от меня, от джависта


Не ВТБ случаем?

альфа и ее клоны, сбербанк
в сбере на один из проектов требовалось доскональное знание субд, wtf, от джависта, серьезно?
в втб тоже нет выделенной роли, но хотя бы особых знаний и не спрашивают
6 май 21, 14:44    [22319243]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 2048
Вован Барабан

в сбере на один из проектов требовалось доскональное знание субд, wtf, от джависта, серьезно?

от проекта зависит, если надо плотно работать с высоконагруженной 24/7 бд и там не реализовано на pl/sql(ага) апи, то не напасешься дба потом за вами подчищать.
6 май 21, 15:56    [22319269]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 65941
Блог
Вован Барабан
далеко не вся логика может/должна быть завёрнута на базу, где-то надо в онлайне считать.

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

Стартовая точка для проектирования - это один кирпич, всё вместе. Потому, что самое простое и удобное. Каждый раз, когда архитектор хочет отломать часть и отложить в сторону, сделать на кирпич больше, ему нужен внятный ответ: что плохо в одном кирпиче и станет лучше, если отломать. Например, клиент-серверные приложения появились потому, что в одном кирпиче (файл-серверных) не удалось решить проблему эффективной многопользовательской работы с данными. Если бы в те времена была какая-нибудь готовая к использованию NUMA - вполне вероятно, двухзвенок бы просто не возникло, они были бы не нужны.

Трёхзвенные приложения появились как ответ на задачи, которые было тяжело или невозможно решить внутри СУБД. Обращаю внимание - тех СУБД, которые были в начале 90-х. Классическим примером тогда приводили обработку изображений - мол, на SQL это делать ну крайне проблематично. Были и другие - организация взаимодействия нескольких распределённых СУБД итп. И вот здесь есть момент, про который не пишут в книжках "Трёхзвенки для чайников", поэтому ряд посетителей форума о нём не в курсе. СУБД уже не те, которые были, когда Вася Пупкин шёл в трёхзвенку, потому что Oracle слишком дорогой, а MySQL ни хрена не умеет. Возможности того, что можно сделать внутри СУБД, нарастают. Существенно и принципиально нарастают. И это подрывает питательную базу трёхзвенок. Аргумент "трёхзвенка нужна, потому что в двузвенке этого не сделать" становится всё более и более не соответствующим действительности.

Лично я думаю, что постепенно оно сольётся. То есть удачные решения по "аппсерверам" и по "базам данных" в итоге окажутся под одной оболочкой. Просто потому, что это выигрывает по качеству.
6 май 21, 16:03    [22319273]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
visweden
Member

Откуда:
Сообщений: 388
softwarer

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


Слова "аппсерверам" и "качество" в одном предложении звучат как оксюморон

softwarer ну ты же кроме как суровый модератор еще и вроде как серьезный С++ программист

Как ты можешь такое произносить на публике ?

Сообщение было отредактировано: 6 май 21, 16:08
6 май 21, 16:16    [22319278]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
hVostt
Member

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


Я не имел в виду именно ОРМ/ОПП. Обычно именно ОРМ противопоставляют размещению логики в БД. Хотя именно ОРМ умеют прекрасно работать через ХП.

Суть вообще в другом. Где логика?
6 май 21, 19:08    [22319328]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
hVostt
Member

Откуда:
Сообщений: 19322
softwarer
Вован Барабан
далеко не вся логика может/должна быть завёрнута на базу, где-то надо в онлайне считать.

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

Стартовая точка для проектирования - это один кирпич, всё вместе. Потому, что самое простое и удобное. Каждый раз, когда архитектор хочет отломать часть и отложить в сторону, сделать на кирпич больше, ему нужен внятный ответ: что плохо в одном кирпиче и станет лучше, если отломать. Например, клиент-серверные приложения появились потому, что в одном кирпиче (файл-серверных) не удалось решить проблему эффективной многопользовательской работы с данными. Если бы в те времена была какая-нибудь готовая к использованию NUMA - вполне вероятно, двухзвенок бы просто не возникло, они были бы не нужны.

Трёхзвенные приложения появились как ответ на задачи, которые было тяжело или невозможно решить внутри СУБД. Обращаю внимание - тех СУБД, которые были в начале 90-х. Классическим примером тогда приводили обработку изображений - мол, на SQL это делать ну крайне проблематично. Были и другие - организация взаимодействия нескольких распределённых СУБД итп. И вот здесь есть момент, про который не пишут в книжках "Трёхзвенки для чайников", поэтому ряд посетителей форума о нём не в курсе. СУБД уже не те, которые были, когда Вася Пупкин шёл в трёхзвенку, потому что Oracle слишком дорогой, а MySQL ни хрена не умеет. Возможности того, что можно сделать внутри СУБД, нарастают. Существенно и принципиально нарастают. И это подрывает питательную базу трёхзвенок. Аргумент "трёхзвенка нужна, потому что в двузвенке этого не сделать" становится всё более и более не соответствующим действительности.

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


В реальности ничего такого не происходит, ничего не сливается, а происходит всё ровно наоборот.
Если оно и сольётся, то видимо только по щелчку какого-то божества, и никак иначе.

Это всё равно что говорить, язык Perl — язык будущего! И ничего, что уже много лет как он стремительно теряет свои позиции, люди не хотят писать на этом языке, да и не пишут новые проекты давно на нём. Но всё когда-нибудь будет на Перле, вижу будущее как на духу
6 май 21, 19:21    [22319331]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Nelrum
Member

Откуда:
Сообщений: 352
Melkomyagkii_newbi
hVostt
пропущено...


Аналогично, коллега. ХП не абсолютное зло в моём понимании, действительно бывают ситуации, когда использование этой способности оправдано. Никто их хоронить не собирался и не собирается. Речь о том, чтобы избегать по максимуму размещение логики в БД. Нет в этом никакого смысла и никакой нужды.


Есть смысл логику держать ближе к данным, а не тягать данные по сети лишний раз. Люди оптимизируют даже лишние походы в буфферный кеш - кешируют что можно в пга(это если про pl/sql), минимизируют i/o внутри сервера ибо пропускная способность каналов i/o не соответствует производительности флеш массивов - exadata offloading (часть работы на процах прикрученых напрямую к стораджу).


Ближе к данным? У вас БД в одну ноду? И как вы гарантрируете что выполенение идет на тойже ноде что и данные?
Вас не смущает забивание памяти и ЦП на сервере где БД расчетами бизнес логики?
6 май 21, 19:37    [22319333]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 2048
Nelrum
Melkomyagkii_newbi
пропущено...


Есть смысл логику держать ближе к данным, а не тягать данные по сети лишний раз. Люди оптимизируют даже лишние походы в буфферный кеш - кешируют что можно в пга(это если про pl/sql), минимизируют i/o внутри сервера ибо пропускная способность каналов i/o не соответствует производительности флеш массивов - exadata offloading (часть работы на процах прикрученых напрямую к стораджу).


Ближе к данным? У вас БД в одну ноду? И как вы гарантрируете что выполенение идет на тойже ноде что и данные?
Вас не смущает забивание памяти и ЦП на сервере где БД расчетами бизнес логики?


может и на одной, может рак, может active-active на репликации, может еще как-то. Соответствующий роутинг на сервисы, есть способы. А чем еще занять например сотни-тысячи потоков и террабайты памяти? Думаете создатели и заказчики экзадаты или суперкластеров м8-8 дурачки и создали такие тачки не под конкретные задачи которые по другому не особо решаются? Что вас смущает, что одни люди прикручивают процессоры к стораджам, а другие готовы по сети гонять те же данные чтобы на аппсерверах то же самое вычислить?
6 май 21, 19:55    [22319335]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
fixxer
Member

Откуда:
Сообщений: 835
Melkomyagkii_newbi
А чем еще занять например сотни-тысячи потоков и террабайты памяти? Думаете создатели и заказчики экзадаты или суперкластеров м8-8 дурачки и создали такие тачки не под конкретные задачи которые по другому не особо решаются?


То есть сначала потратили миллионы на железо, а потом думаем как бабки отбить? Такая тема выгодна только оракл-цыганам и CTO на откатах.

Сообщение было отредактировано: 6 май 21, 19:59
6 май 21, 20:05    [22319338]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Melkomyagkii_newbi
Member

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


Я не имел в виду именно ОРМ/ОПП. Обычно именно ОРМ противопоставляют размещению логики в БД. Хотя именно ОРМ умеют прекрасно работать через ХП.

Суть вообще в другом. Где логика?


Это был ответ на

автор
Нормально живём. Вот, например мы, от аутсорсера, который годами писал систему в Оракле на ХП — отказываемся. Потому что за пол года полностью переписали систему без ХП, используя несколько систем хранения данных, под каждый класс задач. А отказываемся потому что цена любой грошовой доработки сейчас на этой системе, построенной на ХП стоит десятки миллионов и несколько месяцев.

И тормозит это убожество так, что не приведи Господь. А для отчётов уже давно ребята тупо вытягивают себе данные, раскладывают как надо и строят отчёты на чистом SQL-е, в режиме реалтайм.


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

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


Что значит не смог в ХП? Очень даже смог, и вполне успешно надо сказать. Для своего-то времени. Нагрузки, которые система выдерживает и выдерживала -- колоссальные.

Убожество, это то, во что превратилась система сейчас. Просто чихнуть боятся. Любое изменение может положить систему на бока. Что уже случалось несколько раз. Доработки сверх-дорогие, как по деньгам, так и по времени. И да. Сегодня оно тормозит.

Но это был контрответ-история на историю. Так что не вникайте, ведь всегда можно сказать. Вы просто не умеете клеить на сопли, поэтому у вас всё отваливается. Просто не осилили технику соплей ))
6 май 21, 20:59    [22319351]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1996
Melkomyagkii_newbi
Есть смысл логику держать ближе к данным, а не тягать данные по сети лишний раз.


Так делается в hadoop или Ignite/GridGain
6 май 21, 21:16    [22319359]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 2048
fixxer
Melkomyagkii_newbi
А чем еще занять например сотни-тысячи потоков и террабайты памяти? Думаете создатели и заказчики экзадаты или суперкластеров м8-8 дурачки и создали такие тачки не под конкретные задачи которые по другому не особо решаются?


То есть сначала потратили миллионы на железо, а потом думаем как бабки отбить? Такая тема выгодна только оракл-цыганам и CTO на откатах.


откуда такой вывод? Я имел ввиду как раз обратное, бизнес задачи - первичны, потом пилятся-развиваются продукты/прототипы, замеряется пропускная способность, узкие места, потом если многие(или очень жирные) заказчики сталкиваются с какими-то проблемами - вендор либо уже имеет железки/софт для их удовлетворения, либо допиливает/пилит новые - зная, что его разработки окупятся так как ряд заказчиков спит и видит, просит нарастить производительность в местах где у них затыки дабы начать собирать еще больше бабла. И заказчик знает, что на такой железке он сможет увеличить количество своих бизнес операций - если ему это выгодно - покупает. Грубо говоря.
Как думаете все крупные банки/телекомы/биржи и подобное - отбивают бабки на такое железо или им уже хвост все переписал и они счастливо полетели в космос наконец не на проклятущих устаревших хп? Или завтра это будет? Или когда они упрутся в потолок/узкое место они сложат ручки и скажут, ну ок - всех денег не заработать, останемся на таком количестве бизнес операций, новых клиентов не брать(вместо того чтобы купить железку повеселей)? Или чтоб без оракла, но чтоб acid и масштабировалось и всякие требования по безопасности вывозило перевезут бизнес логику куда-то - может когда-то и напишут такой софт(для всех бизнесов где важен acid), но пока нет и даже если вот сейчас решишь писать свой ин хаус подобного сорта, то маловероятно выдумаешь такую архитектуру которая будет лучше и дешевле таковой на оракле. Поэтому пилят на оракле и новое, и нагрузки растут, и он развивается, и железки под него точатся и где там что устарело - не понятно, инструмент как инструмент, в том числе для логики которая связана с данными, что даст ее вынос подальше от системы хранения - не очень понятно.
автор
действительно бывают ситуации, когда использование этой способности оправдано
но
автор
Нет в этом никакого смысла и никакой нужды.
6 май 21, 21:28    [22319363]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
hVostt
Member

Откуда:
Сообщений: 19322
Melkomyagkii_newbi
автор
действительно бывают ситуации, когда использование этой способности оправдано
но
автор
Нет в этом никакого смысла и никакой нужды.


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

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

Тем более, на код хранимок обычно без кровавых слёз не взглянешь. Хуже T/PL-SQL только ABAP, который придумали наследники Гитлера, чтобы люди страдали :)
6 май 21, 22:59    [22319379]     Ответить | Цитировать Сообщить модератору
 Re: Ночные дежурства  [new]
hVostt
Member

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


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

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

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

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