powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Будущее Oracle DBA v 1.1
25 сообщений из 125, страница 3 из 5
Будущее Oracle DBA v 1.1
    #39669825
казинак
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
-2-казинакпропущено...
между прочим это именно айбиэм и оракл двигают жавуА БМВ двигают велосипеды. На замену своим же автомобилям, где узкое место водитель и пассажиры не масштабируются более положенных сидячих мест. Хотя... если ремни безопасности реализовать на уровне - держаться рукой за переднее кресло, можно на заднем сидении вместо трех и пятерых пассажиров посадить, а если вместо isofix применить коленки родителей, то еще двоих-троих детей ту да же.
какое-то словесное недержание

-2-казинакпропущено...
а про сервер в никуда - ваще бред, не знаешь, так хоть не позорьсяПоздно, уже опозорился. Для осознания "тупо добавить" у меня недостаточно квалификации. Пришлось воспользоваться документацией на сайте Томката. Смотрю раздел Apache Tomcat Clustering ...
ты походу кластер бд не отличаешь от кластера серверов приложений
кластеру сервера приложений не надо consistency данных обеспечивать
это просто дополнительный процесс, который перестартует упавшие/зависшие жава машины

неохото мне ликбезом заниматься, читай доки
елика, тоже с собой возьми
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39669849
Фотография kinky cat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
казинакв фейсбуке ни форин кей констрейнтов, ни джойнов в базе не делают
все на серверах приложений

..чушь тихонько повизгивала...
Они всего лишь prestodb разработали, где практически ansi
https://prestodb.io/docs/current/sql/select.html
При том у них совсем другая задача - Big Data, логика относительно простая, но даже в ней они без sql и джойнов не обошлись.
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39669855
казинак
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kinky catказинакв фейсбуке ни форин кей констрейнтов, ни джойнов в базе не делают
все на серверах приложений

..чушь тихонько повизгивала...
Они всего лишь prestodb разработали, где практически ansi
https://prestodb.io/docs/current/sql/select.html
При том у них совсем другая задача - Big Data, логика относительно простая, но даже в ней они без sql и джойнов не обошлись.
я там не работал, доказать не смогу, но первый же нагугленный линк говорит
авторMySQL - используется как хранилище пар ключ-значение, никаких join'ов
https://www.insight-it.ru/highload/2010/arkhitektura-facebook/
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39669859
Фотография kinky cat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39669874
MaximaXXL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
казинакMaximaXXLпропущено...


ага, а потом приложения втянув в себя 16+ Гб данных из таблиц валятся с переполнением памяти ... а всего то надо было селектик написать и получить постранично (по 100 например) записей. Так нет жеж, мы все вытянем и в памяти быстро соберем/обработаем. Мы же однотабличные селекты делать умеем ...

А еще можно пожаловаться что надо памяти докупить, это всегда проще чем код оптимизировать ...
сдуру конечно можно и хер сломать
только никто не будет 16Гб тянуть из базы
просто последовательно сделают
сначала по параметрам с формы вытащат айди регионов, например,
потом, айди наименований товаров
а потом из таблицы транзакций вытащат нужные транзакции
ну это к примеру

Ну если к примеру:
Есть 2 таблицы:
таб1 (Отдел, Сотрудник) - все сотрудники предприятия
таб2 (Сотрудник, Время прихода/ухода) - только те сотрудники которые приходили

ну и надо увидеть те отделы где на работу приходили все сотружники.

Расскажите мне несведущему, как Вы его реализуете не делая объединение таблиц в одном селекте?
И это ОЧЕНЬ простой пример
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39669891
казинак
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kinky catказинак,
учитесь для начала гуглить
https://www.facebook.com/notes/facebook-engineering/presto-interacting-with-petabytes-of-data-at-facebook/10151786197628920/?s=keen-io
ну меряться линками глупо
но даже в вашем линке написано "The Presto system is implemented in Java"

такшто, оракл бд там, какбэ нету,
и ваш агрумент только подтверждает уменьшение потребности оракл админов и прогеров
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39669895
казинак
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MaximaXXLказинакпропущено...

сдуру конечно можно и хер сломать
только никто не будет 16Гб тянуть из базы
просто последовательно сделают
сначала по параметрам с формы вытащат айди регионов, например,
потом, айди наименований товаров
а потом из таблицы транзакций вытащат нужные транзакции
ну это к примеру

Ну если к примеру:
Есть 2 таблицы:
таб1 (Отдел, Сотрудник) - все сотрудники предприятия
таб2 (Сотрудник, Время прихода/ухода) - только те сотрудники которые приходили

ну и надо увидеть те отделы где на работу приходили все сотружники.

Расскажите мне несведущему, как Вы его реализуете не делая объединение таблиц в одном селекте?
И это ОЧЕНЬ простой пример
элментарно
в одну коллекцию тащим первую таблицу, в другую - вторую
и объединяем коллекции
ессно там наверняка фильтры будут, например, приходы/уходы за месяц
да даже если не будут, объединяем и кэшируем, если надо
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39669913
MaximaXXL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
казинакMaximaXXLпропущено...


Ну если к примеру:
Есть 2 таблицы:
таб1 (Отдел, Сотрудник) - все сотрудники предприятия
таб2 (Сотрудник, Время прихода/ухода) - только те сотрудники которые приходили

ну и надо увидеть те отделы где на работу приходили все сотружники.

Расскажите мне несведущему, как Вы его реализуете не делая объединение таблиц в одном селекте?
И это ОЧЕНЬ простой пример
элментарно
в одну коллекцию тащим первую таблицу, в другую - вторую
и объединяем коллекции
ессно там наверняка фильтры будут, например, приходы/уходы за месяц
да даже если не будут, объединяем и кэшируем, если надо

Вот и получаеться Вы тянете 16+ ГБ данных, вместо 2 строчек. А если сервера БД нахожятся в Маями а сервера приложений в Лондоне ... то лучше написать один правильный запрос чем укатывать сервера приложений ... с криками, добавте памяти

То же относиться и к справочникам, иногда полезно иметь ин-мемори, но они должны быть не простыми (например, не нашел ин-мемори - полез в базу). Иначе кто-то добавит(а не дай бог исправит роутинг) в справочнике, а Вы об этом не знаете и по своей ин-мемори отправите транзакцию в другое приложение и разрушите бизнес логику. А это уже совсем плохо
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39669922
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
казинакты походу кластер бд не отличаешь от кластера серверов приложений
кластеру сервера приложений не надо consistency данных обеспечивать
Ты путаешь социальную помойку с информационной системой. Если слетела подписка или странности с количеством лайков, всегда можно списать на руку Кремля или происки Госдепа.

казинакэто просто дополнительный процесс, который перестартует упавшие/зависшие жава машины

неохото мне ликбезом заниматься, читай докиДокументация томката clustering how-to пишет про репликацию сессий и предостерегает от "тупо добавил" для больших систем.

казинакв одну коллекцию тащим первую таблицу, в другую - вторую
и объединяем коллекции
ессно там наверняка фильтры будут, например, приходы/уходы за месяц
да даже если не будут, объединяем и кэшируем, если надоМногие здесь проходили это "объединяем" в эпоху beforesql на прогрессивном dbase. Но потом объемы подросли, требования усложнились и вложенный цикл (нестед-луп) перестал покрывать все потребности. Потом захотелось не тупить, когда данные меняют более одного пользователя, потом прочий acid ... и dbase сдулся.
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39669925
казинак
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MaximaXXLВот и получаеться Вы тянете 16+ ГБ данных, вместо 2 строчек.
это с какого перепугу?
применяем фильтры тащим из одной таблицы, отфильтрованное, а потом, по результатам первой, тащим из второй

MaximaXXLТо же относиться и к справочникам, иногда полезно иметь ин-мемори, но они должны быть не простыми (например, не нашел ин-мемори - полез в базу). Иначе кто-то добавит(а не дай бог исправит роутинг) в справочнике, а Вы об этом не знаете и по своей ин-мемори отправите транзакцию в другое приложение и разрушите бизнес логику. А это уже совсем плохо
кэши обновлять можно по требованию, то бишь после изменений
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39669966
MaximaXXL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
казинакMaximaXXLВот и получаеться Вы тянете 16+ ГБ данных, вместо 2 строчек.
это с какого перепугу?
применяем фильтры тащим из одной таблицы, отфильтрованное, а потом, по результатам первой, тащим из второй

Да с такого, что Вы уже вытащили данные из 2-й таблицы чтоб их проанализировать (это уже более 2 строчек)
А далее Вам надо вытащить все данные из первой, потому как Вы не можете из вытащенных данных сформировать полный фильтр, в класcике банальный Left Join без полных данных первой таблицы сложно организовать. Но и так, взяв данные из второй таблицы вы получаете НАМНОГО больше данных чем пришлет результирующий селект.

казинакMaximaXXLТо же относиться и к справочникам, иногда полезно иметь ин-мемори, но они должны быть не простыми (например, не нашел ин-мемори - полез в базу). Иначе кто-то добавит(а не дай бог исправит роутинг) в справочнике, а Вы об этом не знаете и по своей ин-мемори отправите транзакцию в другое приложение и разрушите бизнес логику. А это уже совсем плохо
кэши обновлять можно по требованию, то бишь после изменений
Можно кеши обновлять "по требованию" но опять таки - Вы будете тянуть все данные, а их может быть не мало и тянете Вы их для того чтоб получить колекцию для работы с чем? Если с данными из базы (вытянутые другим селектом) то может разумнее написать 1 правильный селект, а не городить огород? Данные кеша обновляються не моментально... Ставить всех на холд для обновления кешей зачастую так себе практика.

Я много лет работаю с джавистами и они осознали силу sql.
Даже если им надо что-то на 1 фильтр (например отчет МОЖЕТ вытягянуть 10+ ГБ, потому что в форме чел может указать очень поверхносно фильтр) и джависты этого не делали раньше, они приходят и мы обсуждаем как лучше. Уже давно они отошли от практики вытянем все и в памяти все быстро сделаем. Хотя еще приходят "молодые дарования" которые мыслят аналогично Вашему, но лабы в институте и реальная работа это разные вещи.
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39670078
Фотография dbms_photoshop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Как-то дискуссия не в то русло немного утекла. Начиналось все с вопроса про DBA и уход в cloud.
А, еще почему-то автора интересует Россия хотя сам он там не обитает и контактов не имеет.

Несколько моментов

1. Облака
Действительно в западном мире ведется активный выход в облако (включая банковскую сферу и прочие sensitive data) и действительно это уже привело (и тренд продолжается) к уменьшению вакансий DBA.
Еще Oracle продвигает свои мега-технологии под названием "the self-driving database" и "Oracle autonomous database", что призвано уменьшить число DBA... правда оно может и наоборот потребовать больше человеческих ресурсов, но в этом случае можно отключить (как некоторые типа меня делают с другими особо интеллектуальными технологиями типа cardinality feedback или adaptive plans).
Возвращаясь к России, достаточно разумно что компании намного менньше ведуться на вывод своих данных в облако, владеемое юр лицом другой страны.

2. Удешевление железа и в частности оперативки + увеличение объемов данных.
Предпринимается много попыток перенести базы в кластера, в частности хадуп. И это действительно приводит к уменьшению потребности в ораклистах, но есть несаолько моментов.
Как бало замечено, надо полностью осознавать, что ACID не поддерживается (хотя дяди, выделяющие бюджеты ведутся на маркетинговый буллщит типа limited ACID support от чего в итоге страдают все).
И, второе, даже когда пришло осознание что всякие хадупы не вариант для OLTP, то даже для DWH/OLAP возникают серьезные проблемы с масштабируемостью по нагрузке (число одновременно запущенных запросов по простому), а во вторых недопустимая latency. Внезапно обраруживается, что типичное время отзыва не конкурирует с аналогичной логикой в Оракле.
И тут приходит новый тренд - кластер но уже в памяти. Что-то в духе гибрида GridGain + Hadoop .
Как бы там ни было это таки сжимает долю Оракла.

3. Отупение среднестатистического специалиста.
Этот тренд скомбинирован с пунктом 2.
В общем ситуация такая: снижаются издержки на человеческий ресурс и на дорогое ПО типа Оракла и вместо этого вбухивается в железо.
Никто особо не пытается понимать как работает оптимизатор запросов (про такое понятие как query transformations знает вообще наверное менее 5%),
мало кто умеет нормально анализировать куда уходит время и ресурсы при обработке данных.
Вместо этого давайте пытаться перейти на кластер, использовать разнообразные кеши и прочее... мало у кого взлетает.
Люди которые были не в состоянии delivery on mature software вдруг терпят крах на сырых технологиях - внезапно!
Но тенденция есть и долю Оракла это тоже уменьшает.

4. Жадность Ларри и замедленная приспособляемость к реалиям.
Важный архитектурный недостаток Оракла - остуствие columnar storage. Это достаточно критично для больших хранилищ.
Всякие hybrid columnar compressionна на то и гибрид, что это не полноценный колоночный формат.
Вроде бы многообещающе выглядит in-memory column store, но влетает в копеечку.
И на волне общего хайпа касательно хадупа, клстеров и прочих in-memory caches мало кто рассматривает инвестицию в Oracle in-memory option.
Доля рынка на крупных хранилищах уходит.
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39670112
Фотография dbms_photoshop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WolverinesВ этом есть ценность человека - желание улучшать процессы в компании. В Cloud кто этим будет заниматься? Просто купим больше дисков, больше памяти, больше CPU.Может в каком-то "Рога и копыта" у админа болит душа как сэкономить на железе, особено если он друг владельца или директора или имеет на этом фоне хорошие премии, но во всяких крупных бизнесах, которые являются основными потребителями Оракла есть DBA team и есть application team.
application team смотрит насколько эффективно приложение потребялет ресурсы и насколько отзывчиво к пользователю.
При переходе в облако ничего особо не меняется, если есть доступ к oracle performance views.
А вот DBA team в принципе исчезает.
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39670204
Wolverines
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbms_photoshopWolverinesВ этом есть ценность человека - желание улучшать процессы в компании. В Cloud кто этим будет заниматься? Просто купим больше дисков, больше памяти, больше CPU.Может в каком-то "Рога и копыта" у админа болит душа как сэкономить на железе, особено если он друг владельца или директора или имеет на этом фоне хорошие премии, но во всяких крупных бизнесах, которые являются основными потребителями Оракла есть DBA team и есть application team.
application team смотрит насколько эффективно приложение потребялет ресурсы и насколько отзывчиво к пользователю.
При переходе в облако ничего особо не меняется, если есть доступ к oracle performance views.
А вот DBA team в принципе исчезает.
А application team почему выживает?)) Приложеньки еще проще вынести, сам разработчик сразу после тестов деплоит контейнеры в облако.
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39670232
Фотография dbms_photoshop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Wolverines,

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

Но как я отметил основных тренда два
1. уменьшается доля ДБА из-за облака и разнообразных атоматизаций. Это влияет только на ДБА.
2. уменьшается доля Оракла в целом как из-за нездорового хайпа касательно новых подходов так и по некоторым объективным причинам. Это влияет и на разрабов.
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39670259
Wolverines
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dbms_photoshopWolverines,
application team это те, кто пишет приложение.
Ок, думал, что application team это люди, которые поддерживают апликейшен сервера.
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39670283
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Меня приводит в легкое изумление доверчивость бизнеса к облакам.
Отдать свои чувствительные данные под фактический чужой контроль - модель поведения, в чем-то созвучная девизу "слабоумие и отвага".
Полагаю, в данном случае скорее это вопрос веры и маркетинга.
Веры в cloud-провайдеров с просветленными лицами, привнесенной в бизнес мессиями от маркетинга.

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

...впрочем, за любым увлечением очередной новомодностью следует неизбежный откат.
Не думаю, что DBA как профессия неизбежно отомрет в ближайшие годы.
В конце концов, тем же клаудам нужны высокопрофессиональные администраторы, а это достигается планомерной селекцией, для которой необходима широкая "кормовая база" (или "поголовье" - кому как удобнее) администраторов обыкновенных.
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39670362
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymous, жизненный цикл менеджмента обычно короче жизненного цикла компаний.
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39670387
Фотография Relic Hunter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Железный конь идет на смену крестьянской лошадке. (С)
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39670423
казинак
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
-2-казинакты походу кластер бд не отличаешь от кластера серверов приложений
кластеру сервера приложений не надо consistency данных обеспечивать
Ты путаешь социальную помойку с информационной системой. Если слетела подписка или странности с количеством лайков, всегда можно списать на руку Кремля или происки Госдепа.
опять понос


-2-Документация томката clustering how-to пишет про репликацию сессий и предостерегает от "тупо добавил" для больших систем.
двоюшник, то б хоть раз по делу чо написал
а то только понос один

ну какой смысл чота с тобой обсуждать?
репликация сессий, блин, прочитал словечко и думаешь уел?
даж не буду объяснять
просто, я сам конфигурил веблоджики в кластер и без кластера
а ты только отдельные фразы из доки выдергиваешь

-2-казинакв одну коллекцию тащим первую таблицу, в другую - вторую
и объединяем коллекции
ессно там наверняка фильтры будут, например, приходы/уходы за месяц
да даже если не будут, объединяем и кэшируем, если надоМногие здесь проходили это "объединяем" в эпоху beforesql на прогрессивном dbase. Но потом объемы подросли, требования усложнились и вложенный цикл (нестед-луп) перестал покрывать все потребности. Потом захотелось не тупить, когда данные меняют более одного пользователя, потом прочий acid ... и dbase сдулся.
это ты типа в историю нас посвятил))
проблема твоя и тебе подобных в том, что вы даже не понимаете что есть альтернативные решения,
сотворили себе кумира из оракла и обсираете тех, кому в принципе насрать на оракл
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39670430
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymousМеня приводит в легкое изумление доверчивость бизнеса к облакам.
Отдать свои чувствительные данные под фактический чужой контроль - модель поведения, в чем-то созвучная девизу "слабоумие и отвага".
Полагаю, в данном случае скорее это вопрос веры и маркетинга.
Веры в cloud-провайдеров с просветленными лицами, привнесенной в бизнес мессиями от маркетинга.

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

...впрочем, за любым увлечением очередной новомодностью следует неизбежный откат.
Не думаю, что DBA как профессия неизбежно отомрет в ближайшие годы.
В конце концов, тем же клаудам нужны высокопрофессиональные администраторы, а это достигается планомерной селекцией, для которой необходима широкая "кормовая база" (или "поголовье" - кому как удобнее) администраторов обыкновенных.Точно, такие же мысли. Вот навернется Амазон из-за кассового разрыва, как Bear Sterns какой-нибудь или братья Леманы... И что будет с данными в AWS? Выключат нахрен и всё, а ещё лучше - продадут конкурентам чтобы, стало быть, покрыть убытки.
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39670854
IMNO
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Почитал я 3 страницы. Захотелось вступить в дискуссию.

Вроде бы лет 10 назад пытались убить SQL?
Привело к тому, что в каждой компании "ушедшей" от SQL родился собственный уродец а-ля SQL. Для выборки, агрегирования и сортировки данных. Компании подумали и вернулись обратно к SQL.

Возможно облака ждет та же участь. Большая часть бизнеса уйдет в облака.
Условно какой-нибудь Вася Пупкин будет сотрудником Амазона, но закреплен будет за компанией "Рога и копыта", базы которой будет администрировать. Собственно тот же ДБА, работающий на компанию "Рога и копыта", только вид сбоку.
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39670858
master_yoda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymousОтдать свои чувствительные данные под фактический чужой контроль - модель поведения, в чем-то созвучная девизу "слабоумие и отвага".
Это не сильно отличается от передачи всего и вся в аутсорсинг.

Арендуется у кого-то датацентр или место в нём.
Берётся в лизинг железо.
Нанимается подрядчик следить за системами.
Разработка отдаётся вендору или его партнёру.

Если бизнес согласен на это, то почему бы уже в клауд всё не сгрузить, чтобы минимизировать количество подрядчиков.
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39670886
Фотография Vadim Lejnin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
master_yodaandrey_anonymousОтдать свои чувствительные данные под фактический чужой контроль - модель поведения, в чем-то созвучная девизу "слабоумие и отвага".
Это не сильно отличается от передачи всего и вся в аутсорсинг.

Арендуется у кого-то датацентр или место в нём.
Берётся в лизинг железо.
Нанимается подрядчик следить за системами.
Разработка отдаётся вендору или его партнёру.

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

Тогда уж приложение тоже в лизинг отдать, одно но
Если сломается сетевой ms office - останется часть документов ( большинство в отправленных письмах)
Если сломается безвозвратно база - компанию можно закрывать
...
Рейтинг: 0 / 0
Будущее Oracle DBA v 1.1
    #39670887
Фотография Vadim Lejnin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
master_yoda,

Учитывая лицензионное соглашение на cloud service, провайдер ничем сильно не рискует
...
Рейтинг: 0 / 0
25 сообщений из 125, страница 3 из 5
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Будущее Oracle DBA v 1.1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]