|
|
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
может кто-то имеет опыт работы с нарядами, извещениями и т.д. и т.п. Короче говоря, структура данных такова: Код: plaintext (стрелочки - один ко многим) Как проще и эффективнее организовать ввод данных для такой схемы? 1 вариант - по кусочкам. Т.е. формируется [наряд], затем к нему можно нарастить исполнителей и перечень работ. На каждую запись - отдельная транзакция. 2 вариант - все одной транзакцией (как по идее и должно быть). Все манипуляции с данными происходят на клиенте, а потом кэш сбрасываем в рамках одной транзакции. Но! все равно мы должны соблюдать последовательность ввода данных в базу. Т.е. нельзя сбросить данные об исполнителях, не имея там информации по наряду (что предусмотрено схемой базы). Тем не менее, я выбрал 1 вариант. Конечно чистая бизнес-транзакция здесь как-таковая отсутствует. Однако есть преимущество во времени - снижается вероятность блокировок. Для модемной связи пакетная транзакция тем более не есть хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2002, 08:52:24 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
м-да... рабочий день к концу подходит, похоже никто с OLTP сейчас не работает. всех 1С устраивает... надо переходить на OLAP :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2002, 13:30:32 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
Я применял в такой ситуации один в один стакой подход! Отдельно создавался/изменялся наряд и работы! А потом по работам расписывали исполнителей! Очень удобно! Все это использовалось в автосервисе и тормозов замечено небыло! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2002, 13:53:35 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
ерунда получается на клиенте. Для того чтобы откатить все изменения по одному наряду (нажав кнопку "Отмена") надо хранить либо перечень всех действий - изменение списка работ, исполнителей; либо... есть вариант все действия проводить в темповой табличке, а потом в рамках одной транзакции данные переносить в "нормальные" таблицы. Как-то все мудрено. Может есть более простое решение? Как откатить действия при вводе данных в схеме один ко многим? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 09:09:15 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
открыть еще одну сессию(со своей транзакцией..).... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 10:44:32 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
гм... ну да. Так можно. Ну допустим завел пользователь 30 значений на один наряд. Т.е. будет 31 сессия. Берем 10 пользователей, т.е. 310 соединений на сервере? или что-то не так? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 11:34:57 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
не... есть еще вложенные транзакции... ты детально алгоритм опиши(бизнес логику по шагам) и где у тебя затык... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 12:26:30 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
ну ладно. Попытка №2... необходимо занести в базу данные по наряду. Вот примерный состав данных - Наряд: дата, номер, подразделение. Суррогатный ключ identity. Работы: операция, время, деньги. На один наряд несколько работ. С удалением нарядов проблем нет :) Есть проблемы с вставкой и обновлением. Какой-то тормоз здесь. Допустим заводим новый наряд. Открывается на клиенте форма, указывает он номер, дату, подразделение, затем начинает вводить по работам. Как я могу занести данные по работам в таблицу, если еще нет ключевого поля по наряду? Форма содержит внизу две кнопки - "OK" и "Отмена". Т.е. пользователь может откатить вообще все изменения при вводе наряда. Завести одну транзакцию на ввод всей информации? Так она ведь заблокирует весь наряд! И длиться она может неопределенное количество времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 12:45:34 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
А что мешает сначала вставить наряд а потом его наполнить ? Не понял где возникает блокировка ? Используй оптимистичные блокировки. При открытии формы открывать соединение или начинать транзакцию по отмене роллбэк. Только отслеживать ошибку соединения (типа кто-то другой уже успел че то сделать с данными нового наряда) забивать болт или обрабатывать как надо и все . Или нужно именно "неоптимистично" блокировать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 13:04:40 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
нельзя вставить пустой наряд. Он должен быть заполнен. Если я буду изменять перечень работ по наряду в рамках одной транзакции, то при repeatableread эти данные будут заблокированы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 13:21:50 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
вопрос зачем здесь repeatableread ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 13:37:32 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
Вы предлагаете грязное чтение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 13:42:46 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
зачем грязное? readcommitted ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 13:47:43 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
на самом деле нужен ответ на вопрос зачем здесь repeatableread ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 13:49:38 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
что-то я не пойму... открываю QA, делаю так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. открываю второе окно: Код: plaintext 1. 2. блокировано! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 13:57:44 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
REPEATABLE READ конечно же моя ошибка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 14:05:17 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
все правильно ... транзакция не закончена вставленные ряды эксклюзивно заблокированы селект ждет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 14:08:30 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
при таком раскладе выход либо NOLOCK либо READPAST ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 14:11:07 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
да-да. Грязное чтение. А READPAST наверняка лучше :) Ладно. Буду пробовать. Вариант с транзакциями чем плох - продолжительное время удерживания ресурсов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2002, 14:18:56 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
нельзя вставить пустой наряд. Он должен быть заполнен. почему так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2002, 01:52:47 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
Я тоже так думаю: что за ерунда, зачем городить себе сложности... Наряд, как обычно, состоит из "шапки" и "строк детализации". Сначала создаем шапку (и прописываем в ней флаг "черновик", если уж очень хочется временно считать этот наряд недействительным), затем спокойненько, хоть в течение нескольких дней, дописываем строчки к этому наряду... Абсолютно никаких проблем не вижу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2002, 02:06:51 |
|
||
|
Разделить транзакцию
|
|||
|---|---|---|---|
|
#18+
2Mice: патамучто! :) значение имеет не наряд, а выполненные работы. Вместо метки "черновик" можно сделать к в банковском документообороте - состояние "закрыт/незакрыт". Соответственно всю дальнейшую работу (аналитику) проводить только с закрытым нарядом. С другой стороны, если наряд блокирован транзакцией на изменение, то его, собственно, никто и не увидит. Так что может быть все получится и без дополнительного признака. Посмотрим. Мне эту задачу необходимо реализовать в течении недели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2002, 06:09:52 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32069595&tid=1818674]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
199ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
2ms |
| others: | 219ms |
| total: | 536ms |

| 0 / 0 |
