Помогите найти доводы для начальства

← →
Александр Иванов © (2006-06-23 09:26) [0]

Правильно ли держать открытую транзакцию, при редактировании данных пользователем? Я считаю, что неправильно, начальство хочет заставить это сделать.

← →
ANB © (2006-06-23 09:29) [1]

Скажи начальнику, что он дурак.

Если не хочешь говорит лично, попроси его завести топик на SQL.RU. Ему там об этом много народу скажет.

← →
Александр Иванов © (2006-06-23 09:29) [2]

Причина: есть список строк, которые кешируются и транзакция предлагается как альтернатива кешированию, я понимаю, что это абсолютно неверно, но ...

← →
Александр Иванов © (2006-06-23 09:31) [3]

ANB © (23.06.06 09:29) [1]

Это не совсем довод :)

← →
Ega23 © (2006-06-23 09:33) [4]

Смотря какой Isolation Level. ИМХО.

← →
Тульский © (2006-06-23 09:35) [5]

Я - начальник, ты - дурак (с)

← →
ANB © (2006-06-23 09:37) [6]

> Александр Иванов © (23.06.06 09:31) [3]

1. Доводы там укажут.
2. Кеширование надо делать на клиенте. Делать это с помощью транзакций - нарываться на проблемы блокировок.
Имхо :
Транзакция, согласно определения, это некая совокупность действий с БД, которая должна либо выполнится вся, либо не выполнятся совсем. При этом рекомендуется транзакцию выполнять как можно быстрее, т.к. частенько при этом выставляются блокировки.
Сама идея кеширования меня никогда не привлекала, т.к. приходилось на своих программах рабоать. Очень неудобно, когда полчаса или больше забиваешь какой то список, а потом из за какой то причине, на последней строке все отваливается и работа ушла впустую. Я бы сделал буферную таблицу, куда все складывал, а при нажатии кнопки "сохранить" переписывал в боевые таблицы.

← →
Александр Иванов © (2006-06-23 09:37) [7]

Ega23 © (23.06.06 09:33) [4]

Что-то не нашел я выбора уровня в ODAC, работаю с Ораклом

← →
Ega23 © (2006-06-23 09:39) [8]

> Что-то не нашел я выбора уровня в ODAC, работаю с Ораклом

Тады сорри, с Ораклом не знаком...

← →
ANB © (2006-06-23 09:41) [9]

> Александр Иванов © (23.06.06 09:37) [7]

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

← →
ANB © (2006-06-23 09:43) [10]

Уровень изоляции у оракла как то менять можно (хотя я не уверен), но :
1) Никто этого не делает
2) по причине 1) обычно мало кто знает как.
Вроде как я видел что то в настройках инстанса. Но из клиента его точно не поменяешь.

← →
Александр Иванов © (2006-06-23 09:45) [11]

ANB © (23.06.06 09:43) [10]

В дот Нете с уровнями в Оракле работал, здесь не нашел.

← →
ANB © (2006-06-23 09:45) [12]

> Александр Иванов © (23.06.06 09:37) [7]

Таки задай вопрос на SQL.ru. Ща придет мой начальник, он там постоянно пасется (модератор softwarer), он твоего начальника аргументированно размажет по стенке. Только задай его с уверенностью, что так делать и надо (от лица своего начальника). Тогда точно обратят внимание и размажут.

← →
ANB © (2006-06-23 09:47) [13]

> В дот Нете с уровнями в Оракле работал

Я, честно говоря, даже не знаю, как будет работать оракл при изменении уровня изоляции. Скорее всего, он игнорировал твои настройки в дот.нете.

← →
Курдль © (2006-06-23 09:48) [14]

> Александр Иванов © (23.06.06 09:37) [7]
> Что-то не нашел я выбора уровня в ODAC, работаю с Ораклом

И не ищи! Работать с ораклом и при этом использовать грязное чтение, - это волюнтаризЬм!
Оракл не блокирует доступ к таблицам, у которых открыты транзакции (на от он и оракл, а не МС СКЛ). Однако, начинает жрать ресурсы.
Я не представляю Вашей конечной цели, но в моих проектах всегда были формы, на которых предполагалось редактирование многих строк и даже многих взаимосвязанных таблиц одновременно. Все это нормально разруливают датасэты с кэшированием. Лучше всего - датасэты от ADO.NET.

← →
Александр Иванов © (2006-06-23 09:52) [15]

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

← →
Курдль © (2006-06-23 09:54) [16]

> Александр Иванов © (23.06.06 09:52) [15]

Все равно не ясно :(
Деревянная структура?
Что значит "все связанные"? Друг с другом?

← →
Danilka © (2006-06-23 09:55) [17]

[11] Александр Иванов © (23.06.06 09:45)
> В дот Нете с уровнями в Оракле работал, здесь не нашел.

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

[15] Александр Иванов © (23.06.06 09:52)
А по подробней можно? Шото я не понял ничего, а особенно, зачам здесь длинные транзакции.

← →
Александр Иванов © (2006-06-23 09:59) [18]

Danilka © (23.06.06 09:55) [17]

Там просто при создании транзакции один из параметров - уровень изоляции.

← →
Danilka © (2006-06-23 10:06) [19]

[18] Александр Иванов © (23.06.06 09:59)
Понятно, просто я смысла не вижу, если все транзакции - короткие.

← →
Александр Иванов © (2006-06-23 10:08) [20]

Danilka © (23.06.06 09:55) [17]

Ну список там обычный, одно из полей - ссылка на предыдущую запись

← →
Danilka © (2006-06-23 10:15) [21]

[20] Александр Иванов © (23.06.06 10:08)
Извини, все равно непонятно нифига :))

На клиенте есть список, так?
Там-же на клиенте есть грид, так?
Выбираем какую-то запись из списка, она попадает в грид, а из списка исчезает?

← →
Александр Иванов © (2006-06-23 10:32) [22]

Danilka © (23.06.06 10:15) [21]
Таблица в базе, на клиенте грид с кешированием. В грид попадают записи из другой таблицы, которых нет в гриде, фильтрацию осуществляет хранимая процедура, следовательно ей надо сообщать о тех записях, которые уже добавлены. Из-за этого предлагают отказаться от кеширования, и держать открытую транзакцию, в момент начала редактирования.

← →
Sergey13 © (2006-06-23 10:40) [23]

> [22] Александр Иванов © (23.06.06 10:32)

С такими описаниями задачи не мудрено, что вы идете нестандартными путями.

← →
Danilka © (2006-06-23 10:46) [24]

[22] Александр Иванов © (23.06.06 10:32)

> Таблица в базе, на клиенте грид с кешированием

Понятно

> В грид попадают записи из другой таблицы, которых нет в
> гриде

как я понимаю, во время редактирования попадают?

> фильтрацию осуществляет хранимая процедура

фильтрация чего?

как вообще происходит редактирование? если не сИкретная информация, можно более подробно расписать, а то до сих пор нифига не понятно, например:
есть таблица А с полями А1, А2, А3.
Есть таблица Б с полями Б1, Б2, Б3.
тваблица А открывается в гриде.
таблица Б - список.
юзер выбирает запись из списка, в результате в гриде формируется новая запись. сейчас эта операция сделана с помощью ХП - информация о записи из Б попадает таблицу какую-то на сервере и грид с записями А переоткрывается...

← →
Курдль © (2006-06-23 10:58) [25]

> Александр Иванов © (23.06.06 10:32) [22]

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

Вот это мне тоже непонятно:

> Ну список там обычный, одно из полей - ссылка на предыдущую
> запись

Что, "хвост в гриву"? Или все же "родитель - наследник"?

← →
Val © (2006-06-23 11:00) [26]

Между прочим, пока я не понимаю, из приведенного описания, чем в данном случае плох select for update. Вам пофиг, что другие юзеры будут менять у себя те же выбранные вами, например, в клиентский кеш записи, а потом вы выброской из кеша все их изменения похерите?

← →
Desdechado © (2006-06-23 11:12) [27]

Я читал-читал, но так и не понял, что именно автор хочет (или не хочет) сделать.
А по "держать открытую транзакцию, при редактировании данных пользователем" думаю, что если транзакция только читающая, то держи, сколько влезет.
Редактировать датасет на клиенте можно и так. Изменения потом в короткой транзакции(ях) можно скинуть на сервер. Обычно одни и те же данные 2 чела не редактируют (разные сферы ответственности). Но даже если так, то кто последний, тот и папа.

← →
Курдль © (2006-06-23 11:20) [28]

> А по "держать открытую транзакцию, при редактировании данных
> пользователем" думаю, что если транзакция только читающая,
> то держи, сколько влезет.

Проснитесь!!! Не бывает у оракла "читающих транзакций"! Это продукт воспаленной фантазии авторов IB!
Он имел в виду конкретно транзакцию "пишущую"!

Правильный ответ надо искать в логике работы с данными конкретной предметной области. а не среди множества усвоеных с опытом правил и аксиом.

> Не бывает у оракла "читающих транзакций"!
Я не настолько знаком с Ораклом, чтобы спорить. Прошу указать, где в документации это написано.
Логически же рассуждая, не верю, что SELECT блокирует записи от изменения. Данные получены, серверу должно быть уже все равно, что с ними будет делать клиент, особенно если он ничего делать не собирается.

> Он имел в виду конкретно транзакцию "пишущую"!
1. Не вижу, из каких объяснений автора это следует.
2. Если нет "читающих", значит абсолютно все "пишущие"?

транзакция "пишущая". Структуру базы разрабатывал не я и менять мне не дадут, поэтому и задавал конкретный вопрос.

Ох, и любят же здесь длиннючие дискуссии ни о чем ;))

> Desdechado © (23.06.06 11:36) [30]
> Я не настолько знаком с Ораклом, чтобы спорить. Прошу указать, где в документации это написано.

Не буду даже искать. Просто нет такого понятия в нормальных СУБД "читающая транзакция". Даже сам термин "транзакция" не предполагает простого созерцания.

> Александр Иванов © (23.06.06 11:38) [31]
> транзакция "пишущая". Структуру базы разрабатывал не я и
> менять мне не дадут, поэтому и задавал конкретный вопрос.

Однако, если хотите, чтобы Вас поняли, - вот мой совет - старайтесь в описаниях приближаться к универсальному языку проектирования БД.
Не надо нам про таблицы, ключи, индексы и их связи. Оперируйте сущностями, связями и правилами.

> [7] Александр Иванов © (23.06.06 09:37)

В ОДАКе я не искал, но в документации по Ораклу есть следующее:
ISOLATION_LEVEL
Syntax:
ISOLATION_LEVEL = {SERIALIZABLE | READ COMMITTED}
The ISOLATION_LEVEL parameter specifies how transactions containing database
modifications are handled. ISOLATION_LEVEL is a session parameter only, not an
initialization parameter.

Но не думаю, что тебе это надо. Я тоже ничего не понял из твоих объяснений, что ж ты хочешь?

>[34] evvcom © (23.06.06 11:58)
:) из описания никто ничего не понял вот и трепемся помалеху, пока автор описание пишет...

Курдль © (23.06.06 11:54) [33]
> нет такого понятия в нормальных СУБД "читающая транзакция".
> Даже сам термин "транзакция" не предполагает простого созерцания.
Т.е. SELECT выполняется вне контекста транзакции?! А если он единственный запрос за все время работы с БД?

> [37] Desdechado © (23.06.06 12:05)
> Т.е. SELECT выполняется вне контекста транзакции?! А если
> он единственный запрос за все время работы с БД?

Ну и что?

> нет такого понятия в нормальных СУБД "читающая транзакция".

А вот что пишет Том Кайт:
SET TRANSACTION. Этот оператор позволяет устанавливать атрибуты транзак-
ции, такие как уровень изолированности и то, будет ли она использоваться толь-
ко для чтения данных или для чтения и записи. Этот оператор также позволяет
привязать транзакцию к определенному сегменту отката.

> [39] evvcom © (23.06.06 12:18)

Ну и что? Этот оператор устанавливает свойства транзакции, а не стартует ее. Вся сессия, по большому счету - "читающая транзакция", хотя мне лично тоже этот термин слух слегка режет 8-).

Помогите найти доводы для начальства Найти похожие ветки