Можно ли не использовать первичный ключ, когда он мне не нужен

вам нужен первичный ключ. Ты просто еще этого не знаешь.

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

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

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

нет, если вы не можете найти пример: "эта база данных работала бы намного лучше, если бы у table_x не было первичного ключа."

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

да, таблица всегда должна иметь первичный ключ... если только вам не нужно однозначно идентифицировать записи в нем. (Мне нравится делать абсолютные утверждения и сразу же им противоречить)

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

первичный ключ всегда поможет с выполнением запроса. Поэтому, если вам когда-либо нужно запросить "ключ" к "внешнему ключу" или использовать в качестве поиска, то да, craete внешний ключ.

Я не знаю. Я использовал пару таблиц, где есть только одна строка и один столбец. Всегда будет только одна строка и один столбец. Нет никаких отношений внешнего ключа.

зачем мне ставить на это первичный ключ?

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

хорошо...

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

вам может сойти с рук отсутствие поля "ID", если у вас есть таблица N-M, которая объединяет 2 разные таблицы, но вы можете однозначно идентифицировать запись по значениям из обоих столбцов, к которым вы присоединяетесь. (Составной первичный ключ)

наличие таблицы без первичного ключа противоречит первой нормальной форме и ничего не имеет делать в реляционной БД

У вас всегда должен быть первичный ключ, даже если он только на ID. Может быть, NoSQL-это то, что вам нужно (просто спросите)?

Это очень зависит от того, насколько вы можете быть уверены, что вам это не нужно. Если у вас есть хоть малейшее сомнение, добавьте одно - вы поблагодарите себя позже. Индикатор, если данные, которые вы храните, могут быть связаны с другими данными в вашей БД в какой-то момент.

один вариант использования, который я могу придумать, - это таблица регистрации, в которой вы просто сбрасываете одну запись за другой (чтобы правильно обработать их позже). Вероятно, вам не понадобится первичный ключ, если вы храните достаточно данных для отфильтруйте соответствующие сообщения (например, дату). Конечно, сомнительно использовать для этого РСУБД.