Правильное проектирование базы данных

@updaite · Регистрация: 14.01.2013

Author24 — интернет-сервис помощи студентам

Здравствуйте, коллеги подскажите.
Стоит задача спроектировать базу данных для отдела продаж.

Есть некий шаблон таблицы вот такого вида.

Таблица сделка.

1) Ид.
2) Ид менеджера.
3) Имя.
4) Телефон.
5) Адрес.

В программе отображаются только три пункта из этой таблицы (Имя, Телефон, Адрес).
Так же, мой заказчик просит дать возможность добавлять/удалять к уже имеющимся пунктам, свои пункты прямо в программе.

Например: Бюджет, Статус, Время.

Правильно ли будет решение, если я просто расширю таблицу в БД?
Вот в такой вид?
1) Ид.
2) Ид менеджера.
3) Имя.
4) Телефон.
5) Адрес.
6) Бюджет.
7) Статус.
8) Время.

Или же, мне нужно отдельную таблицу такого формата.
1) Ид.
2) Ид сделки.
3) Пункт.

И при запуске программы данные дополняются из второй таблицы.

Как мне поступить?

@Meridian21 · 06.09.2016, 09:35

updaite, на мой взгляд логично было бы, для таблицы "сделка" оставить следующее:
- ид
- ид менеджера
- статус сделки
- время
- бюджет
Если сделка может изменять статус в системе (например, "работа начата" -> "согласование" -> "сделка заключена") то надо добавить поле время_изменения_статуса или нечто похожее. Еще надо как-то идентифицировать клиента, причастного к этой сделке, добавить "ид_клиента".
А вот поля: Имя, Телефон, Адрес - это чьи атрибуты? Если это к менеджеру - то это в таблицу "сотрудники", если это клиентские данные - то в таблицу "клиенты", если это данные какого-то объекта продажи, то в таблицу "объекты".
Также, если сделка, например, о продаже чего-либо, то стоит добавить ссылку на объект продажи, например "ид_строения", "ид_авто" и т.д.

@pincet · 06.09.2016, 11:27

Сообщение от Meridian21

Если сделка может изменять статус в системе (например, "работа начата" -> "согласование" -> "сделка заключена") то надо добавить поле время_изменения_статуса или нечто похожее.

ни в коем случае. Это m:n между Сделка и Статус

@Meridian21 · 06.09.2016, 12:43

Согласен, ошибся. Свалилось все в кучу как-то...
Если движение заявки по статусам актуально, то, тогда либо:
вариант 1
- поле data_created - дата начала жизни заявки
- поле last_updated - обновляемое поле, завязанное на текущий статус. Статус поменялся с "В работе" на "Заключена", поле обновило значение. Дефолтное значение берем равное data_created.
вариант 2:
Делаем еще одну таблицу, которая будет хранить движения заявок, и уже в ней добавляем временную метку. В таком случае ничего обновляться не будет, просто временная метка у каждой строки будет разная.

@pincet · 06.09.2016, 13:53

Сообщение от Meridian21

вариант 1
- поле data_created - дата начала жизни заявки
- поле last_updated - обновляемое поле, завязанное на текущий статус. Статус поменялся с "В работе" на "Заключена", поле обновило значение. Дефолтное значение берем равное data_created.

Ужос.
только вариант 2, ибо это физическое представление граничной сущности

@Meridian21 · 06.09.2016, 16:41

pincet, мне тоже не слишком нравится такой вариант, но вижу его на практике в разных системах довольно часто. Вполне возможно, что данное поле работает исключительно для "логирования" движения заявки, т.е. сама временная метка не критична (например, система обрабатывает заявки автоматом и последний апдейт нужен исключительно для понимания сколько времени заявка болталась в системе). Непосредственный результат работы передается дальше в систему (или в смежную) уже в адекватном виде или вообще без timestamp'ов.
Так что такой вариант допустим, как мне кажется. В реальных системах ведь не всегда все "по науке".

@pincet · 06.09.2016, 16:51

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

С такими случаями я сталкивался - приходилось триггеры вешать на ведение лога, ибо так (будем поле обновлять и все тут) и думали разрабы.

@Meridian21 · 06.09.2016, 17:07

pincet, согласен. Разбирать и "мотивировать" ответственных при такой реализации сложно. Даже при полностью автоматизированном цикле обработки заявки, при каком то косяке (повисла заявка, умерла по TTL и т.д.), без адекватных логов на серверах подсистем, понять что с ней не так, не просто бывает. А логи редко когда бывают читаемы и понятны.
Когда я первый раз увидел такую реализацию, был сильно удивлен, но почему-то так делают...

@updaite 15 / 15 / 8 Регистрация: 14.01.2013 Сообщений: 545 Записей в блоге: 2
		1
	Правильное проектирование базы данных 05.09.2016, 17:57. Показов 635. Ответов 7 Метки нет (Все метки) Здравствуйте, коллеги подскажите. Стоит задача спроектировать базу данных для отдела продаж. Есть некий шаблон таблицы вот такого вида. Таблица сделка. 1) Ид. 2) Ид менеджера. 3) Имя. 4) Телефон. 5) Адрес. В программе отображаются только три пункта из этой таблицы (Имя, Телефон, Адрес). Так же, мой заказчик просит дать возможность добавлять/удалять к уже имеющимся пунктам, свои пункты прямо в программе. Например: Бюджет, Статус, Время. Правильно ли будет решение, если я просто расширю таблицу в БД? Вот в такой вид? 1) Ид. 2) Ид менеджера. 3) Имя. 4) Телефон. 5) Адрес. 6) Бюджет. 7) Статус. 8) Время. Или же, мне нужно отдельную таблицу такого формата. 1) Ид. 2) Ид сделки. 3) Пункт. И при запуске программы данные дополняются из второй таблицы. Как мне поступить? 0

@Meridian21 Zero day 267 / 231 / 78 Регистрация: 16.12.2015 Сообщений: 943 Записей в блоге: 4
	06.09.2016, 09:35	2
	updaite, на мой взгляд логично было бы, для таблицы "сделка" оставить следующее: - ид - ид менеджера - статус сделки - время - бюджет Если сделка может изменять статус в системе (например, "работа начата" -> "согласование" -> "сделка заключена") то надо добавить поле время_изменения_статуса или нечто похожее. Еще надо как-то идентифицировать клиента, причастного к этой сделке, добавить "ид_клиента". А вот поля: Имя, Телефон, Адрес - это чьи атрибуты? Если это к менеджеру - то это в таблицу "сотрудники", если это клиентские данные - то в таблицу "клиенты", если это данные какого-то объекта продажи, то в таблицу "объекты". Также, если сделка, например, о продаже чего-либо, то стоит добавить ссылку на объект продажи, например "ид_строения", "ид_авто" и т.д. 1

@pincet 1643 / 1144 / 171 Регистрация: 23.07.2010 Сообщений: 6,793
	06.09.2016, 11:27	3
	Сообщение от Meridian21 Если сделка может изменять статус в системе (например, "работа начата" -> "согласование" -> "сделка заключена") то надо добавить поле время_изменения_статуса или нечто похожее. ни в коем случае. Это m:n между Сделка и Статус 1

@Meridian21 Zero day 267 / 231 / 78 Регистрация: 16.12.2015 Сообщений: 943 Записей в блоге: 4
	06.09.2016, 12:43	4
	Согласен, ошибся. Свалилось все в кучу как-то... Если движение заявки по статусам актуально, то, тогда либо: вариант 1 - поле data_created - дата начала жизни заявки - поле last_updated - обновляемое поле, завязанное на текущий статус. Статус поменялся с "В работе" на "Заключена", поле обновило значение. Дефолтное значение берем равное data_created. вариант 2: Делаем еще одну таблицу, которая будет хранить движения заявок, и уже в ней добавляем временную метку. В таком случае ничего обновляться не будет, просто временная метка у каждой строки будет разная. 1

@pincet 1643 / 1144 / 171 Регистрация: 23.07.2010 Сообщений: 6,793
	06.09.2016, 13:53	5
	Сообщение от Meridian21 вариант 1 - поле data_created - дата начала жизни заявки - поле last_updated - обновляемое поле, завязанное на текущий статус. Статус поменялся с "В работе" на "Заключена", поле обновило значение. Дефолтное значение берем равное data_created. Ужос. только вариант 2, ибо это физическое представление граничной сущности 1

@Meridian21 Zero day 267 / 231 / 78 Регистрация: 16.12.2015 Сообщений: 943 Записей в блоге: 4
	06.09.2016, 16:41	6
	pincet, мне тоже не слишком нравится такой вариант, но вижу его на практике в разных системах довольно часто. Вполне возможно, что данное поле работает исключительно для "логирования" движения заявки, т.е. сама временная метка не критична (например, система обрабатывает заявки автоматом и последний апдейт нужен исключительно для понимания сколько времени заявка болталась в системе). Непосредственный результат работы передается дальше в систему (или в смежную) уже в адекватном виде или вообще без timestamp'ов. Так что такой вариант допустим, как мне кажется. В реальных системах ведь не всегда все "по науке". 1

@pincet 1643 / 1144 / 171 Регистрация: 23.07.2010 Сообщений: 6,793
	06.09.2016, 16:51	7
	Meridian21, есть и тут правда, можно избыточность такую внести. Однако как потом отследить, когда какой этап был завершен, и кого "мотивировать" С такими случаями я сталкивался - приходилось триггеры вешать на ведение лога, ибо так (будем поле обновлять и все тут) и думали разрабы. 1

@Meridian21 Zero day 267 / 231 / 78 Регистрация: 16.12.2015 Сообщений: 943 Записей в блоге: 4
	06.09.2016, 17:07	8
	pincet, согласен. Разбирать и "мотивировать" ответственных при такой реализации сложно. Даже при полностью автоматизированном цикле обработки заявки, при каком то косяке (повисла заявка, умерла по TTL и т.д.), без адекватных логов на серверах подсистем, понять что с ней не так, не просто бывает. А логи редко когда бывают читаемы и понятны. Когда я первый раз увидел такую реализацию, был сильно удивлен, но почему-то так делают... 1

Опции темы