Я проектирую базу данных (в MS Access 2010, но я думаю, что для этого вопроса это не имеет значения) для хранения информации о котировках и заказах для столярного бизнеса.
Это мой первый крупный проект по работе с базами данных, и, хотя я чувствую, что усвоил концепции нормализации, у меня возникли серьезные проблемы с тем, чтобы понять, как структурировать предложение и часть обработки заданий.
Ключевые моменты:
- Когда клиент делает запрос, создается предложение или несколько предложений.
- Полученные цитаты могут включать вариации одного и того же. Например, одна цена может быть указана для 10 окон, окрашенных в белый цвет, а другая цена может быть указана для тех же окон, окрашенных в зеленый цвет (мы взимаем дополнительную плату за небелые цвета). Также могут быть отдельные цитаты, например. один для окон дома и один для некоторых дверей.
- Это для столярного бизнеса, изготовления на заказ окон, дверей и т. Д. - это означает, что расценки производятся, но они не относятся к таблице «продукты», поскольку все является одноразовым. Человек, составляющий предложение, просто напишет что-то вроде «Двойное окно 1200x1000 - Спальня 1» и цену в отдельном поле, и эта строка будет добавлена к предложению.
- Каждая цитата будет иметь набор деталей, прикрепленных к ней, которые считаются приоритетными деталями для всей цитаты. Имеется около 120 полей, некоторые из которых предназначены для текста, а некоторые — для хранения информации о задании. Это такие вещи, как «Тип рамного стекла» (текст) и «Задание включает раздвижные двери» (логическое значение). Это важно, так как в этих полях записывается именно то, что было процитировано, и наши дизайнеры обратятся к ним позже. Они также лягут в основу документа об утверждении, который мы отправляем заказчику для подписания, прежде чем что-либо производить. Я думаю, что это должно быть настроено таким образом, потому что, как правило, если мы делаем, скажем, 10 окон для расчета, они имеют почти все общие детали, такие как цвет краски и тип стекла. Также будет раздел/поле памятки для специальных примечаний о вещах, которые отклоняются от нашей стандартной спецификации и т. д.
- Котировки могут иметь статус «Активный», «Мертвый» или «В обработке».
- Одно или несколько предложений могут быть объединены в одно «задание», которое будет обрабатываться вместе и производиться за один раз. Например, мы можем указать некоторые окна и некоторые двери по отдельности, клиент решает, что он хочет заказать у нас и то, и другое одновременно, поэтому мы обрабатываем их вместе. Точно так же у клиента может быть несколько «этапов» для одного и того же заказа, например. у них может быть 10 окон от нас в один месяц и 10 окон от нас через 3 месяца, когда будет готова другая часть их дома, даже если они могут быть указаны в то же время.
- Котировки часто необходимо пересматривать, поскольку клиенты меняют свое мнение о том, что они хотят.
- Я также хочу, чтобы каждая «Работа» (которая может состоять из нескольких кавычек) имела набор JobDetails, который представляет собой сводный список для всего заказа.
Вот что у меня сейчас есть: 
Но я действительно не уверен, что делаю это наилучшим образом, поскольку у меня нет опыта в подобных вещах.
Таблица «Работа» также связана с таблицей «Учетные записи», в которой хранятся клиенты и т. д., но я не показывал этого, поскольку это не совсем относится к рассматриваемой проблеме.
Я думаю, что «пересмотренные» кавычки должны фактически создавать новую запись, копируя данные из другой кавычки и изменяя их, чтобы создать журнал аудита, и то же самое с JobDetails - если JobDetails в задании меняются и/или отличается от JobDetails предложения, то это необходимо отметить (поскольку клиенту может потребоваться заплатить больше).
Есть ли у кого-нибудь рекомендации о том, как лучше всего это сделать?
