При проектировании базы данных возник вопрос: как правильно организовать многоуровневые справочники? и нужны-ли они вообще.
Предположим есть таблица [контакт] и таблица [вид контакта]. Связь между ними один ко многим, т.е у контакта есть поле (вид), связанное с таблицей видов. Однако, здесь необходимо четко продумать иерархию видов. Например:
вх. звонок – семинар
– обучение — заявка
— отзыв
визит — обучение
— презентация
Это вариант первый.
Но вот появляется контакт, котрый сочетает в себе несколько видов. Как быть? Усложнять иерархию видов – нет желания. Можно вынести все виды в один неиерархический список и ввести новую промежуточную таблицу:

          +----+--------------+---------+
          | id | вид_контакта | контакт |
          +----+--------------+---------+
          | 1  | вх. звонок   | первый  |
          +----+--------------+---------+
          | 2  | обучение     | первый  |
          +----+--------------+---------+
          | 3  | вх. звонок   | второй  |
          +----+--------------+---------+
          | 4  | семинар      | второй  |
          +----+--------------+---------+
          | 5  | отзыв        | второй  |
          +----+--------------+---------+ и т.д.

Это вариант второй.
Ну и третий вариант. В таблице [контакт] поле (вид) рассматривать как набор битов – те из них которые включены и определяют тип контакта.

           +------------вх. звонок
           | +----------исх. звонок
           | |          ...
           | |     +----обучение
           | |     |    ...
          +-+-+-+-+-+-+-+   +-+
          |1|0|0|0|1|0|0|...|0|
          +-+-+-+-+-+-+-+   +-+

У воторого и третьего варианта есть недостаток по отношению к первому — появляется возможность занесения в таблицу несовместимых видов (допустим вх. звонок и исх. звонок одновременно). Или отдать это на откуп пользователям?

Буду благодарен за любые мысли, ссылки на книги, сайты.

Здравствуйте, ValeriySP, Вы писали:

VSP>У воторого и третьего варианта есть недостаток по отношению к первому — появляется возможность занесения в таблицу несовместимых видов (допустим вх. звонок и исх. звонок одновременно). Или отдать это на откуп пользователям?
Отдать это на откуп средствам поддержания целостности.

VSP>Буду благодарен за любые мысли, ссылки на книги, сайты.

http://www.rsdn.ru/article/db/Hierarchy.xml

Автор(ы): Михаил Голованов
Дата: 28.01.2002

Здравствуйте, wildwind, Вы писали:
W>Отдать это на откуп средствам поддержания целостности.

W>http://www.rsdn.ru/article/db/Hierarchy.xml

Автор(ы): Михаил Голованов
Дата: 28.01.2002

Спасибо, эту статью читал.

Но проблема немного не в том. У меня получаются одинаковые значения второго уровня при различных значениях первого. Т.е. [вх. звонок]->[семинар] и [визит]->[семинар]. Можно ли этого избежать?

Здравствуйте, ValeriySP, Вы писали:

VSP>Предположим есть таблица [контакт] и таблица [вид контакта]. Связь между ними один ко многим, т.е у контакта есть поле (вид), связанное с таблицей видов. Однако, здесь необходимо четко продумать иерархию видов. Например:

Битовые поля — плохое решение в случае БД. Хотя бы тем, что они плохо индексируются.

В данном случае есть нормальная развязка многие ко многим. То есть, насколько я понимаю, клиент обращается за некоей услугой, и в ходе этой услуги может быть несколько контактов — звонков и так далее. Это стоит делать как многие ко многим — через развязочную таблицу, как Вы нарисовали. Если при этом нужно контролировать совместимость записей — можно повесить соответствующие триггеры, хотя имхо это решается скорее бизнес-правилами — при первоначальном обращении должен как-то фиксироваться тип обращения, и далее интерфейс вряд ли позволит выбрать несовместимый тип очередного звонка.

Здравствуйте, ValeriySP, Вы писали:

VSP>У меня получаются одинаковые значения второго уровня при различных значениях первого. Т.е. [вх. звонок]->[семинар] и [визит]->[семинар]. Можно ли этого избежать?

А может быть это все-таки разные и независимые характеристики контакта, скажем "вид коммуникации" и "тема"; и между ними нет отношения иерархии?