Как спроектировать базу данных?

Question

[Rogerg]

Как спроектировать базу данных. на основе таких данных.
Компания занимается обслуживанием кондиционеров. Есть штат техников, создаем таблицу техников, в самом простом виде это два атрибута id и ФИО. Есть база заказчиков id, имя заказчика, модель кондиционера, серийный номер кондиционера. Таблица работ
id, названия работ. Работы выбираются из списка ремонт, диагностика, профилактика, запуск.
После визита техника он должен оставить отчет (или комментарии) по результатам работ,
Вот здесь не понятно как сделать основную таблицу, что бы можно было вытащить заказчика, техника и его комментарии. Или все комментарии к определенному кондиционеру.Любой техник может посещать любого заказчика. И соответственно как мне кажется связь между кондиционером и комментарием это один ко многим.

Answer 1

[Андрей Скоржинский]

Можно начать со стандартного каркаса

Comments

[Rogerg]

Спасибо , щас пытаюсь создать БД основываясь на этом каркасе, и у меня в связи с этим появились вопросы. Таблица Orders это промежуточная таблица, которая Client и Order связью многие ко многим? И как называется связь между Order и Condition, с кружочком? Все остальные это обозначение один ко многим, так?

[Андрей Скоржинский]

Rogerg,

Таблица Orders это промежуточная таблица, которая Client и Order связью многие ко многим?

Можно сказать и так, но предпочитаю читать схему так: "Список заказов (счет) Orders заказал клиент Client. Список заказов (Orders) содержит заказ (Order) на обслуживание кондиционера (Condition)." и т.п.
Стрелка кружочком обозначает, что в сущности Order может не быть связи с Condition, например в случае если техник пришел, а кондиционера нет :) Все остальные, да один ко многим. Т.е. если сущность есть, то связь должна должна быть.

[Rogerg]

Андрей Скоржинский,
Точно такую же базу у меня создать не получилось в MySQL была ошибка что-то с constraint. В итоге сделал так, и вроде она работает без всяких constraint (надо ли это вообще использовать в моем случае)
Варианта когда техник приходит а кондиционера нет, я сейчас не рассматриваю.
Все связи сделал через внешнии ключи. Такой вариант будет работать? Или я что-то не учел?
Вместо названия таблицы Order я использовал Note
create MyCompany_db;
use Mycompany_db;

create table Technician (
`id` INT(10) not null key auto_increment,
`name` char(100) not null
);

create table Customer (
`id` INT(10) not null key auto_increment,
`name` char(100) not null,
`address` CHAR(200) NOT NULL

);

create table Conditioner (
`id` INT(10) not null key auto_increment,
`brand` char(100) not null,
`model` CHAR(200) NOT NULL,
`power` CHAR(5) NOT NULL,
`serial number` CHAR(100) NOT NULL,
`Customer_id` INT(10),
FOREIGN KEY (Customer_id) REFERENCES Customer(id)
);

create table Job (
`id` INT(10) not null key auto_increment,
`name` char(100) not null
);

create table Note (
`id` INT(10) not null key auto_increment,
`Date` DATETIME(6),
`Note` CHAR(255),
`FSE_id` INT(10),
`Job_id` INT(10),
`UPS_id` INT(10),
FOREIGN KEY (FSE_id) REFERENCES FSE(id),
FOREIGN KEY (Job_id) REFERENCES Job(id),
FOREIGN KEY (UPS_id) REFERENCES UPS(id));

[Андрей Скоржинский]

Если сервер хавает скрипт, то будет. Ключи это хорошо и правильно. Вообще одна из главных задач разработчика БД это обеспечение целостности данных.

Answer 2

[Сергей Доний]

Таблицы:
Техник, заказчик, виды работ, комментарии
Необходимая информация достается джойнами, а-ля, нормальная форма.
Если СУБД перестанет справляться подумаете о денормализации.

Возможно, будет иметь смысл вынести модели Кондиционеров тоже в отдельную таблицу, но скорее всего не стоит. Это вам решать.

>> После визита техника он должен оставить отчет (или комментарии) по результатам работ,
Вот здесь не понятно как сделать основную таблицу, что бы можно было вытащить заказчика, техника и его комментарии.

Я бы спросил, как контролировать, что он оставил коммент после визита. С запросом проще

Select [fields] from jobs
Inner join customers on jobs.customer_id = customers.id
Inner join provider on provider.id = jobs.provider_id
Inner join worker on worker.id = jobs.worker_id where [condition]

Answer 3

[Adamos]

Или все комментарии к определенному кондиционеру

Сначала надо не запутаться в терминологии и определить, что такое "определенный кондиционер" - это конкретная балалайка у конкретного клиента или конкретная модель, по которой вы будете собирать отзывы?
Впрочем, данных у вас будут не миллионы строк, так что достаточно просто соблюдать нормализацию - вытянуть их проблемой не будет.
Если вам так важно обрабатывать именно комментарии, сделайте избыточную таблицу, где в каждой строчке будет писаться вся нужная информация - и заказчик, и техник, и модель, и идентификатор устройства...
Кстати, возможно, стоит разделить комментарии техника - об устройстве и о клиенте ;)

Comments

[Rogerg]

Определенный кондиционер это конкретная модель с определенным серийным номером у заказчика. Отзывы о модели пока собирать не планирую. Коментарии тоже будут относится к кондиционеру. Коментарии о клиенте идея хорошая , но пока меня интересуют коментарии которые будут относится к кондиционеру.