вот это хороший повод завести вторую базу данных в бразилии)

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

А они уже там хранятся. Ведь его копию я поставил на его сервер. :)

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

знаем такую Бразилию)

А они уже там хранятся. Ведь его копию я поставил на его сервер. :)

пока у тебя клиентов десяток-два - все будет не так страшно. А когда клиентов больше сотни - то тут начинаются несколько другие приоритеты

знаем такую Бразилию)

это нормальная практика в большинстве стран, так что никаких намеков. Я говорю о Бразилии именно

пока у тебя клиентов десяток-два - все будет не так страшно. А когда клиентов больше сотни - то тут начинаются несколько другие приоритеты

Ну я просто деплой скрипт же прописываю. Добавить ещё один сервер. У него своя БД.

Ну я просто деплой скрипт же прописываю. Добавить ещё один сервер. У него своя БД.

сколько у тебя таких клиентов?

сколько у тебя таких клиентов?

Пока 2 должно стать.

Ну даже если 100

а ну тогда пофигу

))

Ну даже если 100

"это проблемы админов"))

"это проблемы админов"))

Что в моей версии изменится для 100 клиентов? :)

как ты будешь деплои выкатывать для 100 клиентов?

вот напилили фичу

100 инстансов базы, 100 серваков, 100 деплоев каждый раз

Да. Одной командой.

в 100 раз больше париться

100 инстансов базы, 100 серваков, 100 деплоев каждый раз

У каждого свой. :)

да, все можно автоматизировать, но с учеличением количества растут и риски

а там раз, и первый сервак не отзывается

у нас было ~50 серваков

а потом пойдут часовые пояса разные

в 100 раз больше париться

Ну это ж не так уж и страшно. В конце концов у тебя 100 клиентов. :))

и это каждый раз была боль

да, все можно автоматизировать, но с учеличением количества растут и риски

Но я разве не уменьшаю риск утечки данных по вине программиста в таком случае?

Но я разве не уменьшаю риск утечки данных по вине программиста в таком случае?

it depends.

Если утекут то независимо от инфраструктуры данной. :)

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

потому что это ж компутеры - тут всё должно быть автоматизировано

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

все очень зависит от характера того что и как внутри

Но? :)

большая часть нагрузки ложится на админов и суппорт

как правило

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

а еще - на определенном масштабе риски "проебаться при деплое" сильно превышают риски "забыл условие в where добавить"

последнее контролировать проще

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

Если не учитываем миграции вообще, то это тупо деплой всем одного и того же.

но сложнее чем сделать 2-3 копии базы в случае 2-3 клиентов

ну то есть если я буду знать что у меня будет 2-3 клиента + смешные нагрузки - я как и @Gaaarfild не буду заморачиваться.

а если это 100 клиентов или же это 3-4 клиента но нагрузки сильно разные...

Ну представь что данные например бухгалтерские хранятся. Стал бы ты надеятся на where?

Ну представь что данные например бухгалтерские хранятся. Стал бы ты надеятся на where?

почему нет?)

Одна ошибка и все. :)

А она очень вероятна в каком нибудь сложном проекте.

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

А она очень вероятна в каком нибудь сложном проекте.

приемочные тесты

тем более на сложном проекте

Ты забыл написать и тестом покрыть. Ревьюер проглядел так как невыспался. Куэй не заметил так как тестовые данные неполные. И вперёд. :)

А она очень вероятна в каком нибудь сложном проекте.

для этого есть qa, разные энвайрменты, ревью и приемочные тесты

А потом суды и растраты.

Так как ты раскрыл конфиденциальные данные.

Ты забыл написать и тестом покрыть. Ревьюер проглядел так как невыспался. Куэй не заметил так как тестовые данные неполные. И вперёд. :)

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

Которые могли стоить очень дорого.

А потом суды и растраты.

https://www.postgresql.org/docs/9.5/static/ddl-rowsecurity.html

и те же самые последствия с твоим подходом

в любом случае - вся ответственность на людях

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

Это весьма не сферически а то, что часто происходит. Решить эту проблему раз и навсегда просто именно тем способом что я предлагаю.

в любом случае - вся ответственность на людях

Ну вот при деплое как данные одного кастомера с физического сервака в Бразилии попадут в физический сервак в Британии?

что часто происход? совокупность факторов "тесты не написаны - qa втыкает - тестовый энв сделал вид, что всё ок - приёмочное тестирование"

Это весьма не сферически а то, что часто происходит. Решить эту проблему раз и навсегда просто именно тем способом что я предлагаю.

перепутать куда лить данные - это влегкую можно провернуть))

короч

что часто происход? совокупность факторов "тесты не написаны - qa втыкает - тестовый энв сделал вид, что всё ок - приёмочное тестирование"

Да. Человеческий фактор - весьма коварная штука.

резюмирую - просрать полимеры можно всегда

вопрос процессов

если совокупность всех этиф факторов часто повторяется, то надо команду разогнаьт кху ям)

перепутать куда лить данные - это влегкую можно провернуть))

Так данные не льём же. :)

ERROR: S client not available

Так данные не льём же. :)

но ты же льешь)

Так данные не льём же. :)

перепутать где обновлять можно)

короч - лучше учитесь оценке рисков и анализу рековери тайм

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

но ты же льешь)

Что я могу окрыть одному кастомеру, если случайно укажу не то в данных другого кастомера?

тот же итог

Что я могу окрыть одному кастомеру, если случайно укажу не то в данных другого кастомера?

открыть ничего, ты можешь случайно не то ему проапдейтить

Что я могу окрыть одному кастомеру, если случайно укажу не то в данных другого кастомера?

откуда я знаю что ты там льешь

открыть ничего, ты можешь случайно не то ему проапдейтить

Но при этом я не раскрою данных

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

Но при этом я не раскрою данных

при этом ты сделаешь их бесполезными)

откуда я знаю что ты там льешь

Ну перекинуть юзера из одной группы в другую. Чревато только легкорешаемой проблемой.

при этом ты сделаешь их бесполезными)

Это справедливо и для единой базы.

Ну перекинуть юзера из одной группы в другую. Чревато только легкорешаемой проблемой.

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

Это справедливо и для единой базы.

ты можешь на уровне базы разрулить права

короч, давайте закругляться

когда 2-3 клиента вообще насрать

апдейты, если они делаются без резервирования исходных значений - почти всегда необратимы

В общем, вам не нравится мое решение. :))

В общем, вам не нравится мое решение. :))

два чая этому джентльмену))

В общем, вам не нравится мое решение. :))

да пофиг) я так тоже делал и делаю) просто делюсь что мне подобное не нравится)

в любом случае, решать тебе, получать пиздюлей тоже тебе и получать бонусы тоже тебе))

Ну вот выслушав ваши аргументы, я пока виду в моем способе больше преимуществ. :)

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

Верно. :))

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

Вот да.

Может быть и так.

Но тогда можно просто деплои разделить по таймзонам например.

Но тогда можно просто деплои разделить по таймзонам например.

это зачем?

я не об этом а об общей стоимости железа

короч слишком много зависит от специфики проекта и клиента

Это например на плечах клиентов. Каждый оплачивает своё.