Сценарий времени разработки БД SQL-сервера (распределенный или централизованный)

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

Я вижу два варианта:

Мы создаем таблицу для каждой организации, такой как OrgCustomer, OrgDistributor, OrgVendor и т. Д. ... все таблицы будут иметь схожую структуру, а некоторые таблицы будут иметь дополнительные специальные поля, как у клиента есть поле HomeAddress (чего нет в других таблицах Org ) .. и наоборот.

Мы создаем общую таблицу OrgMaster и храним ВСЕ разностные организации в одном месте. Таблица будет иметь поле OrgType, чтобы различать разные типы Org. И специальные поля будут добавлены в таблицу OrgMaster (значения в таких полях будут иметь только соответствующие записи Org, в других случаях это будет NULL)

Некоторые плюсы и минусы № 1:

ПЛЮСЫ:

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

МИНУСЫ:

Тиражирование дизайна. Если мне нужно увеличить размер поля ZipCode - я должен сделать это во ВСЕХ таблицах.Репликация в реализации манипуляции (то есть мы использовали хранимые процедуры для операций CRUD, поэтому репликация идет n-кратно. 3-4 инертных SP, 2-3 SELECT SP и т. Д.)Все растет в n раз - от ограничений БД \ индексирования до SP - до бизнес-объектов в коде приложения.Изменение (общее) в одном месте должно быть сделано и во всех других местах.Некоторые плюсы и минусы # 2:

ПЛЮСЫ:

N-кратный становится 1-кратным :-)Обслуживание становится проще, потому что мы можем попытаться реализовать единую точку входа для всех операций (т. Е. Один SP для обработки операций CRUD и т. Д.)Мы должны беспокоиться о поддержании единой таблицы. Индексация и другие оптимизации ограничены одной таблицей.

МИНУСЫ:

Это создает узкое место? Можно ли управлять этим путем реализации Views и другой оптимизированной стратегии доступа к данным?Другая сторона централизованной реализации заключается в том, что одно изменение должно быть проверено и проверено во всех местах. Это не абстрактно.Дизайн может показаться немного менее организованным. из-за тех немногих Orgs, для которых нам нужно добавить «специальные» поля (которые не имеют отношения к другим таблицам)

Я также имел в виду вариант № 3 - хранить отдельные таблицы Org, но создавать общую таблицу OrgAddress для хранения общих полей. Но это ставит меня в середину # 1 и # 2, и это создает еще больше путаницы!

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

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

Hemant

Ответы на вопрос(2)

Ваш ответ на вопрос