Что является лучшей практикой для работы в неуправляемом шаблоне программирования

У меня есть запросЧто является лучшей практикой для работы в неуправляемом шаблоне программирования

UPDATE dbo.M_Room 
SET 

//do something 
WHERE PK_RoomId= @RoomId AND IsActive=1 AND FK_DepartmentId [email protected]

Пусть теперь PK_RoomId мой Pk из M_Room и autoincremented поля. Итак, в соответствии с этим я мог бы использовать

WHERE PK_RoomId= @RoomId

вместо

WHERE PK_RoomId= @RoomId AND IsActive=1 AND FK_DepartmentId [email protected]

Что все угрозы, я мог бы преодолеть, если я использую второе условие, а не 1-ый. Если у нас нет каких-либо отношений/Ограничения (PK, FK и т. Д.), Физически существует и не может реализоваться из-за неуправляемой структуры базы данных.

Какова будет ваша рекомендация в таком случае. Что нужно сделать для обеспечения согласованности данных.

источник

2010-08-04 Shantanu Gupta

+1. Вопрос действительно, даже если ход действий оказывается не рекомендованным. – MPelletier

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

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

Я не думаю, что это хорошая идея, чтобы изменить WHERE на WHERE PK_RoomId= @RoomId. Первая часть (часть, которую вы хотите сохранить) предназначена для идентификации записи. Вторая часть (AND IsActive=1) используется, чтобы ограничить обновление в зависимости от того, активна ли эта комната или нет. Что касается последней части (AND FK_DepartmentId [email protected]), это может означать, что иногда вы хотите обновить комнату только в том случае, если она принадлежит отделу, который вы указали. Это также может быть полезно.

Почему именно вы хотите изменить запрос?

источник

2010-08-04 09:30:00

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

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

Если вы используете транзакции READ-UNCOMMITTED или вообще не совершаете транзакций, или данные долгое время сидят на чьем-то экране, дополнительные условия могут спасти вас от захороненного обновления, предполагая, что ваш // делает что-то делает что-то в столбце IsActive.

Он также может быть окончательным защитником от просто ошибочного (видя, если комната не активна, а затем забывает воспользоваться этим фактом).

Обязательно проверьте количество обновленных строк в любом случае.

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

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

источник

2010-08-04 09:31:02

Что является лучшей практикой для работы в неуправляемом шаблоне программирования

ответ

Смежные вопросы