Или может сделать 3ую таблицу где связать между собой authData

и authDataTypes ?

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

Я создал что-то такое, что думаете ? CREATE TABLE `authData` ( `authDataId` int NOT NULL AUTO_INCREMENT, `authDataTypeId` int NOT NULL, `teamId` int NOT NULL, `ownerId` int NOT NULL, `serverName` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL, `description` tinytext CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci, `deleted` tinyint(1) NOT NULL DEFAULT '0', `creationDate` bigint DEFAULT NULL, `updateDate` bigint DEFAULT NULL, PRIMARY KEY (`authDataId`), KEY `authData_teamId_idx` (`teamId`), KEY `authData_ibfk_ownerId` (`ownerId`), CONSTRAINT `authData_ibfk_ownerId` FOREIGN KEY (`ownerId`) REFERENCES `user` (`userId`) ON DELETE CASCADE, CONSTRAINT `authData_ibfk_teamId` FOREIGN KEY (`teamId`) REFERENCES team (`teamId`) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci; CREATE TABLE authDataTypes ( authDataTypeId int NOT NULL AUTO_INCREMENT, authDataId int NOT NULL, type enum('API_KEY', 'BASIC') CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL, userName varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci, password tinytext, apiKey tinytext, PRIMARY KEY (`authDataTypeId`), KEY authDataType_authDataId_idx (`authDataId`), CONSTRAINT authDataType_ibfk_authDataId FOREIGN KEY (`authDataId`) REFERENCES authData (`authDataId`) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

CREATE TABLE `authData` ( `authDataId` int NOT NULL AUTO_INCREMENT, `authDataTypeId` int NOT NULL, CREATE TABLE authDataTypes ( authDataTypeId int NOT NULL AUTO_INCREMENT, authDataId int NOT NULL, почему в обеих таблицах оба айдишника? какая связь между таблицами? 1:1 / 1:N / N:N? По логике, типов должно быть несколько и у каждой записи в authData должен быть тип, но с одним типом будет N записей, так?

связь 1:1

Вот так будет правильнее создать ? CREATE TABLE `authData` ( `authDataId` int NOT NULL AUTO_INCREMENT, `authDataTypeId` int NOT NULL, `teamId` int NOT NULL, `ownerId` int NOT NULL, `serverName` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL, `description` tinytext CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci, `deleted` tinyint(1) NOT NULL DEFAULT '0', `creationDate` bigint DEFAULT NULL, `updateDate` bigint DEFAULT NULL, PRIMARY KEY (`authDataId`), KEY `authData_teamId_idx` (`teamId`), KEY `authData_ibfk_ownerId` (`ownerId`), CONSTRAINT `authData_ibfk_ownerId` FOREIGN KEY (`ownerId`) REFERENCES `user` (`userId`) ON DELETE CASCADE, CONSTRAINT `authData_ibfk_teamId` FOREIGN KEY (`teamId`) REFERENCES team (`teamId`) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci; CREATE TABLE authDataTypes ( authDataTypeId int NOT NULL AUTO_INCREMENT, type enum('API_KEY', 'BASIC') CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL, userName varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci, password tinytext, apiKey tinytext, PRIMARY KEY (`authDataTypeId`), KEY authDataType_authDataId_idx (`authDataId`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

Мне сложно сказать, как будет правильнее, потому что я не знаю всех нюансов, что там за предметная область, что за сущности, как вообще они друг с другом связаны. Почему там вообще 1:1 и почему нельзя это вообще в одну таблицу сложить? Если там отношение 1:0..1, то в какую из них запихнуть foreign key будет зависить от того, в какой таблице может существовать запись, для которой может не быть соответствующей записи во второй таблице. Условно две таблицы Города и Страны. Отношение 1:1. Можно добавить запись в таблицу со странами не добавляя городов. А вот чтобы добавить город, нужно знать в какой он стране. В целом можно и ссылку (foreign key) друг на друга сделать в обеих таблицах, но в таком случае запись в таблицы должна идти в одной транзакции и проверка констрейнтов должна быть отложенной до коммита. Если не ошибаюсь, MySQL не умеет в deferred constraint проверки, так что с ним так не выйдет.

Я сделал так CREATE TABLE `authData` ( `authDataId` int NOT NULL AUTO_INCREMENT, `authDataTypeId` int NOT NULL, `teamId` int NOT NULL, `ownerId` int NOT NULL, `serverName` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL, `description` tinytext CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci, `deleted` tinyint(1) NOT NULL DEFAULT '0', `creationDate` bigint DEFAULT NULL, `updateDate` bigint DEFAULT NULL, PRIMARY KEY (`authDataId`), KEY `authData_teamId_idx` (`teamId`), KEY `authData_ibfk_ownerId` (`ownerId`), KEY `authData_ibfk_authDataTypeId` (`authDataTypeId`), CONSTRAINT `authData_ibfk_ownerId` FOREIGN KEY (`ownerId`) REFERENCES `user` (`userId`) ON DELETE CASCADE, CONSTRAINT `authData_ibfk_teamId` FOREIGN KEY (`teamId`) REFERENCES team (`teamId`) ON DELETE CASCADE, CONSTRAINT authData_ibfk_authDataTypeId FOREIGN KEY (`authDataTypeId`) REFERENCES authDataType (`authDataTypeId`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci; CREATE TABLE authDataType ( authDataTypeId int NOT NULL AUTO_INCREMENT, type enum('API_KEY', 'BASIC') CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL, userName varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci, password tinytext, apiKey tinytext, PRIMARY KEY (`authDataTypeId`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci; То-есть то что вы говорили, в моем случае СТРАНА(authData) имеет форейн кей ГОРОД(authDataType)

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

Я попробую с другой стороны спросить, смотри Можешь мне помочь пожалуйста со следующей проблемой Мне нужно создать несколько метод авторизаций, например: 1) Basic AUTH когда имя пользователя пароль 2) API Key 3) OAuth 4) JWT Bearer 5) AUTH 2.0 и так далее И мой вопрос как мне хранить данные об авторизации у себя в БД, то есть представь ситуацию: 1) У меня приходит запрос на авторизацию Basic AUTH когда мне приходит username и пассворд Я записываю в колонку username наш юзернейм, а в паспорт захеширован пассворд 2) Ситуация номер 2 мне приходит API Key И я записываю апи кей в колонку api key и типа я не знаю сколько этих метод может быть и мне нужно не хардкодить колонки, а как-то решить эту проблему, может например создать колонку authType где я буду записывать BASIC, AUTH_KEY и тд и может к этому свторить колонку hashPassword куда буду хешировать данные не зависимо от того что мне пришло, но сразу вопрос что делать когда приходит username и пасворд, типа что мне делать с юзернеймом, если у меня только две колонки type и hashPassword, то куда записывать username и такого рода ньюансы от разной типы авторизации Надеюсь ты понял какая у меня проблема)

я поня о чем речь еще из первого описания - погугли про table inheritance. Как вариант - тут есть пример не большой https://ruheni.dev/writing/sql-table-inheritance/ но вообще я не разработчик, возможно есть какие-то варианты получше, но в целом выглядит именно как твой вариант. Есть таблица, в которой указано кто приходит, откуда и с каким типом подключения. А потом на каждый тип есть своя таблица, в которой уже нужные колонки для этого типа подключения. Нужно больше типов? - создал еще таблиц для типов...

Пока что, учитывая, что для каждого типа авторизацыи надо писать код и миграцыи — правильными выходят варианты или доп.полей в основную таблицу или доп.таблиц дажэ на каждый тип авторизацыи. То, что вы хотите — это или EAV или запихивание информацыи в композитный тип (напр.json или напр. binary-данные, свои для каждого типа). Но не стоит так делать в реляцыонной базе без веских причин.