powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Архитектура базы для сотен бизнес-аккаунтов
7 сообщений из 7, страница 1 из 1
Архитектура базы для сотен бизнес-аккаунтов
    #35662486
Глобальный вопрос по архитектуре возник при разработке одной бизнес-системы.

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

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

Теоретически я за отдельные базочки, т.к. это проще программить и меньше шансов у хакеров получить доступ к чужим данным (намеренно или ненамеренно в случае нашей ошибки). С другой стороны, тяжелее мейнтейнить и есть опасение, что сотня мелких баз вместо одной огромной будет ЗНАЧИТЕЛЬНО тяжелее для сервера базы по ресурсам - предполагается, что одновременно процентов 30-50 будут сидеть на сайте.
...
Рейтинг: 0 / 0
Архитектура базы для сотен бизнес-аккаунтов
    #35662632
походя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сергей Гоцулякстоит ли делать общую базу с общими табличками и разносить аккаунты по определенному полю, или делать архитектуру, завязанную на отдельные базы для каждого аккаунта?

Только в случае, если эти данные должны будут активно "взаимодействовать"... Т.е. есть потребность, например, получать постоянно картину сводную по всем БД, данные одного "аккаунта" непосредственно влияют на данные другого и т.п...
Сергей ГоцулякТеоретически я за отдельные базочки, т.к. это проще программить и меньше шансов у хакеров получить доступ к чужим данным (намеренно или ненамеренно в случае нашей ошибки).
этот довод самый перевешивающий, если данные дожны быть абсолютно изолированы друг от друга - то без сомнения разные БД.
Сергей Гоцуляк
С другой стороны, тяжелее мейнтейнить и есть опасение, что сотня мелких баз вместо одной огромной будет ЗНАЧИТЕЛЬНО тяжелее для сервера базы по ресурсам - предполагается, что одновременно процентов 30-50 будут сидеть на сайте.
Зато проще "размазать" по серверам в случае нехватки ресурсов. При необходимости прикупить и поднять сервер, аналогичный существующему - намного проще, чем мигрировать на более мощное железо или наворачивать клястер при разрастании единой БД.

В итоге по надежности решение с отдельными БД - лучше. Единую БД использовать только в случае реальной бизнес-потребности изментять данные всех "аккаунтов".
...
Рейтинг: 0 / 0
Архитектура базы для сотен бизнес-аккаунтов
    #35662777
Мы тоже склоняемся к отдельным базам - между собой они взаимодействовать не будут, сводной информации получать не нужно (разве что для себя - отслеживать занятые ресурсы).

Мы задумывались также о хостинге в "облаке" (Cloud) - у кого-то есть опыт? Знаний практических в этой области нет, но теоретически очень вкусно было бы масштабировать решение не путем умножения серверов и размазывания аккаунтов, а просто путем "раздувания" облака.
...
Рейтинг: 0 / 0
Архитектура базы для сотен бизнес-аккаунтов
    #35662788
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей ГоцулякТеоретически я за отдельные базочки, т.к. это проще программить и меньше шансов у хакеров получить доступ к чужим данным (намеренно или ненамеренно в случае нашей ошибки). С другой стороны, тяжелее мейнтейнить и есть опасение, что сотня мелких баз вместо одной огромной будет ЗНАЧИТЕЛЬНО тяжелее для сервера базы по ресурсам - предполагается, что одновременно процентов 30-50 будут сидеть на сайте.Отдельные базочки лучше (если данные между базочками не надо будет собирать потом в одну).

вот еще несколько проблем, которые будет трудно решать в одной базе:
1) Одна организация сказала "ОЙ! У нас тут кто-то накосячил во всех данных - нам надо откатить данные на 1 день назад!!!". Остальных, конечно же, такой откат назад не устраивает.

2) Если организации будут из разных регионов, то вы сможете арендовать ссервер у местного провайдера и скорость доступа будет для них выше, чем соединяться куда-то далеко.
...
Рейтинг: 0 / 0
Архитектура базы для сотен бизнес-аккаунтов
    #35669861
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Сергей ГоцулякМы тоже склоняемся к отдельным базам - между собой они взаимодействовать не будут, сводной информации получать не нужно (разве что для себя - отслеживать занятые ресурсы).
В данной ситуации единственый минус - апгрейд баз
...
Рейтинг: 0 / 0
Архитектура базы для сотен бизнес-аккаунтов
    #35672800
AlexTheRaven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей ГоцулякГлобальный вопрос по архитектуре возник при разработке одной бизнес-системы.

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

Вопрос такой - стоит ли делать общую базу с общими табличками и разносить аккаунты по определенному полю, или делать архитектуру, завязанную на отдельные базы для каждого аккаунта?Реализовывать безопасность таким способом я бы не стал - DBA замучится поддерживать сотни БД с тысячами пользователей, очень скоро ему это надоест, и все будут ходить с одним логином и паролем. Лучше защиту на уровне строк/фильтров безопасности поднять, если Oracle или MS SQL, а иначе - реализовать то же самое при помощи view (например, так ) или на "сервере приложений" сделать.

Сергей Гоцуляк
Теоретически я за отдельные базочки, т.к. это проще программить
Проще - не всегда лучше, да и не всегда проще. Первое, чего захочет заказчик, будет сводный отчёт, да хотя бы просто список аккаунтов в одной таблице. Что будете делать? Нет, ну можно, конечно, к каждой БД по отдельности подключиться, или cross databse query но это, прямо скажем, не самый прямой способ. А исправлять несоответствие архитектуры требованиям намного труднее, чем изначально всё разрабатывать с их учётом.

Сергей Гоцуляк
и меньше шансов у хакеров получить доступ к чужим данным (намеренно или ненамеренно в случае нашей ошибки)
Хакеры - в основном миф, по крайней мере до тех пор, пока сервер БД не в DMZ и не содержит банковские счета. Главная опасность - пьяный, обиженный (в т.ч. в связи с уходом), подкупленный или просто безалаберный DBA, сис. админ или просто пользователь, имеющий избыточные полномочия.

Сергей Гоцуляк
С другой стороны, тяжелее мейнтейнить
Это да.
Сергей Гоцуляк
и есть опасение, что сотня мелких баз вместо одной огромной будет ЗНАЧИТЕЛЬНО тяжелее для сервера базы по ресурсам - предполагается, что одновременно процентов 30-50 будут сидеть на сайте.Думаю, это как раз не самая большая проблема, хотя действительно присутствует.
...
Рейтинг: 0 / 0
Архитектура базы для сотен бизнес-аккаунтов
    #35673546
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexTheRavenРеализовывать безопасность таким способом я бы не стал - DBA замучится поддерживать сотни БД с тысячами пользователей, очень скоро ему это надоест, и все будут ходить с одним логином и паролем. Лучше защиту на уровне строк/фильтров безопасности поднять, если Oracle или MS SQL, а иначе - реализовать то же самое при помощи view (например, так) или на "сервере приложений" сделать.Нафига городить ROW LEVEL SECURITY, если можно разнести данные по разным схемам (если это Oracle и MS SQL)?

Чтобы все не ходили с одним логин/паролем - надо сделать инструмент генерации логин/пароля для администратора. А пользователю дать возможность смены пароля. При необходимости - с проверкой его сложности.
...
Рейтинг: 0 / 0
7 сообщений из 7, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Архитектура базы для сотен бизнес-аккаунтов
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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