Maxim Volkomorov
Каким образом правильно сформировать структуру БД?

Ну насчет "правильно" - не знаю. Простой вариант - иметь таблицу субъектов, которая заполняется автоматически (триггерами или подобным образом) при модификации абонентов, партнеров, сотрудников и содержит колонки идентификатор и тип.
Ну а в инциденте уже ссылаться на нее.

Maxim Volkomorov
Нельзя ли по подробней описать это предложение?

Создем таблицу:

На таблицы Абонент, Партнер, Сотрудник вешаем триггера, которые при вставке и удалении записей из этих таблиц делают аналогичную операцию с таблицей faces.
Заботимся о том, чтобы идентификаторы в таблицах Абонент, Партнер, Сотрудник не совпадали (то есть берем их оз одной последовательности, или выделяем разные диапазоны).
Поcле этого в таблице Инцидент прописываем ссылки на таблицу субъекты.
При этом обеспечивается ссылочная целостность.
Ну а в интерфейсе для выбора инициатора (или ответственного) придется делать что-то специфическое.
При желании можно таблицу Субъектов расширить (добавить в нее имя и другие общие реквизиты). Убирать при этом имя из основных таблиц не нужно - в данном случае дублирование данных не вредно. Но надо позаботится об актуализации этого поля триггерами. В этом случае выбор инициатора в интерфейсе можно будет упростить.

ShtockПравда данный подход не обеспечивает один из базовых принципов разработки современных систем-любая внешняя сторона,каким либо образом взаимодействующая с бизнесом должна быть зарегистрирована единажды и не повторяться

Принцип этот полностью поддерживаю (можно легко предложить и реализацию для данного случая), но к большому сожалению, в реальной жизни выдержать этот принцип не удается. Несмотря на все усилия программистов одно и то же лицо оказывается зарегистрированным дважды, трижды и т.д. (вот прямо сейчас пытаюсь понять, как же мне объединить все записи об одних и тех же лицах, если некоторые из них заведены аж по сорок раз). Честно говоря, мне бы никогда в голову не пришли те способы искарежить наименование, которые используют пользователи. Ну как можно одно и то же название организации (из двух слов) написать восемнадцатью разными способами? :)

AlexTheRaven
Просто в БД должен быть всего лишь один оператор, которому разрешено заводить новых субъектов (если субъектов много - делить между операторами по территориальному или ещё какому-нибудь принципу).

Ну это вариант только для автоматизации домашнего бизнеса.
Например, возмем банк - пришел человек в отделение вклад себе открыть - операционист что должен ждать, когда какой-то "оператор" в головной конторе соизволит физлицо завести?
Или все-таки сам заведет? А завтра этот же человек в другое отделение придет (может быть на другом конце страны) и откроет еще один счет?
А если отделение в offline работает с последующей репликацией?
И для того же "телекоммуникационного бизнеса", который был в заголовке наверняка есть несколько точек продаж услуг абонентам.

AlexTheRaven
Как вариант - заводить нового субъекта должно быть долго и сложно, а искать среди существующих - быстро и просто.

Мысль забавная - специально сделать "сложный" интерфейс заведения субъектов, чтобы никто им не пользовался. Интересно много ли вы программных продуктов продадите со "специально усложненным" интерфейсом? Почему-то большинство производителей наоборот за эргономику борются. Учтите, что в большинстве случаев после неудачного поиска заводить нового субъекта все-равно придется.

AlexTheRaven
Как ещё один вариант (достаточно сложный в реализации) - система должна переспрашивать при вводе нового оператора: "похожий уже существует, действительно создать?", и выдавать список субъектов, отличающихся всяческими мелочами (с точки зрения человека) - знаками препинания, пробельными символами, названиями форм собственности, городом в названии, транслитом.

Это единственный стоящий вариант. Правда сделать достаточно интеллектуальный механизм сравнения строк, да еще достаточно быстрый - непросто. Скажем за какое время вам удастся из базы, содержащей хотя бы сто тысяч юрлиц выбрать все наименование которых отличается не более чем в двух символах?
А что делать с физлицами которых у меня вот 2 миллиона?

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

asudorov
А в чём противоречие? Выделяете операциониста, ответственного за порядок при вводе, в каждом отделении. А в БД запоминаем его логин для каждой заведённой записи.


Вы видимо плохо представляете себе что такое розничный фронт-офис.
Итак клиент хочет открыть счет в банке. Сначала он стоит в очереди к операционисту, который берет у него документы проверяет их, и выясняет что же нужно клиенту. Узнав, что клиент хочет открыть счет его направляют к другому операционисту, который клиентов заводить умеет, потом к третьему, который договора заводит, потом еще к бухгалтеру - тот счета открывает. Ну и наконец к кассиру, который деньги выдает.
Видел я банки которые по такому принципу работают. И после 15 минут ожидания ушел в соседний, где мне все сделали за пять минут. Может быть банку это выгодно?
И кроме того, если в каждом отделении свой "операционист для ввода клиентов", то как же они между собой отсутствие дублирования обеспечивают.

asudorov
Про специальное усложнение - это ваши слова, не мои. Просто поиск должен быть настолько простым, быстрым и надёжным, что заводить нового должно быть долго и сложно по сравнению с использованием существующего. Хотя согласен, слов "по сравнению" я не написал.
Невозможно? См. Google.

Я не могу сказать, что поисковая система Google удобная. Я видел и получше. Но замечу, что в 90% случев (если не чаще) после поиска все равно придется заводить нового. То есть предварительный поиск (каким бы удобным он ни был) это чистое увеличение трудоемкости.

asudorov
Просто беспорядок - это плохо, даже если естественно.
Вопрос не в том плохо или хорошо, а в том какую цену мы готовы заплатить за его устранение. В известных мне случаях эта цена оказывалась выше, чем потери от беспорядка.