Я пишу метод, который позволит вставлять в таблицу ссылок в моей БД, и мне интересно, нужно ли мне сначала проверить, чтобы убедиться, что указанные PK действительно существуют в связанных таблицах. Мне кажется логичным, что я могу просто полагаться на базу данных на 100% для принудительного применения этих ограничений FK для меня, а также для предотвращения дублирования записей в таблице через PK таблицы. На самом деле, кажется, довольно избыточным и пустой тратой ресурсов для меня, чтобы проверить их заранее, если БД все равно проверит их. Кроме того, обратите внимание, что я говорю об основных принципах RDBMS здесь; Я ожидаю, что они будут одинаково соблюдаться, даже если вы перейдете на другой механизм хранения данных.Есть ли веская причина не полагаться на целостность ключа БД в бизнес-логике?
Значит, в этих обстоятельствах есть ли веская причина не полагаться на базу данных полностью, чтобы обеспечить целостность данных для FK и PK? Другими словами:
using (var context = new MyDbContext()) {
try {
context.LinkEntries.Add(new LinkEntry { key1 = x, key2 = y });
return context.SaveChanges() > 0;
}
catch (DbUpdateException) {
// Duplicate, or foreign key violation
return false;
}
}
Я полагаюсь на ограничения базы данных, вот для чего они предназначены. – Matthew
Согласен. Ограничения базы данных - это путь. Вам нужно обработать сообщение об ошибке, которое база данных возвращается на передний план. –
@MichaelHarmon Да, это проблема. Entity Framework на самом деле не делает попыток предоставить общий способ определить, какая у вас ошибка SQL; разные коннекторы имеют пользовательские исключения, поэтому SQL Server имеет 'SqlException', а популярный Postgres имеет' NpgsqlException'. Было бы здорово, если бы Microsoft определила 'SqlException' как общий кросс-СУБД класс, который должен был указать такие вещи, как запись enum, дающая вам тип ошибки' PrimaryKeyViolation' или что-то еще. – Jez