2009-08-24 3 views
2

У меня есть две таблицы, A и B и простая таблица X, которая поддерживает отношения между ними. X содержит AID и BID в качестве основного ключа.Должен ли я игнорировать исключение из вставки базы данных?

Я использую Linq к Sql, чтобы вставить отношения как:

public void InsertRelationship(int y, int z) { 
    DataContext.X.InsertOnSubmit(new x { AID = y; BID = z }); 
} 

Проблема заключается в том, что два вызова InsertRelationship() может быть использована в экстремальных условиях, так исключение будет выброшено из-за дубликат записи. Это не имеет значения для меня, поскольку я знаю, что отношения существуют, поэтому я игнорирую исключение.

Можно ли игнорировать исключение в этом случае или это все еще плохая практика? Должен ли я проверить, что отношения еще не существуют до вставки? Как это повлияет на производительность?

Update

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

ответ

2

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

Лучшим решением было бы создать ваше приложение, чтобы вставить в него не было, лучше всего было бы проверить их существование перед выполнением вставки.

Если производительность критически важна, вставка обмана не может быть устранена, соотношение между вставкой обмоток и рабочей вставкой очень мало, и вы можете сказать, что поднятое исключение связано только с дублирующейся проблемой, вам может быть лучше просто поймать исключение и игнорирование этого. Но это, если с большим количеством условий :-)

2

Как правило, сначала вы должны проверить.

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

Независимо от этого, лучше проверить.

+0

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

+0

Как я уже сказал, несмотря на это, лучше проверить и вернуть им хорошую ошибку. –

0

Если вы уверены, что запись не вставлена ​​только потому, что она уже существует, все должно быть в порядке. Другое мудрый игнорирующий исключение может скрыть что-то еще опасное.

2

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

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

+0

«Бросание исключений дорого», дороже, чем проверка того, что запись не существует каждый раз? Количество дублирующих вызовов, вероятно, составляет менее 2%. –

+0

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

1

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

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