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

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

Но зачем другой сервер? Можно сделать отдельную базу с процедурами, и синонимы на боевые таблицы.

TaPaKAlex1975,

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

TaPaKalexeyvgпропущено...
Выглядит как стандартное решение для ответственных проектов, с большим количеством пользователей.
После тестирования на девелоперском окружении тестируется на стабильной тестовой системе, потом на версию переводится часть пользователей, и только потом уже все остальные.
Тестовые системы не абсолютно адекватны боевым, вон, даже производители машин делают отзывы, а уж в софтостроении бета-версии вообще стандартная практика.
всё звучит не плохо до того момента, что они всё это делают на одних и тех же объектах, что значить как минимум
1. Таблицы они никогда не меняют
2. Соотвественно триггеры/представления
А что они тогда делают? Отчёты?
Есть вариант что накатывают объекты сразу на прод, остальное на препрод, но тут ещё больше удивления, ну и так далееТак ТС пишет - "только для процедур".

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

Собственно, модель данных ведь намного стабильнее кода, так что в принципе это работающая, годная стратегия.
Дедушкану, собственно это я и написал Дедушкато заведите этих бета-тестеров на копию системыНужно же на реальных данных тестировать. Иначе это не называют "бета-тестированием".
Как могут часть пользователей работать в системе, вместе с остальными пользователями, но не на реальных данных? 10 кассиров из ста работают со своей базой??? Бета тестеры - это обычные работающие с продуктом люди, но работающие не с текущей стабильной версией, а с кандидатом на неё.

Да, репликациями так можно сделать, но распределённая система сама по себе нетривиальна, слишком сложна, что бы делать её только для тестирования.

Очень лысыйЧто за писание работы тестеров в боевую базу? Мало ли что там кодеры накодят, и, при доступе на прод, этот код там что-то похерит ненароком?Не тестеров, а пользователей.

Вы подготовили версию, она должна утром появиться на компах 10 000 сотрудников.
Но вам стрёмно, 10 000!!! Вас же порвут, а вдруг что то не так? Вы думаете, "а не залить ли эту версию на компы отдела маркетинга, всё равно их никто не слушает, да и их всего сотня? Если что, откатим."

Очень лысыйПосему, возможно, получится держать "маркетологов" в отдельной базе, куда подливать данные из постоянно изменяемых больших таблиц репликацией, а то, что они там нагерерируют, время от времени сливать в основную боевую базу провереным скриптом. А утром пересобирать для них новую базу из свежено бэкапа с основного прода.Я про этот вариант писал, и не только я.
Но это черезмерно сложно для такой задачи. Сделать для тестирования распределённую систему из продакшена и теста - нереально, это будет по стоимости сравнимо с созданием всей системы.
Для очень больших и ответственных систем, которые уже сделаны распределёнными, можно (и обязательно нужно) предусматривать работу разных частей системы в разных версиях, это при той же сложности хотя бы даст дополнительные плюсы, эта адская работа хотя бы не будет сделана только для тестирования.

Очень лысыйНа самом деле, в общем случае реализовать такую схему, как я описал, не так уж трудно и дорого, если база не слишком сложная по структуре и таблиц в ней не сотни. Ибо она не является в полном смысле слова распределённой системой.Не вижу, почему "не является". Совершенно бескомпромиссно-полноценная распределённая система. Разве что одно упрощение - 2 узла, а не произвольное количество.

Представьте, что у вас, например, 1С база, и поставили задачу "держать "маркетологов" в отдельной базе, куда подливать данные из постоянно изменяемых больших таблиц репликацией, а то, что они там нагерерируют, время от времени сливать в основную боевую базу провереным скриптом"

Guest993что насчет дополнительной прослойки по вызову процедур (и в ней проверять юзера и какую процедуру ему вызывать боевую или бета)? но это все места где идет вызов процедур боевых должны переписаться..Зачем такие сложности? Уже подсказали простое и надёжное решение.

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

Может в каких-то не сильно больших системах где десяток транзакций в секунду и можно реализовать.
Но в больших тяжело. Я даже представить боюсь трудозатраты и количество багов которые огребем при реализации такой схемы. А все для того чтобы исключить гипотетическую вероятность того что кто-то через процедуры сможет покосить много не своих данных.Мало того, непонятна идея Очень лысый, как можно таким образом уберечь данные.
Кривая процедура накосячит в данных, и они перенесутся репликацией в рабочую базу.
Результат тот же, но с адской работой и дополнительными ошибками от самой распределённой схемы.