Как лучше и корректнее спроектировать структуру хранения?
От: F0FAN15  
Дата: 10.05.08 10:57
Оценка:
Здравствуйте! Давно и с удовольствием читаю этот форум. Нахожу его в высшей степени полезным. Недавно столкнулся с задачей, которую что-то никак не получается решить. Суть такова: есть фирма занимающаяся продажей земельных участков. Общая схема работы примерно такая – проводятся переговоры с покупателями, оговаривается цена участка, затем совершается сделка. Нужно регистрировать информацию о переговорах с клиентами. Причем нужно записывать следующие данные: состав участников со стороны фирмы (перечень менеджеров), перечень представителей клиента, перечень земельных участков которые обсуждались в ходе встречи, перечень целей переговоров, перечень результатов переговоров и т.п. Например: цель переговоров — презентация земельного участка и обсуждение коммуникаций, соответственно по результатам переговоров будет зарегистрирован факт передачи заказчику схем участка и, например, изменение намерения заказчика (участок был не интересен, а после переговоров клиент собирается выезжать на осмотр участка). И.т.п. Т.е. есть понятие «Переговоры» (соответственно документ «Переговоры»). Соответственно, с течением времени ведутся новые переговоры и регистрируются. И достигнутые ранее результаты переговоров могут меняться. Более того, переговоров как таковых может и не быть. Клиент может просто позвонить и сообщить некую информацию, которая изменяет достигнутые результаты переговоров (например: он таки соглашается с ценой участка, и, дополнительно, изменяется его намерение – переходит в статус «готов приобрести участок»). Казалось бы – все просто. Регистрируем результаты переговоров с помощью документов, данные о достигнутых результатах храним в таблице результатов переговоров, однако все не так легко. Дело в том, что по результатам переговоров могут изменяться не все достигнутые ранее результаты, а лишь некоторые, соответственно те данные, которые не изменяются, менеджер естественно указывать повторно не будет, т.к. он же их уже вводил раньше. И структура таблицы типа: дата переговоров, контрагент, земельный участок, намерения клиента, площадь, интересующая клиента и т.п. (все результаты переговоров) не работает, т.к. получается, что при регистрации новых переговоров изменяются значения не всех столбцов, а только некоторых. Сейчас в голову приходит только два способа решения:
1-ый способ. Все-таки хранить данные в одной таблице и, при регистрации новых переговоров, по тем данным, которые не изменились получать их из предыдущих переговоров (точнее делается отбор по дате, клиенту, земельному участку в таблице результатов переговоров) и подтягивать их в новую запись. Недостатки: а) получается, по сути, дублирование информации, т.е. нормализации в данном случае нет (то, что будут храниться дополнительные копии введенных данных, не смертельно, т.к. дискового пространства очень много, а рост базы предполагается небольшой); б) при чтении предыдущих данных дополнительно придется блокировать еще и их, соответственно будут возникать проблемы при многопользовательской работе (тоже, не критично, т.к. пользователей работающих с базой будет немного).
2-ой способ. Создать несколько таблиц для хранения одного отдельного реквизита, например – таблица для хранения сведений о намерении клиента «дата», «клиент», «земельный участок», «намерение клиента», отдельная таблица для хранения цены клиента «дата», «клиент», «земельный участок», «цена клиента», отдельная таблица для хранения цены предложения «дата», «клиент», «земельный участок», «цена предложения» и т.п. Недостатки: а) очень много таблиц (хотя в данном случае с нормализацией все в порядке), придется хранить копии значений составного ключа (дата, клиент, земельный участок) в каждой таблице, что соответственно увеличивает объем данных.

Вот такая вот картина. Надеюсь, я понятно объяснил. Очень надеюсь на ваши советы. Если что-то непонятно, обязательно отвечу на все вопросы. Заранее спасибо.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.