У нас есть сценарий времени разработки БД SQL Server. Мы должны хранить данные о различных организациях в нашей базе данных (например, Клиент, Продавец, Дистрибьютор, ...). Все организации diff имеют одинаковый тип информации (почти) .. как детали адреса и т. Д. ... И они будут ссылаться в других таблицах (то есть, связанных через OrgId, и мы должны искать OrgName во многих местах diff)
Я вижу два варианта:
Мы создаем таблицу для каждой организации, такой как OrgCustomer, OrgDistributor, OrgVendor и т. Д. ... все таблицы будут иметь одинаковую структуру, а некоторые таблицы будут иметь дополнительные специальные поля, как у клиента есть поле HomeAddress (которое другое Организационные таблицы не имеют) .. и наоборот.
Мы создаем общую таблицу 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 и другой оптимизированной стратегии доступа к данным?
- Другая сторона централизованной реализации заключается в том, что единственное изменение должно быть проверено и проверено во ВСЕХ местах. Это не абстрактно.
- Дизайн может показаться немного менее "организованным \ структурированным". из-за тех немногих организаций, для которых нам нужно добавить «специальные» поля (которые не имеют отношения к другим таблицам)
Я также имел в виду вариант № 3 - разделить таблицы Org, но создать общую таблицу OrgAddress для хранения общих полей. Но это ставит меня в середину # 1 и # 2, и это создает еще большую путаницу!
Если честно, я опытный программист, но не настолько опытный администратор баз данных, потому что это не моя основная задача, поэтому, пожалуйста, помогите мне найти правильный компромисс между параметрами, такими как сложность проектирования и производительность.
Заранее спасибо. Не стесняйтесь задавать любые технические вопросы и предложения приветствуются.
Hemant