У меня есть проект базы данных, в которой хранятся вакансии.
В таблице «Вакансия» имеется несколько фиксированных полей для всех клиентов, таких как «Заголовок», «Описание», «Диапазон зарплаты».
Существует дизайн EAV для «настраиваемых» полей, которые клиенты могут настраивать самостоятельно, например «Имя менеджера», «Рабочие часы». Имена полей хранятся в таблице «ClientText», а данные хранятся в таблице «VacancyClientText» с VacancyId, ClientTextId и Value.
Наконец, существует множество вариантов дизайна EAV для пользовательских тегов / категорий вакансий с такими вещами, как местоположения / офисы, в которых находится вакансия, список необходимых навыков. Он хранится в виде таблицы «ClientCategory», в которой перечислены типы тегов, «Locations, Skills», таблицы «ClientCategoryItem», в которой перечислены допустимые значения для каждой категории, например «Лондон, Париж, Нью-Йорк, Рим», «C #, VB, PHP, Python». Наконец, есть таблица «VacancyClientCategoryItem» с VacancyId и ClientCategoryItemId для каждого из выбранных элементов для вакансии.
Нет ограничений на количество настраиваемых полей или пользовательских категорий, которые может добавить клиент.
Сейчас я разрабатываю новую систему, которая очень похожа на существующую систему, однако у меня есть возможность ограничить количество настраиваемых полей, которые может иметь Клиент, и он создается с нуля, поэтому у меня нет проблем, связанных с устаревшими с.
Для пользовательских полей мое решение простое, у меня есть 5 дополнительных столбцов в таблице вакансий под названием CustomField1-5. Это удаляет один из дизайнов EAV.
Именно с дизайном тегирования / категоризации я борюсь. Если я ограничу клиента наличием 5 категорий / типов тегов. Должен ли я создать 5 таблиц с перечислением возможных значений «CustomCategoryItems1-5», а затем еще 5 таблиц «много-много-много» «VacancyCustomCategoryItem1-5»
Это приведет к тому, что 10 таблиц будут выполнять то же хранилище, что и три таблицы в существующей системе.
Кроме того, если (не дай бог) изменить требования, мне нужно 6 пользовательских категорий, а не 5, тогда это приведет к значительному изменению кода.
Поэтому, может ли кто-нибудь предложить какие-либо шаблоны проектирования БД, которые были бы более подходящими для хранения таких данных. Я рад придерживаться подхода EAV, однако существующая система столкнулась со всеми обычными проблемами производительности и сложными запросами, связанными с таким дизайном.
Любые советы / предложения очень ценятся.
Используемой системой СУБД является SQL Server 2005, однако, 2008 год является опцией, если требуется для какого-либо конкретного шаблона.