Comments 9
Дилетантский вопрос: сейчас разве не принято выносить бизнес-логику из СУБД?
У многих принято. Есть разные подходы, и утверждать о правильности одного и ошибочности другого без привязки к конкретному случаю нельзя. И большинство СУБД дают достаточно ограниченные возможности для реализации логики. А Oracle дорогой.
Я бы сказал так: хочешь и умеешь делать логику в базе, есть деньги на Oracle и желание их потратить — прекрасно! Делай логику в базе. Если ответ «нет» хоть по одной из частей вопроса, то надо смотреть, что это за логика и принимать решение.
Если же ты купил Oracle и просто хранишь там данные в табличках — это растрата денег.
Я бы сказал так: хочешь и умеешь делать логику в базе, есть деньги на Oracle и желание их потратить — прекрасно! Делай логику в базе. Если ответ «нет» хоть по одной из частей вопроса, то надо смотреть, что это за логика и принимать решение.
Если же ты купил Oracle и просто хранишь там данные в табличках — это растрата денег.
бизнес-логика в СУБД работает максимально близко к данным
а если её выносить оттуда, то придётся таскать данные из СУБД в другое место и там с ними работать.
а если её выносить оттуда, то придётся таскать данные из СУБД в другое место и там с ними работать.
Вот когда в БД, будет система контроля версий уровня git.
Когда будет система сборки артефактов типа maven.
Все это завязанное в CI/CD (типа Jenkins).
Плюс каждая ХП или пакет будет изолирован в системах контейнеризации типа докер.
Чтобы изменения шли непрерывно, и не надо было бекапить всю БД.
Тогда да.
А т.к. сейчас железо стоит намного дешевле программистов, то проще докупить железо.
Чтобы относительно дешевые программисты писали БЛ в каком-нибудь pyhon/java/C#/Go etc. Чем иметь мегакрутых гуру из 70-х, которые могут эффективно использовать инструменты Oracle.
Когда будет система сборки артефактов типа maven.
Все это завязанное в CI/CD (типа Jenkins).
Плюс каждая ХП или пакет будет изолирован в системах контейнеризации типа докер.
Чтобы изменения шли непрерывно, и не надо было бекапить всю БД.
Тогда да.
А т.к. сейчас железо стоит намного дешевле программистов, то проще докупить железо.
Чтобы относительно дешевые программисты писали БЛ в каком-нибудь pyhon/java/C#/Go etc. Чем иметь мегакрутых гуру из 70-х, которые могут эффективно использовать инструменты Oracle.
Заявочка на холивар? :)
Что мешает хранить исходные коды БД в Git?
… а в 70-х я еще даже не родился.
Но думаю, продолжать смысла нет, ведь оба подхода имеют право на существование. Вопрос в конкретном случае, и целесообразности выбора того или иного пути для него.
Что мешает хранить исходные коды БД в Git?
… а в 70-х я еще даже не родился.
Но думаю, продолжать смысла нет, ведь оба подхода имеют право на существование. Вопрос в конкретном случае, и целесообразности выбора того или иного пути для него.
Почти.
Все говорят о хранении ХП и Пакетов в GIT…
Но как-то это особо не встречал.
А про другое, что можете сказать?
А 70-е это в смысле процедурное программирование в полный рост.
В то время, когда ФП уже вошло в повседневную практику :-)
Все говорят о хранении ХП и Пакетов в GIT…
Но как-то это особо не встречал.
А про другое, что можете сказать?
А 70-е это в смысле процедурное программирование в полный рост.
В то время, когда ФП уже вошло в повседневную практику :-)
Значит не с теми людьми общались. Без хранения программного кода в репозитории работать невозможно, это профнепригодность просто. Не удивлен в таком случае, что у вас скептическое отношение к БЛ в БД. Такой подход к работе я не рассматриваю.
Про «другое» сильно от задачи зависит. Если инстансов базы мало ( в идеале один), то вопрос решается организационно, в том числе и с помощью ГИТа. Сделать скрипты, компилирующие все что нужно — не так сложно. Остальное (то, что не в базе) собирайте как хотите. Но нужна синхронизация действий.
Если инстансов множество, и, допустим, у вас нет к ним доступа — нужно наладить выпуск патчей для их обновления. Но в последнем случае, я бы крепко задумался о БЛ в БД.
Идеальная ситуация для такого подхода — один облачный сервер и множество клиентов. Тогда проблем вообще нет. Либо крупные системы типа биллинга в сотовой связи, где клиентов по пальцам пересчитать можно.
Про «другое» сильно от задачи зависит. Если инстансов базы мало ( в идеале один), то вопрос решается организационно, в том числе и с помощью ГИТа. Сделать скрипты, компилирующие все что нужно — не так сложно. Остальное (то, что не в базе) собирайте как хотите. Но нужна синхронизация действий.
Если инстансов множество, и, допустим, у вас нет к ним доступа — нужно наладить выпуск патчей для их обновления. Но в последнем случае, я бы крепко задумался о БЛ в БД.
Идеальная ситуация для такого подхода — один облачный сервер и множество клиентов. Тогда проблем вообще нет. Либо крупные системы типа биллинга в сотовой связи, где клиентов по пальцам пересчитать можно.
Вот, например. Но вообще, мы svn используем (а до этого были ClearCase, TFS и много чего ещё, на других заказчиках).
Sign up to leave a comment.
Можно ли использовать Tibero вместо Oracle. И нужно ли