Можно ли сделать составной уникальный ключ "в обе стороны" (напр. 3 и 15 == 15 и 3)?

Роми, если нужна сумма пары каждого значения с каждым, то агрегат или материализованное представление выглядят вполне логичным решением при большом кол-ве данных. Правда, при таких требоавниях, не вижу особого смысла в составном ключе с проверкой уникальности, достаточно один раз верно написать запрос подготовки агрегата или материализованного представления.
А что за бизнес-задача такая? Если не секрет. Точно ли, ее можно решить только так?

Можно ли сделать составной уникальный ключ "в обе стороны" (напр. 3 и 15 == 15 и 3)?

Я понимаю, конечно, какой вопрос, такой ответ, но все же... Если это нужно сделать 1 раз, то к чему огород из составных ключей, и ссылок на старую таблицу? Если это нужно на постоянной основе, то что это вообще за жесть, откуда и зачем эта денормализация?
Пока выглядит так, что автор пошёл впиливать очередной костыль, вместо того, чтобы исправить проблему.

Builder: нужна ли фабрика, или можно в билдере оставить метод?

А не проще ли, сделать в билдере дефолтные значения и просто не писать эти сеттеры?

Сложно ли подделать IP апдрес при запросе $_SERVER['REMOTE_ADDR']?

ChairfaceChippendale, слишком сложно и малоэффективно. Нужен подконтрольный маршрутизатор, нужен RIP, подменить сможешь только диапазон этой сети, без RIP только для подконтрольного маршрутизатора. Поэтому практически мало шансов с таким столкнуться.

Возможно ли копировать полностью всю ОС Ubuntu через ssh?

Получится, у меня получалось. Но, я бы лучше воспользовался копированием файлов, а не блочных устройств. Медленней, но гораздо надёжней.

Какие существуют решения для синхронизации БД на фронте и бэкенде?

Надим Закиров, разработка ПО подразумевает универсальные продукты, которые если не сейчас, то все равно потенциально могут использоваться многими людьми. Чтото только для себя - это так, поиграться, проверить гипотезу, не более того.

Как объединить 2 записи в одну по признаку?

Для подобных задач используется pivot, реализован он может быть по-разному, нужно смотреть для конкретной версии конкретной СУБД. Но реализация pivot по-моему всегда подразумевает необходимость задать необходимые колонки. Т.к. кол-во сотрудников все-таки вещь не вечно 2, то либо динамический SQL, либо подумать, а действительно ли так нужно? Очень странное решение, быть может вы пытаетесь на стороне СУБД решить задачу, которую надо решать на стороне приложения.

Тупо и костыльно можно сделать так:

select 
    min(employee_id) employee_id_first, 
    max(employee_id) employee_id_second,
    office_id
from t
group by office_id

Но, так делать нельзя, потому что завтра их может быть 3 или 1, ну и т.п.

Как объединить 2 записи в одну по признаку?

Объединить можно с помощью group by. Но нужно определиться, что подразумевается под first и second. По какому признаку вы в employee_id_first поместили 1, а в employee_id_second 2?

Какие существуют решения для синхронизации БД на фронте и бэкенде?

Надим Закиров, то что вы хотите невозможно, все валидации должны быть на беке, т.к. фронту доверять нельзя, поэтому в любом случае придется делать только там. Для бека верно, это ORM, бывают совершенно разные, начиная от ActiveRecord заканчивая Doctrine, и почти как вы хотели, почти все автоматически. Но такая автоматическая работа слабо ориентирована на тонкую настройку, а база штука капризная, поэтому на высоких нагрузках - не вариант.

Блокировка PHP flock создает последовательную очередь?

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

Как передать на бекенд требования к API?

Антон Бреславский, ни проблем, ни негатива. Лишь описание ситуаций, принимать решения вам, нести за них ответственность тоже.
Как опять от согласования перешли к "Но если у меня на картинке (окей, экране интерфейса) список пользователей, я не могу спроектировать к этой области API вместе с DTO (модель, схема данных)?" я не понял.
И если ничего не смущает в фразе: "бизнес логика на беке, сущности в первую очередь создаются там, их взаимодействие тоже, отображение вторично, но можете сделать наоборот", то вам с этим разбираться.
У меня новых аргументов не будет.

Как передать на бекенд требования к API?

Антон Бреславский,

Вся суть вопроса только в этом, не заменить бэк, не отнять у них работу, а оперативно согласовывать API

В 4ый раз, в согласовании ничего плохого нет.

Но если у меня на картинке (окей, экране интерфейса) список пользователей, я не могу спроектировать к этой области API вместе с DTO (модель, схема данных)?

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

Это ваша личная оценка, у меня это был как вопрос
"Получает бек должен хорошо разбираться в дизайне, понимать как работает приложение и т.д. Верно?"
Поэтому оценка, что бекенд не может, ваш вывод.

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

Как передать на бекенд требования к API?

Антон Бреславский,

у меня где-то написано про такую позицию? Если описание DTO на фронтенл для API вызывает такую реакцию, то у бекенд разработчика проблемы с самооценкой наверное.

я вот про этот комментарий на ответ AgentSmith:

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

Что api создаются по картинкам, и если их отдать беку, то что они могут хорошего сделать, если не понимают как работает приложение, т.е. картинки. Только не говорите, что это AgentSmith придумал, что api создаются по картинкам. Вообще, эпичный комментарий, ничем не хуже того, что я про базу писал в ответе.

И какой, нафиг, DTO, если по вашему мировозрению вы его из картинок должны составлять?

Хотя, то что на ходу переобуваетесь, значит все что мы тут пишем не прошло даром, и вы что-то начали понимать, вон уже и DTO вспомнили.

В качестве вывода, в Вашем случае фронт все таки не могут предлагать контракт взаимодействия с беком путем написания его в Swagger со последующим обсуждением и правками с бэком?

Неа, раза 3 уже написал, что я не про это говорю, так как проблема не в этом.

Как передать на бекенд требования к API?

Антон Бреславский, да ничего удобного, просто отметил, на тот случай, если не правильно трактовал фразы, но раз спорите не с ними - значит можете вычеркнуть "скорее всего".
Разработка API связана с проектированием передачи сущностей и контроля их взаимодействия. Так как бизнес-логика находится на беке, то создаются эти сущности в первую очередь на беке, в какие сущности они будут переданы на фронте и как отображены - вопрос вторичный. Поэтому проектирование API без бека - это мягко говоря странно. А то, что кто-то не знает, что такое mvc, это печально, но к делу не относится.
И вы зря так про интерфейсы, "HTTP, сокеты ли даже командная строка" - это не "всего лишь интерфейсы", это разные архитектурные подходы, воплощающие разное взаимодействие, поэтому чаще всего они будут использованы для разной бизнес-логики. Да, есть такой момент, когда при невозможности соединиться по ws используют костыль - sse или long-polling, но это частный случай.
Просто подумайте:
http - клиент-серверные заросы в сторону сервера, подразумевающее обработку разными процессами, как правило независимые.
cli - работа app по параметрам или интерактивное, подразумевающее запросы от сервера.
ws - клиент-серверное взаимодействие в обе стороны.
Т.е. в зависимости от архитектурных требований, будет использоваться разный подход.

Почему заранее нельзя договориться с фронтом как данные будут бегать туда-обратно и начать работу параллельно?

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

Как передать на бекенд требования к API?

Антон Бреславский, звучит неплохо, но на практике это может значить что угодно. От реального согласования API, до требования пришли мне по одному запросу несвязанные сущности, отправь почту еще по одному условию и свари кофе, но можешь как пожелаешь назвать свойства у возвращаемых объектов.

Как передать на бекенд требования к API?

Антон Бреславский, поэтому и пишу "скорее всего" и многие, а не все. Дело не в унижении или оскорблении, если ваше восприятие совпадает, с описанном выше, то следует срочно его пересмотреть, т.к. здесь дело даже не в том, что что-то не знаешь или неправильно видишь, все мы что-то не знаем и где-то ошибаемся, а в том, что координально не правильно воспринимаешь и не знаешь базисных принципов, это катастрофично для проекта. Если выше написанное не про вас, не воспринимайте на свой счет, если что-то зацепило - то стоит задуматься.
Вы правильно здесь пишите, но теперь перенесите это и на бек тоже, именно про это я писал, нисколько не умаляя сложностей фронтенд разработки, я остерегал от поверхностного отношения к беку. Огромный - это нисколько не показатель сложности для запроса в базу. Возможно у вас, действительно, на беке нет ничего сложного, а только запросы к бд, но даже в этом случае, нужно пересмотреть отношение к API, иначе это будет не интерфейс взаимодействия независимых сервисов, а прослойка, которая увеличит зацепленность и многократно усложнит их взаимодействие. Поэтому вопрос не в том, что "фронтенд проектирует API и делает это всегда плохо", а в том, что по вашему описанию, вы сейчас руководствуетесь неправильными принципами подходя к проектированию API, это и есть проблема. И речь не про swagger и yaml, или моки, или что фронт и бек умеют договариваться, тут все верно, но если бы все так и было, то не было бы и вопроса.

Как передать на бекенд требования к API?

Антон Бреславский, двойная работа и узкое место будут тогда, когда вы вместо API нафигачите узкоспециализированные запросы к беку, и при малейших изменениях на фронте или беке придется пределавать много и во многих местах.

Зачем в обычном проекте может понадобиться использование __invoke?

Максим Федоров, ну, может я и ретроградствую, время покажет.

А что за DSL? Арифметические вычисления с алгеброй логики? Вызов одиночных функций с параметрами? Или язык с операторами, функциями, условиями и алгеброй логики?

Golang и PHP, дань моде или необходимость?

Роман Мирр, речь больше не про готовые решения, а про написание бизнес-логики: это работа с типами, это структуризация ООП. В Go придется относительно низкоуровнево работать с данными, что здесь не нужно, и тогда будет потрачено больше времени. А для какой-нибудь задачи чисто технической, скажем поднять ws-сервер и наладить его взаимодействие с очередью, там разницы особой не будет, т.к. Go действительно простой язык.

Зачем в обычном проекте может понадобиться использование __invoke?

Максим Федоров, спасибо большое за пример, теперь понятно о чем речь. Да, здесь уже функциональное, но зачем функциональное маскировать под ООП, сделали бы обычными функциями, было бы очевиднее. При процедурном или ООП подходе все выглядело бы еще проще, не проще только, если нужно переиспользование, но и здесь сохранить последовательность шагов не сильно усложнит код. И это я говорю без учета того, что там еще что наверчено внутри класса pipeline.
ООП не процедурное программирование, от слова совсем. Да, в ООП зачастую не обойтись без отдельных процедурных вещей, впрочем как и в функциональном. Так что это заявление бессмысленно. Но в ООП это используется на нижнем уровне, и вы прекрасно можете использовать ООП по назначению - структурировать код. В функциональном не обойтись без процедурного на самом верхнем уровне, потому как структурировать функционально проблематично.
Впрочем, спорить о ООП, функционально и процедурном бессмысленно. Я это уже подчеркивал выше, нравится вам функциональный - используйте, хоть прям внутри метода объекта, но маскировать функциональное программирование под ООП - это странно. А вытаскивать функциональное на верхний уровень параллельно с ООП - опасный подход. И выглядит это прекрасно только в примитивном примере с арифметическими опреациями над одной переменной и засчет отказа от функциональной записи и последовательного применения функций. Как-только будет чтото сложное - начнется ад, никто не пишет DSL функционально, поэтому фича забавная, но не более того.