ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура БД
20 сообщений из 20, страница 1 из 1
Структура БД
    #39446904
gammaray
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gammaray
Гость
Здравствуйте!
Есть текстовое описание задания. Но суть даже не в решении задания. Описание самой БД очень примитивное. Описаны только сами таблицы, поля на уровне просто названий. Никак не могу понять возможную структуру такой БД? Где первичные ключи, какие связи и т.д. Вот описание:
авторВ базе данных есть следующие таблицы:
order - заказы
- id
- code

order_status - статусы заказов
- id
- code
- desc

order_status_history - история статусов заказов
- order_id
- status_id
- date
- time

Из того, что сам понимаю точно:
order.id - первичный ключ таблицы
order_status.desc - текстовое описание статуса заказа
order_status_history.date - дата присвоения данного статуса заказа
order_status_history.time - время присвоения данного статуса заказа

Что означают поля order.code, order_status.id, order_status.code, order_status_history.order_id и order_status_history.status_id и главное как организуется связь между таблицами (первичные и внешние ключи) в упор понять не могу. Уже несколько листочков разрисовал с возможными схемами - без толку. Может меня просто клинит и кто-то предложит какой-то очевидный вариант) Заранее признателен за любую помощь
...
Рейтинг: 0 / 0
01.05.2017, 16:45
| Ответить | Цитировать | Написать  
Структура БД
    #39446923
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
gammaray Вот описание:
авторВ базе данных есть следующие таблицы:
order - заказы
- id
- code

order_status - статусы заказов
- id
- code
- desc

order_status_history - история статусов заказов
- order_id
- status_id
- date
- time



имхо все вполне очевидно
gammarayЧто означают поля order.code,

естественный ключ (в отличие от суррогатного ID) таблицы order
gammarayorder_status.id, order_status.code,

то же самое - суррогатный и естественный ключи order_status
gammaray order_status_history.order_id и order_status_history.status_id

внешние ключи на order.id и order_status.id соответственно
...
Рейтинг: 0 / 0
01.05.2017, 18:19
| Ответить | Цитировать | Написать  
Структура БД
    #39446933
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vmag
Участник
gammaray,

Как то все мрачно с описанием...
order.code - это похоже код заказа в системе, скорее всего текстовый, решено не привязываться к id и это правильно, но похоже его сделали ключом, а это уже не очень, и хотя формат кода заказа типа Z-2017-000000525 позволит обеспечить его уникальность в системе, я бы предпочел другую схему - где история живет сама по себе, типа лог и всё тут...
В общем слева схема БД согласно вашему описанию, в истории хранится только дата и время, а статус(desc) и код заказа(code) вытаскиваются из главных таблиц... справа - как бы я делал, тупо лог: реальный код заказа, статус, дата, время....
И еще... как-то не очень имена полей в таблицах делать схожими с возможными созвучными функциями СУБД - ов
...
Рейтинг: 0 / 0
01.05.2017, 18:56
| Ответить | Цитировать | Написать  
Структура БД
    #39446936
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vmag
Участник
мдя... счас смотрю на свой вариант справа... переделал бы...
1. Или убрал order_status_history вообще, а date_ и time_ закинул в order_status, тогда действующий статус заказа это тот у которого старшие date_ и time_
2. Или убрал бы order_status вообще, а desc сделал бы в order и оставил историю...

Но это уже не важно, слева имхо то, что вы просили.... я так думаю...
...
Рейтинг: 0 / 0
01.05.2017, 19:07
| Ответить | Цитировать | Написать  
Структура БД
    #39446950
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
vmagмдя... счас смотрю на свой вариант справа... переделал бы...

Сейчас еще немного посмотрите, подумаете, решите добавить словарь возможных статусов и вернетесь к схеме ТС :)
...
Рейтинг: 0 / 0
01.05.2017, 19:42
| Ответить | Цитировать | Написать  
Структура БД
    #39446959
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vmag
Участник
Кот Матроскинрешите добавить словарь возможных статусов

так вроде этого нет и в схеме ТС (по крайней мере в явном виде)...
и мне не нравится в исходнике связь code-code один к одному, впрочем может её и нет, ибо то что слева нарисовано - чисто моя интерпретация в попытке изобразить более-менее рабочее из не явного описания...
...
Рейтинг: 0 / 0
01.05.2017, 20:54
| Ответить | Цитировать | Написать  
Структура БД
    #39446961
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vmag
Участник
Кот Матроскин,

Прочитал ваш первый пост (я пока таблички рисовал его вообще не видел)... скорее всего вы правы...
с толку сбивает code в order_status... на самом деле он скорее всего никакого отношения к code в order не имеет...
...
Рейтинг: 0 / 0
01.05.2017, 21:06
| Ответить | Цитировать | Написать  
Структура БД
    #39447170
gammaray
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gammaray
Гость
Кот Матроскинестественный ключ (в отличие от суррогатного ID) таблицы order

А естественные ключи (code) в таблицах при этом совпадают? Если да, то это разве не избыточность данных в этом случае? По id понятно таблицы связаны, а тут дублирующаяся инфа в двух разных таблицах, которую еще и "вручную" надо копировать. Вообще тогда странно выглядит таблица order_status и сомнительна ее необходимость: проще поле desc в таблицу order перенести и удалить таблицу order_status.

Кот Матроскинвнешние ключи на order.id и order_status.id соответственно

Опять же дублирование информации - нет? Эти же значения совпадают (order.id и order_status.id). Так зачем тогда хранить одинаковые значения?
...
Рейтинг: 0 / 0
02.05.2017, 11:37
| Ответить | Цитировать | Написать  
Структура БД
    #39447182
gammaray
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gammaray
Гость
vmag, спасибо за Ваши рисунки. Последний вариант интересный (хотя и кривой по мне в плане организации). Но тогда хотя бы там избыточность данных только в плане поля code (если оно конечно совпадает в двух разных таблицах). Непонятен смысл существования отдельной таблицы order_status. По сути связь с order 1 к 1. Так почему бы не объединить в одну таблицу их, просто перенеся поле desc?
...
Рейтинг: 0 / 0
02.05.2017, 11:43
| Ответить | Цитировать | Написать  
Структура БД
    #39447245
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
gammaray,

Поля CODE в этих таблицах совершенно разные. Я бы вообще переименовал их в ORDER_CODE и STATUS_CODE соответственно.

В том CODE, что в таблице ORDER - код заказа, например "ЗКЗ-225/ы". Он у каждого заказа свой, чтобы клиент и исполнитель смогли понять друг друга в диалоге "- Где мой заказ? - Какой заказ?".

В том CODE, что в STATUS - значения "Принят к исполнению", "Требует уточнения", "Исполнен", "Отказано", и что там еще с любым заказом может случиться. В Desc - подробные пояснения к каждой ситуации.

Таблица STATUS относится к HISTORY как один-ко-многим: многие заказы в разное время принимают один статус.
...
Рейтинг: 0 / 0
02.05.2017, 12:36
| Ответить | Цитировать | Написать  
Структура БД
    #39447360
gammaray
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gammaray
Гость
Cane Cat Fisher, да, согласен, Ваш вариант вполне возможен. Но неужели тогда нельзя было в формулировке вопроса эти поля код назвать по разному, чтобы не вводить в заблуждение?... Вопрос риторический)
...
Рейтинг: 0 / 0
02.05.2017, 14:12
| Ответить | Цитировать | Написать  
Структура БД
    #39447375
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
gammarayCane Cat Fisher, да, согласен, Ваш вариант вполне возможен. Но неужели тогда нельзя было в формулировке вопроса эти поля код назвать по разному, чтобы не вводить в заблуждение?... Вопрос риторический)

Скорее религиозный.

Некоторые полагают, что названия полей должны быть уникальны в пределах БД. Тогда не потребуется никаких дополнительных переименований для полей внешних ключей, и при комбинировании полей в запросах (кроме случаев, когда таблица в запросе участвует более одного раза).

Другие считают, что названия полей должны быть минимизированы - грубо говоря, ID, и CODE в каждой таблице, а другие имена должны использоваться по необходимости - внешние ключи должны называться ORDER_ID, STATUS_ID и т.д., а в запросе, если нужны оба CODE - использовать алиасы ORDER_CODE, STATUS_CODE.

Я склоняюсь скорее к первому варианту. Составитель задания, видимо - ко второму.
...
Рейтинг: 0 / 0
02.05.2017, 14:38
| Ответить | Цитировать | Написать  
Структура БД
    #39448103
gammaray
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gammaray
Гость
Всю голову уже изломал над реализацией задания при схеме БД, к которой в итоге пришли (последняя схема от vmag). Задание следующее:
авторНеобходимо написать SQL-запрос, который будет для каждого
заказа выводить текущий статус, а также дату и время, с которого
заказ находится в этом статусе.
Для простоты реализовал все это в Access, заполнил данными и пробовал написать запросы. Вот данные трех таблиц (2 заказа, один завершен, второй находится на 2 стадии статуса, всего 4 статуса заказа) в порядке order, order_status и order_status_history:









Попытался сделать запросы. Получилось два рабочих варианта, решающие подзадачи самой задачи:
Код: sql
1.
2.
SELECT order.id, order_status.desc, order_status_history.odate, order_status_history.otime
FROM [order] INNER JOIN (order_status INNER JOIN order_status_history ON order_status.id = order_status_history.status_id) ON order.id = order_status_history.order_id


Выводит id заказа (из таблицы order), все статусы заказа и времена присвоения этих статусов (а нужно оставить по идее ТОЛЬКО строчку с максимальной датой И максимальным временем одновременно).

Код: sql
1.
SELECT order_status_history.order_id, Max(order_status_history.odate), Max(order_status_history.otime) FROM order_status_history GROUP BY order_status_history.order_id


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

Всю голову изломал, как сделать итоговый верный запрос...
...
Рейтинг: 0 / 0
03.05.2017, 18:12
| Ответить | Цитировать | Написать  
Структура БД
    #39448191
gammaray
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gammaray
Гость
Вот такой монстр в итоге родился...
Код: sql
1.
2.
3.
4.
5.
SELECT order.code, order_status.desc, order_status_history.odate, order_status_history.otime FROM ((order_status_history 
INNER JOIN [order] ON order.id = order_status_history.order_id)
INNER JOIN [order_status] ON order_status.id = order_status_history.status_id)
INNER JOIN (SELECT order_id, Max(odate) as MaxDate, Max(otime) as MaxTime FROM order_status_history GROUP BY order_id) as q1
ON order_status_history.order_id = q1.order_id AND order_status_history.odate = q1.MaxDate AND order_status_history.otime = q1.MaxTime;


Ну хотя бы результат выдает верный:


Но все таки кажется, что можно как-то несколько короче это написать...
...
Рейтинг: 0 / 0
03.05.2017, 20:56
| Ответить | Цитировать | Написать  
Структура БД
    #39448206
gammaray
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gammaray
Гость
Продолжаю мыслить в слух. Приведенный запрос будет работать правильно только в том случае, когда и дата и время последнего изменения статуса для одного и того же заказа будут одновременно максимальны. Например, случае таких пар дата/время 03.05.2017 17:00 и 04.05.2017 11:00 запрос не выдаст искомое 04.05.2017 11:00, а вообще ничего не выдаст. Так что вопрос остается открытым...
...
Рейтинг: 0 / 0
03.05.2017, 21:38
| Ответить | Цитировать | Написать  
Структура БД
    #39448213
gammaray
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gammaray
Гость
Вот так вроде работает
Код: sql
1.
2.
3.
4.
5.
SELECT order.code, order_status.desc, order_status_history.odate, order_status_history.otime FROM ((order_status_history 
INNER JOIN [order] ON order.id = order_status_history.order_id)
INNER JOIN [order_status] ON order_status.id = order_status_history.status_id)
INNER JOIN (SELECT order_id, Max([odate]+[otime]) as MaxFullDate FROM order_status_history GROUP BY order_id) as q1
ON order_status_history.order_id = q1.order_id AND order_status_history.odate+order_status_history.otime = q1.MaxFullDate;



Но все же надеюсь, что кто-то предложит более короткое и красивое решение
...
Рейтинг: 0 / 0
03.05.2017, 21:49
| Ответить | Цитировать | Написать  
Структура БД
    #39448307
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
gammarayВот так вроде работает
Код: sql
1.
2.
3.
4.
5.
SELECT order.code, order_status.desc, order_status_history.odate, order_status_history.otime FROM ((order_status_history 
INNER JOIN [order] ON order.id = order_status_history.order_id)
INNER JOIN [order_status] ON order_status.id = order_status_history.status_id)
INNER JOIN (SELECT order_id, Max([odate]+[otime]) as MaxFullDate FROM order_status_history GROUP BY order_id) as q1
ON order_status_history.order_id = q1.order_id AND order_status_history.odate+order_status_history.otime = q1.MaxFullDate


Но все же надеюсь, что кто-то предложит более короткое и красивое решениеВ чем сакральный смысл разделения даты и времени на 2 части ? Чтобы при поиске Engine, кроме сравнения, приходилось выполнять ещё и вычисление ? Избавьтесь от этого и запрос становится практически элементарным и более понятным для оптимизатора. Разумеется, при наличии правильных индексов.
...
Рейтинг: 0 / 0
04.05.2017, 07:22
| Ответить | Цитировать | Написать  
Структура БД
    #39449538
gammaray
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gammaray
Гость
ChA, сакральный смысл в том, что таково задание. Я уже писал тут не раз, что такая организация структуры хранения мне мягко говоря самому непонятна.
...
Рейтинг: 0 / 0
05.05.2017, 16:37
| Ответить | Цитировать | Написать  
Структура БД
    #39449667
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
gammarayтаково задание. Я уже писал тут не раз, что такая организация структуры хранения мне мягко говоря самому непонятна.Может те кто ставил задачу, просто видел время и дату в разных полях, но это вовсе не повод так же их и хранить. Если кто-то сознательно настаивает на такой реализации, то это повод задуматься, а стоит ли иметь дело с таким постановщиком, так как ни одного разумного повода хранить время и дату отдельно не существует, если они обязательно нужны оба для фиксации момента времени. Практически в любом диалекте SQL существуют функции, позволяющие выделять только дату или только время, вот и применяйте их при вывода, а хранить надо в одном поле. И запросы станут более вменяемыми. Вычисление при поиске - лучший способ создания себе и заказчику проблем, а вот при выводе можно извращаться как угодно. Надо разделять задачи хранения и представления данных.
Впрочем, настаивать не буду, можно ещё и время разделить, скажем, ещё на 4 поля часы, минуты, секунды и миллисекунды, а дату на год, месяц и день. И все хранить в числовом виде. Или символьном.
...
Рейтинг: 0 / 0
05.05.2017, 23:46
| Ответить | Цитировать | Написать  
Структура БД
    #39449935
gammaray
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gammaray
Гость
ChA, да поймите Вы, что это просто задание из теста по поводу вакансии в одну контору. Я им уже итак все рассказал, что про них думаю с такой формулировкой задания. И самый прикол, что по задумке выполнение всего теста занимает 1-2 часа, а тут я на первом вопрос завис тогда часов на 5-6 точно)
...
Рейтинг: 0 / 0
07.05.2017, 16:56
| Ответить | Цитировать | Написать  
20 сообщений из 20, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура БД
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?desktop=1&fid=32&tid=1540181]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 156ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 56ms
get tp. blocked users:
 1ms
others: 11ms
total:  269ms
созд. / загр.: 269ms
x
x
Закрыть


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