Ребят, помощь нужна по структуре БД. У меня есть список сотрудников.

И для каждого сотрудника есть флаг - Уволен он или нет.
И есть таблица, с историей его карьеры в компании. Там я пробиваю, в каких отделах он работает, в какой отдел временно перешел, по которым выборку делаю, и т.д.
Стоит ли туда писать, когда его приняли на работу и когда уволили?
Или, отдельная таблица для этого?

Дата приема и увольнения, а так же флаг уволен/работает вместе с фио это 1 таблица. Вторая - все движения по отделам

Слушай ну реально слишком абстрактный вопрос... Нужно полное ТЗ. Потому что в зависимости от того что подразумевается под историей, историю может тоже придётся разбить на несколько таблиц для нормализации базы данных. Какая должна быть фильтрация, какие данные должны храниться в истории - это всё имеет значение в архитектуре базы данных. Чем детальнее будет составлено ТЗ на начальных этапах тем меньше потом будет головной боли но и естественно нужно пытаться сделать наиболее масштабируемое решение.

В истории будут храниться, в какую дату сотрудник перешёл в какой отдел и все. То есть: user date department Далее в фильтрации, передаю 2 даты, например 2 месяца: 2021-09-01 - 2021-11-30 И мне нужно будет найти всю историю в промежутке этой даты и так же, самый ближайший из старых записей к начальной дате (2021-09-01)

Сейчас меня конечно запинают, но я предлагаю такую структуру: 1. Table: employee: id, contacts_id, user_data .... etc 2. Table (one to many поскольку сотрудник может несколько раз прийти и уйти): employee_working: id, employee_id, come_date, leave_date(nullable). Поскольку сотрудник может несколько раз прийти и уйти, то все эти несколько раз отражены в one-to-many. Также дата ухода может быть null и если одна из дат null начит сотрудник еще работает. Не надо говорить что будет медленная фильтрация, т.к. больше 4-5к сотрудников все равно врядли будет. 3. Table (one to many поскольку сотрудник может несколько раз перейти в разные отделы): employee_working_experience: id, employee_id, department_id, come_date, leave_date(nullable). 4. table: departments: id, department_code, department_description etc Ну это для начала чтоб что то можно было обсуждать.

Благодарю

Читаю и вижу как менеджер при повторном найме работника просто ставит lave_date в null )

Менеджер ничего не может поставить, ставит программа через интерфейс. Это должно быть отражено в логике php.

Что-то практика показывает, что эта логика только создаёт проблемы менеджерам, а профита не несёт от слова совсем

??? Как это? У вас есть интерфейс в котором написано добавить сотрудника вновь прибывшего на работу если этот сотрудник уже существует то логика дописывает новую дату приёма и последнюю дату ставит null... на откуп юзеру вообще ничего никогда не даётся🙅🙅🤷🤷

У меня не софт для кадрового отдела. Мне нужна информация кого можно поставить в наряд и кому выдать зарплату. Точнее не мне, а менеджерам. А истории трудоустройства им нахой не нужна

ну это пока отдела кадров у тебя нет в crm

А мне нужна)

Читайте ТЗ.

😜

Чтобы что? Я поделился тем как я делаю, а не как делать тебе или автору тз. И главный мой поинт надо смотреть на то что надо бизнесу, а не бездумно клепать истории трудоустройства, потому что работник может вернуться

ох больно будет, когда бизнес поставит условие добавить отдел

Что???))) Вы о чем? Не бездумно, А умышленно чтобы у отдела кадров была история прихода и ухода сотрудников. Если вам не нужна то кому-то может быть нужно ТЗ у всех разное.

Чем же больно? отдел добавиться в таблицу отделов. Если сотрудник туда перейдёт то у него добавиться запись прихода и ухода в новый отдел в таблице "working Experience".

это когда у тебя за ранее ты предвидел, и создал базу для внедрения, а когда как Костик флагами навешался - поди добавь отдел со своим бизнесом

Я думал вы про мою схему написали🙂

На эти флаги агрятся 1-3 модуля. Модуль кадров если понадобится то появится как независимый и по событиям из которого можно обновлять флаги. Где тут проблемы мне лично не ясно

ну достань из своего флага дату принятия и уволнения

у тебя crm работает уже 5 лет, а исчислять ты начнешь с сегодня

она-бизнесу-сейчас-не-нужна. Бизнес не хочет чтобы программа требовала даты увольнения от менеджеров. Услышь меня уже. Если и когда понадобится трекать историю в црм она там появится путём импорта данных из бумажной кадровой истории

дело Ваше, сир ))

https://github.com/automagistre/automagistre/blob/master/src/Employee/Entity/Employee.php#L46-L58 5 лет назад я сделал то о чём меня не просили и спустя 5 лет собираюсь выпилить. Давай расскажи мне ещё о важности этих данных)

мешает?

Сейчас всё переделываю и всё ненужное идёт под каток

Фичи просят денег. Всегда. Фича которая не юзается не приносит денег. То есть чистый убыток. 1. Перед тем как пилить фичу выясни нужна ли она (это то чем продукты заниматься должны, верификация предположений) 2. Заппилили и не пользуется - удаляй

убытка также не принося ))

Если кто то денег просит но при этом их не приносит - этот кто то это убытки.

ну в таком случае, ставим к примеру готовый продукт, название которого не произносят вслух, и выпиливаем 70% ))

и как оно просит денег? На диск?

Открой историю файла по ссылке. За 5 лет в него не было внесено никаких изменений по части его функционала. Но коммиты со всякими рефакторингами, обновлениями доктрин там периодически появляются. Это и есть затраты

ты эти затраты делаешь не из-за наличия фичи, а в опреори

Некоторые рефакторинги условно бесплатные, обновление конфига php-cs-fixer'a например. А некоторые требуют ручного вмешательства в каждый файл. Каждая ненужная фича добавляет количество действий

как у тебя фича, которая зависит от чего-то по id но при этом не меняется 5 лет попадает в коммит? Согласна с Сергеем, когда у тебя весь агрегатор зависит от фичи, но это уже вопрос к проектированию

Лишняя когнетивная нагрузка.

+

вообще не парит, если нет зависимости

Больше папочек - это минимум )

Эт ты просто ещё не в проде