Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Tom, Вы писали:
G>>>Каким образом сразу изменения отправлять? После изменения одного поля? В какой момент? Tom>>Надо поменять данные — меняем сразу. G>Ну и как это будет выглядеть? Поменяли поле — сразу полетел update? G>Боюсь представить как это будет тормозить.
Поменяли строку — полетел update. Для 95% кода это работает прекрастно.
Есть места где нужна групировать обращения к базе что бы улучшить производительность.
Там можно использовать хранимки.
ИМХО Change Tracking изменённых рядов — в 95% случаев не нужен и является преждевременной оптимизацией.
Отслеживание же изменённых полей в одном ряду — может быть полезной фичёй но не жизненно необходимой.
Здравствуйте, Tom, Вы писали:
Tom>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Tom, Вы писали:
G>>>>Каким образом сразу изменения отправлять? После изменения одного поля? В какой момент? Tom>>>Надо поменять данные — меняем сразу. G>>Ну и как это будет выглядеть? Поменяли поле — сразу полетел update? G>>Боюсь представить как это будет тормозить. Tom>Поменяли строку — полетел update. Для 95% кода это работает прекрастно. Tom>Есть места где нужна групировать обращения к базе что бы улучшить производительность. Tom>Там можно использовать хранимки. Tom>ИМХО Change Tracking изменённых рядов — в 95% случаев не нужен и является преждевременной оптимизацией. Tom>Отслеживание же изменённых полей в одном ряду — может быть полезной фичёй но не жизненно необходимой.
Если заниматься трекингом изменений объектов, то нету разницы трекать один или множество.
G>>>>>Каким образом сразу изменения отправлять? После изменения одного поля? В какой момент? Tom>>>>Надо поменять данные — меняем сразу. G>>>Ну и как это будет выглядеть? Поменяли поле — сразу полетел update? G>>>Боюсь представить как это будет тормозить. Tom>>Поменяли строку — полетел update. Для 95% кода это работает прекрастно. Tom>>Есть места где нужна групировать обращения к базе что бы улучшить производительность. Tom>>Там можно использовать хранимки. Tom>>ИМХО Change Tracking изменённых рядов — в 95% случаев не нужен и является преждевременной оптимизацией. Tom>>Отслеживание же изменённых полей в одном ряду — может быть полезной фичёй но не жизненно необходимой. G>Если заниматься трекингом изменений объектов, то нету разницы трекать один или множество.
Да но трекинг вносит очень сильное усложнение системы... По этому я бы подходил тут осторожно.
Если в каком то конкретном месте нужна оптимизация и трэкинг может помоч — пожалуйста используйте.
Если нет — то нах.
Здравствуйте, Tom, Вы писали:
G>>>>>>Каким образом сразу изменения отправлять? После изменения одного поля? В какой момент? Tom>>>>>Надо поменять данные — меняем сразу. G>>>>Ну и как это будет выглядеть? Поменяли поле — сразу полетел update? G>>>>Боюсь представить как это будет тормозить. Tom>>>Поменяли строку — полетел update. Для 95% кода это работает прекрастно. Tom>>>Есть места где нужна групировать обращения к базе что бы улучшить производительность. Tom>>>Там можно использовать хранимки. Tom>>>ИМХО Change Tracking изменённых рядов — в 95% случаев не нужен и является преждевременной оптимизацией. Tom>>>Отслеживание же изменённых полей в одном ряду — может быть полезной фичёй но не жизненно необходимой. G>>Если заниматься трекингом изменений объектов, то нету разницы трекать один или множество. Tom>Да но трекинг вносит очень сильное усложнение системы... По этому я бы подходил тут осторожно. Tom>Если в каком то конкретном месте нужна оптимизация и трэкинг может помоч — пожалуйста используйте. Tom>Если нет — то нах.
Если от слов перейти к делу, то окажется что при любой работе с данными в духе "прочитал-изменил-записал" понадобится трекинг.
Только в очень редких случаях этот самый трекинг будет необязателен.
Если же все изменения данных делать запросами, то трекинг не нужен будет.
Здравствуйте, stump, Вы писали:
S>Здравствуйте, Tom, Вы писали:
Tom>>Всем привет,
Tom>>Хотелось бы в одном месте, например в одном топике собрать все проблемы которые вытекают из обьектно ориентированного способа работы с данными (БД) и использовании ORM средств.
S>Ага. Вот статейка в тему, если кто не читал еще "25 причин чтобы не писать свой ORM" S>Большинство из перечисленных причин, суть проблемы которые в той или иной мере вынуждены решать все ORM.
G>Если от слов перейти к делу, то окажется что при любой работе с данными в духе "прочитал-изменил-записал" понадобится трекинг. G>Только в очень редких случаях этот самый трекинг будет необязателен. G>Если же все изменения данных делать запросами, то трекинг не нужен будет.
Я как то себя теоретиком прямо почувствовал.
Ещё раз, трекинга у нас нет и пока не нужен.
С перфомансом всё хорошо.
Здравствуйте, Tom, Вы писали:
G>>Если от слов перейти к делу, то окажется что при любой работе с данными в духе "прочитал-изменил-записал" понадобится трекинг. G>>Только в очень редких случаях этот самый трекинг будет необязателен. G>>Если же все изменения данных делать запросами, то трекинг не нужен будет. Tom>Я как то себя теоретиком прямо почувствовал. Tom>Ещё раз, трекинга у нас нет и пока не нужен. Tom>С перфомансом всё хорошо.
Трекинг не для перформанса нужен, а чтобы корректно получать changeset измененных данных и формировать пачку update.
Причем при наличии механизма трекинга становится неважно сколько объектов трекается один или миллион.
Трекинг не нужен если вручную указывать какие записи обновлять и в update записывать все поля.
Ну или при ручном формировании запросов.
G>Трекинг не для перформанса нужен, а чтобы корректно получать changeset измененных данных и формировать пачку update. G>Причем при наличии механизма трекинга становится неважно сколько объектов трекается один или миллион. G>Трекинг не нужен если вручную указывать какие записи обновлять и в update записывать все поля.
Давай всё таки различать 2 разные вещи. Tracking изменённых рядов, и tracking изменённых колонок одного ряда.
Первое — отслеживание изменённых рядов ИМХО классический пример преждевременной оптимизации.
Транзакции БД как раз для этого и предназначены.
Второе в теории может быть полезно, что бы не делать обновление всех колонок.
Но опять же полезно и нужно только в 5% а то и меньше порцентах случаев.
Здравствуйте, Tom, Вы писали:
G>>Трекинг не для перформанса нужен, а чтобы корректно получать changeset измененных данных и формировать пачку update. G>>Причем при наличии механизма трекинга становится неважно сколько объектов трекается один или миллион. G>>Трекинг не нужен если вручную указывать какие записи обновлять и в update записывать все поля. Tom>Давай всё таки различать 2 разные вещи. Tracking изменённых рядов, и tracking изменённых колонок одного ряда. Tom>Первое — отслеживание изменённых рядов ИМХО классический пример преждевременной оптимизации. Tom>Транзакции БД как раз для этого и предназначены.
Это понятно.
Tom>Второе в теории может быть полезно, что бы не делать обновление всех колонок.
Если есть второе, то и первое есть.
Tom>Но опять же полезно и нужно только в 5% а то и меньше порцентах случаев.
Да ну, вписывать все поля в set может быть накладно, особенно если много update_ов.
G>>Трекинг не для перформанса нужен, а чтобы корректно получать changeset измененных данных и формировать пачку update. Tom>Давай всё таки различать 2 разные вещи. Tracking изменённых рядов, и tracking изменённых колонок одного ряда. Tom>Первое — отслеживание изменённых рядов ИМХО классический пример преждевременной оптимизации. Tom>Транзакции БД как раз для этого и предназначены.
У тебя неверное понимание трекинга. У него есть один плюс(хотя это зависит от некоторых обстоятельств). Он укорачивает транзакцию и делает ее неблокирующей. Вообще-же он состоит из двух механизмов. 1 — это сам трекинг. То есть сохранение измененных объектов в сухом месте. Во-вторых, это версионификация записи при сбросе в БД. Никакого перфоманса он не несет. Инструмент перфоманса — кэш, который должен быть масштабируемым, и может разделяться между различными транзакциями.
Трекинг, предотвращает поднятие неизмененного объекта в контексте транзакции. То есть, все остальные транзакции изолированы от данной, и работают с другой версией данных. В случае, если используется навигационный доступ к объектам, это фича может быть весьма полезна. Вместо повторной загрузки, берется измененная, локальная для данной транзакции, ссылка на объект. То есть, это один инстанс объекта для всей транзакции. Это позволяет строить достаточно долгие транзакции прозрачно для прикладника. Но она работает только в если используются оптимистические транзакции, так как для сброса изменений нужна проверка актуальности.
Правда тут также существуют и недостатки. Во первых, для сложных запросов с группировками, и сложным блоком where по данным оно не работает. Во-вторых, оно не предназначено для массовых update.
Но никакого perfomance — оно не несет. Скорее наоборот.
