Таблица базы данных с нулевым внешним ключом

Можно ли иметь такие нулевые значения?

Это субъективно. Вопрос: можно ли с ним работать? Возможно - да. Но может ли это гарантировать целостность? Нет.

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

Другой подход состоит в том, чтобы всегда устанавливать user_id (НЕ NULL) и позволять client_id быть необязательным. Если client_id равен NULL, вы знаете, что он обновляется пользователем. Если это не NULL, то вы знаете - он обновляется клиентом.

Затем вы можете получить имя с помощью:

select at.*, coalesce(c.name, u.name) as updated_by
from app_audit at
join user_t u        on u.id = at.user_id
left join client_t c on c.id = at.client_id

Но все еще может пойти не так. Вы можете сохранить идентификатор клиента, который не является «владельцем» приложения. То же самое относится и к user_id. Из-за конструкции (журнал аудита -> приложение -> клиент -> пользователь) и client_id, и user_id функционально зависят от app_id. Так что на самом деле все, что вам нужно, это app_id в качестве внешнего ключа и логический флаг, который сообщает вам, обновлен ли он пользователем или клиентом. Затем вы должны получить данные с помощью:

select at.*, coalesce(u.name, c.name) as updated_by
from app_audit at
join app_t a       on a.id = at.app_id
join client_t c    on c.id = a.client_id
left join user_t u on u.id = c.user_id  and a.updatet_by_user = 1

По поводу вашего комментария:

Я не верю в такие вещи, как «лучший подход» или «лучшая практика», когда проблема «достаточно сложна». Тогда возникает вопрос: лучше для чего? Обычно у вас есть несколько целей, таких как четкость, простота, удобство использования, гибкость, надежность. , производительность и, возможно, что-то еще. «Лучший подход» к гибкости может оказаться кошмаром для производительности, и наоборот.

Более широко используется термин "рекомендуемая практика". И нормализация базы данных считается хорошей практикой. Добавление user_id и client_id вводит функциональные зависимости от не ключа-кандидата, что нарушает 3NF.