Где должна обрабатываться функциональность IsChanged?

Question

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

1. Обработка IsChanged в графическом интерфейсе. Для этого требуется постоянство данных между загрузкой страницы и публикацией данных, что потенциально приводит к большим накладным расходам на пропускную способность / доставку страницы. Это не так уж плохо в приложениях с выигрышными формами, но на веб-сайте это может привести к серьезным финансовым последствиям для затрат на пропускную способность.
2. Обработка в DAL. Для этого требуется несколько обращений к базе данных, чтобы проверить, изменились ли какие-либо данные перед их сохранением. Это потенциально означает дополнительный ненужный вызов к базе данных, потенциально вызывающий проблемы с масштабируемостью из-за ненужных запросов к базе данных.
3. Обработка в хранимом процессе Save () - для этого требуется, чтобы хранимый процесс потенциально выполнял дополнительный ненужный вызов таблицы для проверки, но сохранял бы дополнительный вызов из DAL в базу данных. Потенциально это может масштабироваться лучше, чем DAL, но моя интуиция говорит, что это можно сделать лучше.
4. Обработка в триггере - для этого потребуется использование триггера (к которому я эмоционально не отношусь, я стараюсь избегать триггеров, кроме случаев, когда это абсолютно необходимо).
5. Не обрабатывайте функциональность IsChanged вообще - обработка даты «LastUpdated» не только становится сложной, но и ненужное сохранение данных в базе данных кажется плохой практикой для масштабируемости.

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

Архитектура: SQL Server 2005, ASP.NET MVC, IIS7, Высокие требования к масштабируемости для неспецифической глобальной аудитории.

Answer 1

Хорошо, вот еще одно решение - я не продумал все последствия, но оно может сработать, я думаю:

Подумайте о функциональности сравнения GetHashCode ():

Во время загрузки страницы вы вычисляете хеш-код для данных вашей страницы. Вы сохраняете хеш-код в данных страницы или в viewstate / session, если это то, что вы предпочитаете.

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

• Pros
  • Вам не нужно хранить все исходные данные при загрузке страницы, что сокращает накладные расходы на пропускную способность / доставку страницы.
  • Вам не нужно, чтобы ваш DAL делал несколько звонков в базу данных, чтобы определить, что-то изменилось.
  • Запись будет обновлена ​​в базе данных, только если что-то изменилось, и, следовательно, сохранит правильную дату последнего обновления.
• Cons
  • Вам все еще нужно загрузить исходные данные из базы данных в ваш бизнес-объект, которые не были сохранены в «viewstate», что необходимо для сохранения действительной записи в вашей базе данных.
  • Изменение одного поля изменит хеш, но вы не знаете, какое поле, если вы не вызовете исходные данные из базы данных для сравнения. На заметку, возможно, вам не нужно. Если вам нужно обновить какое-либо из полей, отметка времени изменится, и перезапись поля, которое не изменилось для всех интенсивных целей, не даст никакого эффекта.
  • Вы не можете полностью исключить вероятность столкновения, но они будут редкими. Это сводится к приемлемо ли влияние столкновения или нет?
• или / или
  • Если вы храните хеш в сеансе, это экономит полосу пропускания, но увеличивает ресурсы сервера, поэтому у вас есть потенциальная проблема с масштабируемостью в любом случае.
• Unknowns
  • Затраты на обновление одного столбца отличаются от затрат на обновление нескольких / всех столбцов в записи? Я не знаю, что это за производительность.

Answer 2

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

Answer 3

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

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