Доброго времени суток.
Хотелось бы услышать мнение профессиональных проектировщиков баз данных по следующей задаче:

В перспективе имеются 100-1000 фирм не имеющих отношения к друг другу, может и более.
У каждой из фирмы свои документы, сотрудники и номенклатуры и группы номенклатур.

Цель - вести учет документов для каждой из фирм 10-30 бухгалтерами. То есть, сотрудники каждой фирмы целый день выписывают: счета, накладные, счета фактур, а один независимый бухгалтер обрабатывает документы 10-50 фирм и сдает отчет.

В связи с этим я планирую:
1. Для каждой из фирм создавать отдельную базу данных, а не хранить данные всех фирм в общей базе данных (разделяя фирмы уникальным индексом)
2. Все базы данных каждой отдельной фирмы по структуре идентичны.

Причины по которым я планирую разделить БД:
а. Использование отдельных БД позволит ограничить каждую из фирм в ресурсе дисковой подсистемы.
б. Отдельные учетные записи для фирм позволят разграничить права доступа.
в. Удаление долго не активных баз данных значительно проще чем выковыривать данные отдельное фирмы из одной общей БД.
г. Масштабируемость (при нехватке ресурсов сервера новые фирмы можно будет размещать на следующем сервере)
д. Запросы к мелким БД на мой взгляд более быстрее чем, очередь запросов к одной громадной базе данных.
е. Сбой в одной огромной БД критичнее, чем сбой в одной независимой БД.

Но есть и то, что я пока не знаю как решить:
i. Как синхронно менять структуру этих одинаковых баз? Например если понадобиться добавить какую-нибудь таблицу во все БД разом, ведь структура баз данных всех фирм должна быть идентична.
ii. Можно ли будет использовать общие хранимые процедуры для работы со всеми БД?
iii. Можно ли, и как, сформировать единую view, например по товарам и услугам из всех баз данных 100-1000 фирм? Например это может понадобиться бухгалтеру для поиска данных по всем фирмам разом?

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

Модератор: Тема перенесена из форума "Microsoft SQL Server".

Mike_zaВсякие мелкие таблички-справочки будут дублироваться между базами.
В оперативной памяти будут многократно кешиться одинаковые общие данные и одинаковые планы запросов. Оперативная память будет жраться за зря.

Разделение прав вообще не является проблемой, и легко реализуется.
Для больших таблиц можно смотреть в сторону секционирования, если версия скл позволяет.
Общие хранимки доя разных баз только через динамику и довольно муторно.
Единую вью на 1000 таблиц страшно представить))

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

Разрешение как раз проблема если данные храняться в одной табличке! Создать отдельную учетку в MsSQL и дать разрешения на доступ только конкретной БД на мой взгляд безопастнее, чем давать всем одну учетну!

View согласен, может и страшно представить, но тогда как производить поиск?
Например я хочу "Видить все фирмы продающие капусту" ))) для этого планирую использовать морфологический поиск MsSQL2012


kva6513Lamer666Цель - вести учет документов для каждой из фирм 10-30 бухгалтерами. То есть, сотрудники каждой фирмы целый день выписывают: счета, накладные, счета фактур, а один независимый бухгалтер обрабатывает документы 10-50 фирм и сдает отчет.

Если основная задача - типовой учет и отченость по ПБУ, не проще купить на каждую контору 1С в облаке и сосредоточится на самой задаче , а не на создании инструмента для ее выполнения ?

В том то и дело, что учет не типовой!!! И 1С не дает гибкость, например поиска товаров и услуг по всем фирмама сразу!




Злой Бобр Lamer666

По ходу очередной убийца 1С.
Lamer666Причины по которым я планирую разделить БД:
...
Все, кроме последней, причины бредовые.
Причина разделять базы может быть только одна - отдавать базу клиенту, т.е. физически БД у клиента крутится а не на вашей железке.

Lamer666Но есть и то, что я пока не знаю как решить:
i. Как синхронно менять структуру этих одинаковых баз? Например если понадобиться добавить какую-нибудь таблицу во все БД разом, ведь структура баз данных всех фирм должна быть идентична.
ii. Можно ли будет использовать общие хранимые процедуры для работы со всеми БД?
iii. Можно ли, и как, сформировать единую view, например по товарам и услугам из всех баз данных 100-1000 фирм? Например это может понадобиться бухгалтеру для поиска данных по всем фирмам разом?

i. Ну очевидно что шедулером дергать хранимку, которая будет смотреть версию, скачивать скрипт обновления и запускать.
ii. Да. Разрешаю.
iii. Можно. Но зачем? Вы представляете например выбор по товарам, где у каждой конторки один и тот же товар называется по разному? Про услуги я даже и говорить не хочу - там полный мрак.
Lamer666Возможно есть еще какие то подводные камни, я был бы очень признателен услышать ваше мнение.
Главный камень это явное отсутствие реального опыта и понимания что и как должно быть, и как есть на самом деле.

Соглашусь с мыслью выше - берите 1С, закупайтесь вазелином и пилите.

Бредовость в том что нельзя давать пользователять возможность безграничного роста БД? Ну сядут пару идиотов и запустят скрипт который будет добавлять данные в БД пока она не распухнет до предела дисков, и потом сиди и выковыривай их га..но от реальных данных других пользователей или чего хуже, других фирм. Это по вашему бред?

По поводу поиска я уже сказал выше. Хочу видить все фирмы оказывающие ту или иную услугу.


kva6513Злой Бобрберите 1С, закупайтесь вазелином и пилите.
Ну дык... Самостоятельное "набивание шишек" - оно ить может потребовать не только вазелина... :) В худшем случае может выйти и что-нить вроде такого - прошел год, начать собственно бизнес никак не получается, т.к. "решение" все не готово и не готово, а "подопытные кролики" уже смотрят волками и собираются разбежаться кто куда... Или даже - разогнать опытных кроликов с их затеями...

Никто не говорит о грандиозном решении! 1. Табличка "счета", 2. Табличка "накладные", 3. Табличка "Счета фактур", 4. Номерклатура 5. Контрагенты. ВСЕ!!!! Если вам 5 таблиц не осилить, то для меня это как то не проблема. )

kva6513Lamer666И 1С не дает гибкость, например поиска товаров и услуг по всем фирмама сразу!
Бухучет, пусть и не типовой, в 1С, своими силами - агрегацию в единую БД и поиск по данным номенклатурных справочников, собираемых с 1С ? Не, не пойдет ?

Ничего не имею против 1С, но проект будет иметь дальнейшее развитие и 1С ну никак не ложиться в основу. (((

MasterZivMike_zaMasterZiv, как видно внизу првого поста из вставки модератора, речь вовсе не про mysql

А, сори, попутал форумы видимо...

Но в общем, мои ответы почти все верны остаются, кроме того, что в СУБД нет баз, есть только схемы.
Да, в MSSQL базы -- это отдельные физические единицы хранения данных.

Но и тут лучше лить все данные в одну БД.
Причина проста: выигрыш от расслоения будет где-то на 1000-10000 фирмах и БД, а столько БД MSSQL просто наверняка не позволить создать.

Что ж, спасибо всем за мнения, они очень важны, так как важно изначально выбрать нужный вектор движения.
Если большинство рекомендуют использовать единую БД, то как в таком случае решить следующие задачи:

1. Разграничения прав доступа к базам данных? Например для WEB клиентов можно запускать сессию и при аутентификации назначАть уникальный ID и использовать его в ХП (механизм сессий работает на сервере и не дает пользователю после аутентификации менять ID что бы заглянуть в чужие данные), а как быть для Soft, Android клиентов?
2. Есть задача подключить механизм распределенных баз данных. Например в офисах люди работают с локальным сервером, и раз в час происходит синхронизация распределенных БД с центральной базой данных.
Если база данных отдельная, то в настройке механизма синхронизации не вижу трудностей, а вот если все фирмы в одной БД, то как синхронизировать?

MasterZiv1. Разграничения прав доступа к базам данных? Например для WEB клиентов можно запускать сессию и при аутентификации назначАть уникальный ID и использовать его в ХП (механизм сессий работает на сервере и не дает пользователю после аутентификации менять ID что бы заглянуть в чужие данные), а как быть для Soft, Android клиентов?


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


2. Есть задача подключить механизм распределенных баз данных. Например в офисах люди работают с локальным сервером, и раз в час происходит синхронизация распределенных БД с центральной базой данных.
Если база данных отдельная, то в настройке механизма синхронизации не вижу трудностей, а вот если все фирмы в одной БД, то как синхронизировать?


Так же. ДОбавляя везде идентификатор фирмы.

На счет пользователя, имеете ввиду: дать пользователю права только на исполнение ХП (с функционалом select, incert, update) и добавлять в конце каждой команды TSQL id фирмы к которому привязан пользователь что бы записываемые данные маркировались и считываемые были только этой самой фирмы?


На счет второго не ясен ответ ТАК ЖЕ. У MsSQL есть стандартные механизмы репликации, разве можно реплицировать данные в одну БД с идентификатором? Или вы имеете ввиду по таймеру производит самописную синхронизацию данных?



Mike_zaLamer666,

Если данные вообще не пересекаются, то в чем проблема?
Куча динамики и вперед.
+ Какая-то генерилка одинаковых процедур в разные базы. На основе модельно базы
Для сквозного поиска либо опять таки динамика, либо какая-то агрегация в общую базу для поиска

А что подразумеваете под выражением "куча динамики и вперед"?
"Какая-то агрегация в общую базу" вот как раз меня интересует более детально про эту агрегацию. Что и как? Алгоритм накидать можете?



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