Я занимаюсь разработкой приложения с использованием фреймворка CakePHP и в настоящее время занимаюсь проектированием базы данных. Я хочу убедиться, что я правильно проектирую объекты и их ассоциации, чтобы приложение работало хорошо, правильно организовывалось, расширялось и хорошо масштабировалось. Сначала я подробно опишу приложение, а также предложу модель Object Relationship. Мне нужно некоторое руководство с точки зрения наилучшей практики и соглашения CakePHP. Пожалуйста, прочитайте описание, а затем ответьте на мои вопросы ниже.
Пожалуйста, оставьте комментарий, если вам нужно что-то разъяснить.
Обоснование применения и требования
Приложение будет функционировать как специализированная система CRM. Клиент будет использовать его для отслеживания и управления клиентами, контактами, заданиями, ресурсами, поставщиками и возможностями. В настоящее время клиент имеет большую неорганизованную базу данных и поврежденный код приложения. Им необходимо восстановить базу данных с нуля, используя CakePHP ORM и новое приложение, построенное поверх структуры данных. База данных будет построена в MySQL. Приложение должно поддерживать несколько типов пользователей со списками контроля доступа. Он должен быть спроектирован для эффективного масштабирования, а новые приложения должны будут быть построены поверх объектной модели на более позднем этапе.
Предложенные объекты (суб-маркеры наследуются от объекта выше)
- Компания - любая компания, с которой клиент ведет бизнес
- Клиент - клиент клиента
- Подрядчик - фирма, с которой клиент заключил контракт на работу
- Поставщик - компания, которая поставляет запчасти или услуги клиенту
- Производитель - компания, которая производит детали
Учетная запись - объект, который инкапсулирует отношения между клиентом и его клиентами
Работа - Единица работы, предоставляемая компанией
Задача - оплачиваемый сервис, связанный с конкретной задачей
Часть - элемент, установленный клиентом как часть задания или задачи
InventoryItem - Часть, которая находится в инвентаре
Персона - запись о человеке
- Сотрудник - сотрудник одной из компаний, с которой клиент имеет дело
- Техник - Сервисный техник, нанятый клиентом
- Контакт - контактное лицо для конкретной компании, с которой клиент имеет дело
- Администратор - администратор сайта
Opportunity - потенциальная возможность трудоустройства для любой учетной записи
Предлагаемые отношения
(HO = hasOne, HM = hasMany, BT = принадлежит To, HABTM = hasAndBelongsToMany)
- Компания
- HM: контакт, техник, работник
- HABTM: Администратор
- Производитель наследует от компании
- Продавец наследует от компании
- Подрядчик наследует от компании
- Клиент наследует от компании
- Работа
- BT: счет
- HM: Задание
- HABTM: Деталь, Подрядчик, Техник
- Задача
- БТ: Работа
- HABTM: деталь, подрядчик, техник
- Часть
- InventortyItem
- Наследование сотрудника от лица
- Техник унаследовал от человека
- Контакт наследует от человека
- Администратор наследует от лица
- Возможность
Я приложил все усилия, чтобы проиллюстрировать это на диаграмме UML, хотя я не уверен, правильно ли я понял условные обозначения:
http://twitpic.com/2o5r0a
Мои вопросы и проблемы
- Какие изменения, если таковые имеются, вы бы внесли в эту схему и почему?
- Каков наилучший способ обработки наследования объектов в CakePHP?
- Как лучше всего провести клиента по этой схеме, объяснив, как она отвечает требованиям проекта?
- Представляет ли этот предложенный проект потенциальные проблемы с масштабируемостью?
- Предвидите ли вы этот дизайн, вызывая какие-либо трудности при разработке кода приложения?
- Любые слова мудрости от ветеринаров CakePHP по этому поводу?