Дизайн шаблона «Несколько компаний»

Question

Есть ли такое понятие, как шаблон дизайна «Multi Company» для баз данных? На днях профессор сказал, что это относительно простая функция добавления времени разработки и что мы должны применять ее к любому программному обеспечению, которое может использоваться более чем одной компанией в то время или, например, корпорацией (D), который изготовлен из компаний A, B, C.

Он предположил, что в общих чертах это было.

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

Например ...

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

Есть ли более эффективный способ?

Я спрашиваю, потому что это будет не первый раз мы сказали что-то, что является довольно устаревшим, и я был бы признателен за любое понимание современных тенденций дизайна (или где их найти)

Приветствия.

Answer 1

Есть несколько различных соображений здесь:

Технических соображений

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

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

архитектурные соображения

Типа приложения ваша база данных, поддерживающая также взвешивать в соответствующий дизайн. Например, если вы планируете размещать приложение «Программное обеспечение как услуга», которое было тяжелым, вы можете запустить несколько экземпляров для нескольких компаний, чтобы обслуживать такие вещи, как производительность, использование, лицензирование и т. Д. Это один из миллионов примеров архитектурное решение, выходящее за рамки технологии базы данных.

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

Юридические/Лицензия Соображения

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

Резюме

Как вы можете видеть, что есть много (и много больше, чем я перечислил) причины, которые могут привести к архитектурному изменения, которые затем приводит структуры базы данных в той или иной форме. Но, говоря чисто технически, в общем смысле, нет ничего плохого в том, что «Идентификатор компании» распространяется по всем соответствующим таблицам и обеспечивает безопасность вашего приложения или уровня базы данных, чтобы каждая компания получала свои собственные данные.

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