|
Действия ...
|
06.12.2019, 09:54
|
|||
|---|---|---|---|
|
|||
Проектирование. Заказ на основе разных документов. |
|||
|
|
|
06.12.2019, 10:35
|
|||
|---|---|---|---|
|
|||
Проектирование. Заказ на основе разных документов. |
|||
|
|
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
05.12.2019, 17:42
|
|||
|---|---|---|---|
|
|||
Проектирование. Заказ на основе разных документов. |
|||
|
#18+
Какие варианты нормализации, если: Заказ заведен на основании: Письма, Звонка, Смски. Письма, Звонка, Смски - это все отдельные сущности со своими атрибутами. Первое что приходит на ум, Таблица Заказ: ID | ТипОснования | Основание_ID И в зависимости от ТипаОснования, обращаемся к той или иной таблице по Основание_ID. Или есть по лучше варианты? Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.12.2019, 17:55
|
|||
|---|---|---|---|
|
|||
Проектирование. Заказ на основе разных документов. |
|||
|
#18+
iv_roman_vl, Можно и в таком варианте, без внешних ключей и желательно чтобы идентификаторы писем, звонков и смс-ок не имели пересечений, т.е. в этих таблицах не должно быть одинаковых идентификаторов. Можно сделать три поля, по одному для каждой сущности основания, можно вынести основания в отдельную таблицу и там сделать три поля для оснований источников. Насчет лучше - серебряной пули нет, смотрите какой вариант лучше именно для вашей задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.12.2019, 17:57
|
|||
|---|---|---|---|
Проектирование. Заказ на основе разных документов. |
|||
|
#18+
iv_roman_vl, лучше - хз, а вот как альтернативу рассмотреть три таблицы заказа...если есть предпосылки (скорость/доступ/различный функционал) как то так (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.12.2019, 18:04
|
|||
|---|---|---|---|
|
|||
Проектирование. Заказ на основе разных документов. |
|||
|
#18+
kolobok0, Чтобы дробить одну сущность на несколько нужны весьма веские основания, тут их не наблюдается. авторесли есть предпосылки (скорость/доступ/различный функционал) скорость - зачем для этого дробить сущность? доступ - построчный тоже реализуем, очень большой вопрос будет ли профит от разделения одной сущности на несколько. различный функционал - не вижу препятствий в зависимости от типа использовать тот или иной функционал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.12.2019, 18:21
|
|||
|---|---|---|---|
|
|||
Проектирование. Заказ на основе разных документов. |
|||
|
#18+
iv_roman_vlПисьма, Звонка, Смски - это все отдельные сущности со своими атрибутами. А вот и нет. Это дериваты одной сущности "обращение" или "основание для заказа". Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.12.2019, 22:27
|
|||
|---|---|---|---|
Проектирование. Заказ на основе разных документов. |
|||
|
#18+
iv_roman_vl Какие варианты нормализации, если: Заказ заведен на основании: Письма, Звонка, Смски. Письма, Звонка, Смски - это все отдельные сущности со своими атрибутами. Первое что приходит на ум, Таблица Заказ: ID | ТипОснования | Основание_ID И в зависимости от ТипаОснования, обращаемся к той или иной таблице по Основание_ID. Или есть по лучше варианты? Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.12.2019, 08:28
|
|||
|---|---|---|---|
|
|||
Проектирование. Заказ на основе разных документов. |
|||
|
#18+
Dimitry Sibiryakov iv_roman_vlПисьма, Звонка, Смски - это все отдельные сущности со своими атрибутами. А вот и нет. Это дериваты одной сущности "обращение" или "основание для заказа". Более того, сам заказ может быть основанием для следующего заказа. Поэтому всё в одну таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.12.2019, 09:54
|
|||
|---|---|---|---|
|
|||
Проектирование. Заказ на основе разных документов. |
|||
|
#18+
iv_roman_vl Письма, Звонка, Смски - это все отдельные сущности со своими атрибутами. Нет, это одна сущность - основание заказа. А то, что ты перечислил - частные её случаи. И в зависимости от ТипаОснования, обращаемся к той или иной таблице по Основание_ID. И как ты будешь делать join в общем случае? Будет n вариантов одного и того же запроса? Хотя тут скорее зависит от того, что ты будешь использовать. На ООП модель твоя схема ложится нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.12.2019, 10:35
|
|||
|---|---|---|---|
|
|||
Проектирование. Заказ на основе разных документов. |
|||
|
#18+
iv_roman_vl Письма, Звонка, Смски - это все отдельные сущности со своими атрибутами. Я бы объединил всё в одну таблицу. Добавление новой сущности потребует сильной переработки задуманного функционала. На крайний случай можно некую промежуточную таблицу придумать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.12.2019, 13:08
|
|||
|---|---|---|---|
|
|||
Проектирование. Заказ на основе разных документов. |
|||
|
#18+
iv_roman_vl Заказ заведен на основании: Письма, Звонка, Смски А если клиент написал письмо что заказать, потом позвонил что-то добавить, а вдогонку еще прислал СМС-ку про самое главное? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.12.2019, 15:32
|
|||
|---|---|---|---|
|
|||
Проектирование. Заказ на основе разных документов. |
|||
|
#18+
Cane Cat Fisher А если клиент написал письмо что заказать, потом позвонил что-то добавить, а вдогонку еще прислал СМС-ку про самое главное? Основание для заказа - всегда первое обращение. Всё остальное - переписка/уточнение. Если думать на вскидку, то в форме "Создание заказа" есть раздел "Переписка" и у одной из этих строк есть атрибут "Источник заказа". Либо "Источник заказа" идёт отдельным атрибутом и является корнем "Переписки" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.12.2019, 15:41
|
|||
|---|---|---|---|
|
|||
Проектирование. Заказ на основе разных документов. |
|||
|
#18+
iv_roman_vl, Я-бы сделал так: Таблица "Заказы" связана с таблицей "Переписка", по коду заказа. В таблицу "Переписка" вносится всё взаимодействие с клиентом по любому каналу (соц. сеть, мессенджер, телефон, почта, смс). Основанием создания "Заказа" всегда является первое обращение. Другой заказ не может быть основанием для создания, так как сам заказ это не средство общения. Вариант, который всплыл в теме - звонит клиент и говорит, что нужно сделать другой заказ, похожий на заказ номер xxx, и вместо кожаных штанов включить дильдо пятого размера. Тут всё просто - звонок есть основание, но данные заказа можно скопировать из заказа ххх. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.12.2019, 01:42
|
|||
|---|---|---|---|
Проектирование. Заказ на основе разных документов. |
|||
|
#18+
iv_roman_vl Заказ заведен на основании: Письма, Звонка, Смски. Письма, Звонка, Смски - это все отдельные сущности со своими атрибутами. имхо изначально не правильно, хватило бы одной таблицы с признаком что это было (Письмо, Звонок, Смс, ....) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&tablet=1&tid=1539888]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
170ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
| others: | 245ms |
| total: | 514ms |
| 0 / 0 |
