Akina

Пример реализации.

-- рабочая таблица
CREATE TABLE orders (
  id INT AUTO_INCREMENT PRIMARY KEY,
  project_id INT,
  project_number INT
  );

-- опорная таблица для генерации номеров в разрезе проектов
CREATE TABLE generate_project_number (
  project_id INT,
  project_number INT AUTO_INCREMENT,
  PRIMARY KEY (project_id, project_number)
  ) ENGINE = MyISAM;

-- триггер-генератор
CREATE TRIGGER generate_project_number
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
  -- вставить хапись в опорную таблицу для генерации номера
  INSERT INTO generate_project_number (project_id) VALUES (NEW.project_id);
  -- вставить сгенерированный номер в рабочую таблицу
  SET NEW.project_number = LAST_INSERT_ID();
  -- почистить опорную таблицу от лишних записей
  DELETE FROM generate_project_number 
  WHERE project_id = NEW.project_id
    AND project_number < NEW.project_number;
END

DEMO fiddle

Любая СУБД имеет достаточно мощную систему контроля целостности и непротиворечивости данных. Эта система работает, используя набор правил контроля, описанных в структуре БД, и жёстко следит за тем, чтобы ни одно из правил не было нарушено.

Внешний ключ - это как раз такое правило. Сформулировано оно так: в данном поле таблицы не может храниться значение, которое не присутствует в той таблице, на которую ссылается внешний ключ (rонечно, в зависимости от конкретного текста ссылки внешнего ключа и самого поля тут возможны варианты - например, в этом поле может храниться не только значение, присутствующее в ссылочной таблице, но и NULL). И, имея такое правило, СУБД ни при каких условиях не позволит его нарушить. Любая попытка вставить запись со значением, которого нет в ссылочной таблице, приведёт к ошибке. Любая попытка изменить существующее значение на такое, которого "там" нет - приведёт к ошибке. То же касается и "второй" стороны, СУБД не позволит изменить значение в ссылочной таблице или удалить его (потому что записи в нашей таблице при этом "потеряют" ссылку) - такая попытка корректировки приведёт к ошибке.

Нужны ещё как минимум две таблицы.

Первая описывает связь типа много-ко-много между компанией и ролью. Ведь в разных компаниях может быть разный набор ролей - где-то есть аудитор, а где-то нет, к примеру...

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

Вместе они задают, какую конкретную роль в конкретной компании имеет конкретный пользователь.

CREATE TABLE schedule ( schedule_id INT PRIMARY KEY,
                        start_time TIME,
                        task_id INT );

В одной записи - одно время и одна задача. Никаких CSV-наборов.
Если у задач есть отдельная таблица - то соответственно FOREIGN KEY в неё.