Проектирование БД на sqlite3, как правильно спроектировать некоторые таблицы?

Question

[Роман Иванов]

Я первый раз проектирую БД (есть таблички в эксельке не использовал софт для проектирования БД - если нужно могу сделать скрин табличек)
Проектирую БД под небольшое производство, при создании таблиц вообще запутался с тем какие связи должны быть.
Таблицы (некоторые поля в таблицах не указал так как они не несут никакой смысловой информации)
таб users:
id
job_title
first_name
last_name

таб Works:
id
work type
work

таб orders:
id
name_order
deadline
client

И так 3 верхние таблицы Заказы, Работы, Пользователи с ними всё ясно - но вот есть еще 3 таблицы с которыми есть проблема. slabs_works, details_woks - сначала об этих двух таблицах. Так как база проектируется для небольшого цеха по производству и обработке камня у нас есть рабочие(users) которым назначают виды работ (содержаться в таблице works) над деталями и слябами - я вижу так 2 эти таблицы

Табл slabs_works:
id
id_order
number_slab
id_works

Табл details_works:
id
id_order
number_detail
id_works

Вопрос №1 нужно ли для каждой таблицы создавать дополнительные таблицы для связи многие ко многим. Потому что по сути над слябом/деталью может выполнятся несколько работ, каждая работа из таблицы works может быть выполнена над каждым слябом/деталью?

Далее еще таблица performance_work в этой таблицы должны содержаться данные о работе над слябом/деталью и при этом присвоен user который выполняет эту работу.
как это вообще можно реализовать по типу?
Табл performance_work:
id
id_slabs_works
id_details_works
id_users
start_date
end_date
work_hour

Вопрос №2 могу ли я например сделать столбец id_slabs_works но он будет пустым например если столбец id_details_works будет заполнен и наоборот? Получается что у нас есть оба этих столбца в таблице но когда мы присваиваем сотруднику выполнить работу над слябом тогда id_slabs_works - будет заполнен, но id_details_works в этот момент будет пустым, можно ли так делать, или лучше отдельно создавать 2 отдельные таблицы и при этом так же здесь получается связь многие ко многим и нужна промежуточная таблица поскольку один рабочий может работать над многими деталями /слябами, и соответственно каждая деталь/сляб может обрабатываться разными рабочими?

Вопрос №3 если мне нужно фиксировать когда сотрудник начал работу над деталью и когда закончил получается что нужно отдельная таблица? Поскольку если мы в таблице performance_work назначаем рабочим выполнение работ, получается что запись после уже внесения в таблицу нужно будет как бы перезаписывать , поскольку начало работы и ее окончание будут внесены позже чем назначение рабочему выполнение работ что как я понимаю не лучшее решение.

Comments

[Василий Банников]

Кажется, вам сначала следует определить, что у вас за данные.

Для этого советую нарисовать ER-диаграмму, где будут описаны все сущности, их атрибуты и отношения между ними.
И, умоляю, если не можете нормально на английском писать - пишите лучше на русском и оперируете теми же терминами, которыми мог бы оперировать эксперт в этой области.
Если рабочий, то и называйте его рабочим/исполнителем, а не юзером.

[Роман Иванов]

В теории - конечно можешь.
Но возникает встречный вопрос.
Если слэб и деталь (кстати, в твоём случае это part, а не details) по факту одни и те же атрибуты, то может их имеет смысл обобщить и засунуть в одну таблицу?

Возможно, но имеем такую ситуацию, архитектор имея чертежи, выбирает камень, далее берет часть камня(сляб) - и назначает работы над слябом, после этого со сляба получаются детали которые опять же присваиваются (назначаются) свои работы. Я подумал что лучше разделить на таблицы отдельно слябы отдельно детали потому как им присваиваются номера, и кроме того имеет таблицу - предпроизводства в которой призначаются кто будет делать замеры, контрольные замеры.
Как бы видели решение таблицы в которой и слябы и детали по типу
id
id_order
number_slab_part
id_works
а далее два столбика Boolean
slab_boolean
part_boolean

которыми мы маркируем это сляб или это деталь вы так видите?

Вполне нормальное решение.
Рабочий начинает смену - в неё записывается время начала и статус "в работе".
Рабочий завершает смену - в неё записывается время завершение и статус "завершена".

Вопрос такого плана, получается записи в таблице performance_work, будет именно первая запись начал во столько, вторая запись закончил во столько то. Не добавление в туже строчку уже значение статусов? А именно статус будет в новой строке?
Я прикреплю всё таки скрин эксель таблицы performance _work что бы было понятно как я вижу, и вам было видно в чём моя ошибка.

Answer 1

[Василий Банников]

Вопрос №1 нужно ли для каждой таблицы создавать дополнительные таблицы для связи многие ко многим. Потому что по сути над слябом/деталью может выполнятся несколько работ, каждая работа из таблицы works может быть выполнена над каждым слябом/деталью?

Если по вашей предметной области такое возможно, то да.
Если нет, то нет.

Вопрос №2 могу ли я например сделать столбец id_slabs_works но он будет пустым например если столбец id_details_works будет заполнен и наоборот?

В теории - конечно можешь.
Но возникает встречный вопрос.
Если слэб и деталь (кстати, в твоём случае это part, а не details) по факту одни и те же атрибуты, то может их имеет смысл обобщить и засунуть в одну таблицу?

Вопрос №3 если мне нужно фиксировать когда сотрудник начал работу над деталью и когда закончил получается что нужно отдельная таблица?

Ну у тебя есть некоторый заказ и N смен, во время которых у тебя этот заказ выполняется. Раз нужно эти смены фиксировать - значит нужна таблица для них.

Поскольку если мы в таблице performance_work назначаем рабочим выполнение работ, получается что запись после уже внесения в таблицу нужно будет как бы перезаписывать , поскольку начало работы и ее окончание будут внесены позже чем назначение рабочему выполнение работ что как я понимаю не лучшее решение.

Вполне нормальное решение.
Рабочий начинает смену - в неё записывается время начала и статус "в работе".
Рабочий завершает смену - в неё записывается время завершение и статус "завершена".

Не думаю, что тебе следует заморачиваться с концепцией event sourcing.