powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование. Заказ на основе разных документов.
13 сообщений из 13, страница 1 из 1
Проектирование. Заказ на основе разных документов.
    #39898771
iv_roman_vl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Какие варианты нормализации, если:

Заказ заведен на основании: Письма, Звонка, Смски.
Письма, Звонка, Смски - это все отдельные сущности со своими атрибутами.

Первое что приходит на ум,

Таблица Заказ:
ID | ТипОснования | Основание_ID

И в зависимости от ТипаОснования, обращаемся к той или иной таблице по Основание_ID.


Или есть по лучше варианты?
Спасибо!
...
Рейтинг: 0 / 0
Проектирование. Заказ на основе разных документов.
    #39898777
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iv_roman_vl,

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

Можно сделать три поля, по одному для каждой сущности основания, можно вынести основания в отдельную таблицу и там сделать три поля для оснований источников.

Насчет лучше - серебряной пули нет, смотрите какой вариант лучше именно для вашей задачи.
...
Рейтинг: 0 / 0
Проектирование. Заказ на основе разных документов.
    #39898779
kolobok0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iv_roman_vl,

лучше - хз, а вот как альтернативу рассмотреть три таблицы заказа...если есть предпосылки (скорость/доступ/различный функционал)

как то так
(круглый)
...
Рейтинг: 0 / 0
Проектирование. Заказ на основе разных документов.
    #39898784
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kolobok0,

Чтобы дробить одну сущность на несколько нужны весьма веские основания, тут их не наблюдается.

авторесли есть предпосылки (скорость/доступ/различный функционал)
скорость - зачем для этого дробить сущность?
доступ - построчный тоже реализуем, очень большой вопрос будет ли профит от разделения одной сущности на несколько.
различный функционал - не вижу препятствий в зависимости от типа использовать тот или иной функционал.
...
Рейтинг: 0 / 0
Проектирование. Заказ на основе разных документов.
    #39898793
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iv_roman_vlПисьма, Звонка, Смски - это все отдельные сущности со своими атрибутами.

А вот и нет. Это дериваты одной сущности "обращение" или "основание для заказа".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Проектирование. Заказ на основе разных документов.
    #39898869
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iv_roman_vl
Какие варианты нормализации, если:

Заказ заведен на основании: Письма, Звонка, Смски.
Письма, Звонка, Смски - это все отдельные сущности со своими атрибутами.

Первое что приходит на ум,

Таблица Заказ:
ID | ТипОснования | Основание_ID

И в зависимости от ТипаОснования, обращаемся к той или иной таблице по Основание_ID.

Или есть по лучше варианты?
Спасибо!
Нормальный и самый простой вариант. Во многих системах именно так.
...
Рейтинг: 0 / 0
Проектирование. Заказ на основе разных документов.
    #39898925
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov

iv_roman_vlПисьма, Звонка, Смски - это все отдельные сущности со своими атрибутами.

А вот и нет. Это дериваты одной сущности "обращение" или "основание для заказа".

Более того, сам заказ может быть основанием для следующего заказа.
Поэтому всё в одну таблицу.
...
Рейтинг: 0 / 0
Проектирование. Заказ на основе разных документов.
    #39898941
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iv_roman_vl
Письма, Звонка, Смски - это все отдельные сущности со своими атрибутами.

Нет, это одна сущность - основание заказа. А то, что ты перечислил - частные её случаи.
И в зависимости от ТипаОснования, обращаемся к той или иной таблице по Основание_ID.
И как ты будешь делать join в общем случае? Будет n вариантов одного и того же запроса?
Хотя тут скорее зависит от того, что ты будешь использовать. На ООП модель твоя схема ложится нормально.
...
Рейтинг: 0 / 0
Проектирование. Заказ на основе разных документов.
    #39898961
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iv_roman_vl

Письма, Звонка, Смски - это все отдельные сущности со своими атрибутами.

Я бы объединил всё в одну таблицу. Добавление новой сущности потребует сильной переработки задуманного функционала. На крайний случай можно некую промежуточную таблицу придумать.
...
Рейтинг: 0 / 0
Проектирование. Заказ на основе разных документов.
    #39899056
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iv_roman_vl
Заказ заведен на основании: Письма, Звонка, Смски

А если клиент написал письмо что заказать, потом позвонил что-то добавить, а вдогонку еще прислал СМС-ку про самое главное?
...
Рейтинг: 0 / 0
Проектирование. Заказ на основе разных документов.
    #39900079
Stanislav P
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Cane Cat Fisher
А если клиент написал письмо что заказать, потом позвонил что-то добавить, а вдогонку еще прислал СМС-ку про самое главное?

Основание для заказа - всегда первое обращение. Всё остальное - переписка/уточнение.
Если думать на вскидку, то в форме "Создание заказа" есть раздел "Переписка" и у одной из этих строк есть атрибут "Источник заказа". Либо "Источник заказа" идёт отдельным атрибутом и является корнем "Переписки"
...
Рейтинг: 0 / 0
Проектирование. Заказ на основе разных документов.
    #39900094
Stanislav P
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
iv_roman_vl,

Я-бы сделал так:
Таблица "Заказы" связана с таблицей "Переписка", по коду заказа.
В таблицу "Переписка" вносится всё взаимодействие с клиентом по любому каналу (соц. сеть, мессенджер, телефон, почта, смс).
Основанием создания "Заказа" всегда является первое обращение. Другой заказ не может быть основанием для создания, так как сам заказ это не средство общения.
Вариант, который всплыл в теме - звонит клиент и говорит, что нужно сделать другой заказ, похожий на заказ номер xxx, и вместо кожаных штанов включить дильдо пятого размера. Тут всё просто - звонок есть основание, но данные заказа можно скопировать из заказа ххх.
...
Рейтинг: 0 / 0
Проектирование. Заказ на основе разных документов.
    #39903795
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iv_roman_vl
Заказ заведен на основании: Письма, Звонка, Смски.
Письма, Звонка, Смски - это все отдельные сущности со своими атрибутами.


имхо изначально не правильно, хватило бы одной таблицы с признаком что это было (Письмо, Звонок, Смс, ....)
...
Рейтинг: 0 / 0
13 сообщений из 13, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование. Заказ на основе разных документов.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]