Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Решение: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:43 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
причем работа проходит в режиме Uncommited Read (грязное чтение) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:44 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenman Можно поработать на складе. Предположим у нас есть 100 ящиков какого-то товара. И в разных филиалах его продают. сначала - оформление документов (выписка фсяких накладных и пр...). И чтоб пока документы оформляются - наши ящики не ушли кому-нить другому. Все - одной транзакцией. В общем - условия - те же... Бред. При чем здесь транзакции? Не видел ни одного заказчика, который описывая требования к системе упомянул бы условие "Все - одной транзакцией". А вот условие "что бы ящики не ушли" решается элементарно при правильном проектировании. Например введением понятия "резервирование", которое может происходить еще до выписки документов. -- http://talk.ru/forum/talk.ru.accounting.development ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:49 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
системы всякие бывают...)) требования разные... но подходы к решению проблем могут быть одними и теми же... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:53 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Ты зря не привел скрипт создания инстанса с включением в пост всех скриптов Оракла. Было бы нагляднее. Ответь мне на вопрос - а где учет мест? Ведь тому мужику, что насилует кассиршу, надо плацкартные НЕБОКОВЫЕ. А если их назавтра нет, то он поедет послезавтра. причем работа проходит в режиме Uncommited Read (грязное чтение) Ты мне просто скажи - на каком вокзале это работает? В каком городе? А то вдруг я туда поеду. Предупрежден - уже вооружен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 14:57 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Вы еще про бронирование забыли. Это когда деньги еще не уплачены, а билеты уже формально проданы (то есть их нет в наличии в кассе). Значит ли это с точки зрения автора топика, что транзакция закончится только когда человек придёт и выкупит билеты реально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:00 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenmanсистемы всякие бывают...)) требования разные... но подходы к решению проблем могут быть одними и теми же... Странная задача на самом деле. В начале вы намекаете что сущьность места не нужна (едем в электричке?) достаточно кол-ва свободных мест в поезде, а потом очень долго забиваете паспортные данные (куда?). Т.е. система учитывает сколько свободных мест и какие паспорта едут в этом поезде? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:18 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
))) Ну уж нет, раздувать простой пример до решения для МПС я не намерен...)) так что решение с плацкартом и СВ с девушкой для Сереги - предоставим кому-нить другому. Ладно, более подробно, как это все работает: 1) К 1 окошку подходит гражданин и заказывает 600 билетов set isolation ur insert into locks values ('C100','31.12.2004',600,1) DB20000I Команда SQL выполнена успешно. гражданин сует кучу паспортов, бабки и ждет когда его оформят по полной программе. 2) Ко 2 окошку подходит другой гражданин и пытается заказать 500 билетов: set isolation ur insert into locks values ('C100','31.12.2004',600,2) SQL0438N Программа генерирует ошибку с текстом диагностики: "Too many tickets". SQLSTATE=75001 Срабатывает триггер BILocks, мэн получает отлуп по полной программе и уходит, а к окошку подходит следующий и заказывает 4 билета insert into locks values ('C100','31.12.2004',4,2) DB20000I Команда SQL выполнена успешно. --от автора: Код: plaintext 1. 2. 3. 4. 5. 6. 3) во втором окошке все напечатали, бабки приняли и делается: insert into sales (route_num,departure_dt,desk) values ('C100','31.12.2004',2) commit срабатывает триггер BISales, чтобы продать именно столько билетов сколько было заблокировано и срабатывает триггер AISales, который обновляет кол-во проданных билетов в routes. Тут же делается commit, поэтому таблица routes не блокируется надолго. А блокировки в таблице locks от 2 окошка на 4 билета снимается. --от автора Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. а в это время в 1 окошке все еще незаконченная транзакция по продаже 600 билетов все еще висит, нужное кол-во билетов блокировано... а тем временем 2 окошко может обслуживать следующего потенциального пассажира. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:25 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
теперь можете критиковать.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:26 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenman))) Ну уж нет, раздувать простой пример до решения для МПС я не намерен...)) Так ты для детской пластмассовой ЖД что ли? Тогда пойдет. gardenmanтак что решение с плацкартом и СВ с девушкой для Сереги - предоставим кому-нить другому. Вот так всегда. gardenman1) К 1 окошку подходит гражданин и заказывает 600 билетов set isolation ur insert into locks values ('C100','31.12.2004',600,1) DB20000I Команда SQL выполнена успешно. гражданин сует кучу паспортов, бабки и ждет когда его оформят по полной программе. После ввода 599 паспортов система вешается и "спасает" ситуацию только комбинация из трех пальцев. В системе благополучно залочено 600 мест. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:39 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
увы... транзакция благополучно откатится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:42 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Поддерживаю Серегу :) И еще: автора в это время в 1 окошке все еще незаконченная транзакция по продаже 600 билетов все еще висит, нужное кол-во билетов блокировано... Объясните, зачем вам тут транзакция??? Общая, одна на все 600 билетов, зачем? Вы что, по-человечески, без транзакции, не можете спокойно зарезервировать 600 билетов для пластмассовой ЖД и потом оформлять их хоть три дня подряд? И еще автор-- Продаем именно столько билетов, сколько заблокировали Так вы еще их скопом продаете? Не по одному? А зачем такой гимор? А если придется сделать комбинацию из трех пальцев - ту, что постом выше - то и информация всех 599 паспортов улетит в ж.. это, в трубу? Круто! -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:47 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Ну я надеюсь, судя по всему, что Экспресс-2 (и 3) не по такой схеме делали, иначе бы вокзал дневное количество билетов месяц продавал бы -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 15:48 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Опять никто никого не понял... Или я никого не понял, но сделал следующие выводы: 1) Разделить понятия транзакций с СУБД и транзакций с кассиршой 2) Таблица с блокировками - кривая система резервирования Блокировки допустимы только во время проведения операций с базой. Взятие денег, ввод данных - не операция с базой, а операция с клиентом. Блокировки нужны более высшего уровня. Операция резервирования и операция реализации лежат в одной таблице, которая привязана к таблице с рейсами. Их различие ведется по статусу. На кол-во свободных мест стоит ограничение >0. Если кто-то захочит вставить лишнее - не выйдет. Сначала добавляем икс билетов в расход со статусом зарезервировано, триггером снимаем этот икс с таблицы со свободными местами. Затем кассир вбивает свою муть получает деньги и переводит статус в продано. Если при срабатывании триггера срабатывает ограничение, то кассир обламается с резервированием - и вбивать ничего не придется. Если клиентский комп отвалился, то тетка решает, вешать ли ей табличку "технический перерыв", то ли ждать разрешения проблемы связи. При возобновлении связи в первом случае она удаляет резерв, во втором доводит дело до конца. Если необходим учет разновидности мест(товарной сущности), то это надо соответственно отразить в предложенном варианте. Почему все бьются над одной и той же проблемой, и все время призывают в помощь уровни изоляции???!! И лень поискать на форуме. Здесь уже обсуждался похожий пример, только там был склад и выписывание товара, что по сути одно и тоже. Ссылку не дам, лень искать. Думайте, господа, над сущностью телодвижений "клиентов" и их взаимосвязью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 23:02 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 iLLer Правильно все понял - мы о том же и говорим с Серегой. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2004, 11:36 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
"Усиленное решение". Я так понимаю единственная проблема была в триггере BILocks, дескать он может сработает не совсем так как нужно в конкурентной среде. Т.е. Я и Ёжик намекал на то, что всеже могут быть проданы лишние билеты (особенно если убрать CHECK CONSTRAINT AtCnt на таблице ROUTES). Конечно же я осознаю, что то, что сейчас здесь будет нарисовано не будет работать ни на одной из известных мне баз кроме DB2. Напишем хранимую процедуру на С++ в которой создадим именнованный мьютекс. Таким образом получится что инсертить в таблицу LOCKS (вместе со срабатыванием соответствующего триггера BILocks) в один момент времени может только один клиент. Makefile Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. reserve.def Код: plaintext 1. 2. reserve.sqx Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. таким образом чтобы заблокировать соответствующие билеты с 1000 станций (начать соответствующие транзакции, каждая из которых может кончится когда угодно, не мешая другим и при этом всё будет согласовано и ни каких лишних билетов на машине с Celeron 1300 в качестве сервера уйдет примерно 4 секунды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2004, 11:37 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Я уже начинаю думать, что мы со слепым тут разговариваем - не видит человек ничьих постов, кроме своих, ну хоть ты тресни. Доктор....... Доооооктооооорррррр......................рррррр.....рррр..... :) авторНапишем хранимую процедуру на С++ в которой создадим именнованный мьютекс. Таким образом получится что инсертить в таблицу LOCKS (вместе со срабатыванием соответствующего триггера BILocks) в один момент времени может только один клиент. Инсертить всегда в один момент времени может только один клиент, особенно если он использует транзакцию. gardenman начать соответствующие транзакции , каждая из которых может кончится когда угодно, не мешая другим и при этом всё будет согласовано и ни каких лишних билетов на машине с Celeron 1300 в качестве сервера уйдет примерно 4 секунды Может вы все же объясните, что вы понимаете под транзакциями в данном контексте??? ============= Сам с собой человек разговаривает - круто, да? А зачем на форус обратился? Чтобы его гениальный алгоритм все увидели? Дык увидели, и даже прокомментировали.... Что же еще? -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2004, 11:53 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
gardenman"Усиленное решение". Вообще существует ещё много интересных и не менее полезных занятий в этом мире, например изобретение вечного двигателя. gardenman Я так понимаю единственная проблема была в триггере BILocks, Не единственная, а первая попавшаяся на глаза . В Вашу синхронизацию как минимум надо включить оба ваши триггера на sales и и все возможные операции на routes, только тогда можно будет ожидать корректных результатов. Т.е. по сути Вы ВСЕ операции с базой данных над таблицами locks,sales, routes выстраиваете в очередь, т.е сериализуете ( как вам и говорил vc123) только не на уровне БД а на уровне OS, искусственно выделив из сериализации часть транзакции по вводу данных паспортов. Не проще ли выделить этот ввод в отдельную транзакцию и не мучиться изобретением велосипедов? tygra Я уже начинаю думать, что мы со слепым тут разговариваем - не видит человек ничьих постов, кроме своих, ну хоть ты тресни. Он же сказал уже: "Смысл того, что здесь написано совсем другой. И я имел в виду совсем не то, о чем ты подумал. Я хочу сказать что существует класс задач, для которых Оракл не катит." Его не интересует как "правильно и эффективно" решить реальную задачу, он хочет показать, что в такой кривой постановке её можно решить только на блокировочнике с грязным чтением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2004, 14:03 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
В упор не вижу причин для: 1) Невозможности реализации на Oracle или любой другой SQL-СУБД. И даже не столько невозможности, сколько не профильности. Если у Вас будет один сервак и тыща касс, то многие СУБД могут загнуться. 2) Необходимости применения уровней изоляции (не блокировок, так как это понятие растяжимое). Необходимо разделить понятия транзакционности. То ли для Вас транзакция - это факт изменения данных в БД, то ли факт оформления покупки. И совершенно не обязательно одно натягивать на другое. 3) Необходимости применения синхронизации работы клиента (А какого черта Вы тогда вообще в СУБД лезете, еще чуть-чуть подправить, организовать хранилище данных в файле, и будет совсем автономная система, а вернее СУБД). СУБД для того и нужна, чтоб организовать надежный доступ многих страждующих к одним данным и она берет на себя задачу сериализации транзакций. Пора призывать модераторов закрывать эту тему. Ибо начальный вопрос потерян и не уместен в данном контексте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2004, 22:41 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Его не интересует как "правильно и эффективно" решить реальную задачу, он хочет показать, что в такой кривой постановке её можно решить только на блокировочнике с грязным чтением. 1) Хотел бы увидеть почему моё решение неправильное. Пожалуйста - аргументы. Хотите сказать что оно не работает? Привидите такую последовательность действий над системой, когда результат будет не таким, каким я его ожидаю. 2) Почему моё решение неэффективное? У вас есть более эффективное? требующее меньшего I/O, меньших затрат на програмимирование, увеличивающее параллелизм? >Пора призывать модераторов закрывать эту тему У нас появился цензор? Меня записали в еретики? Сожжете на костре? 3) У каждой задачи существует множество решений, также, как существует множество людей. И увы, не нам решать имеют ли они право на существование. Теперь еще раз медленне и подробнее. Два пользователя хотят изменить в записи поле с остатком. пользователь А делает select for update nowait - блокирует запись. Пользователь Б также делает select for update nowait - и получает отлуп. Если он сделает просто select for update - то подвиснет до тех пор, пока А не сделает commit. Таким образом они редактируют запись по очереди . И от этого конечно не избавиться ни в одной системе. Но в отличие от версионника, блокировочник может построить очередь из таких незавершенных запросов (транзакций) и, спрогнозировав сколько билетов осталось в кассе ( несмотря на то, что еще не все транзакции закоммичены ) сказать - можете не занимать очередь, вам все равно не хватит. Но если хотите испытать судьбу - подождите. Может вам и достанется. Или, например в другом случае, не просто дать отлуп на select for update nowait, а сказать - знаете, а эту запись редактирует сейчас Вася Пупкин, который сидит этажом выше, и хочет списать со счета 50 баксов, на счете останется еще 100 баксов. И, если вы хотите снять в пределах этих ста баксов - то пожалуйста - путь свободен. Если больше - то извините...(( За сим прощаюсь с вами. Всем удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2004, 11:24 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
2 gardenman ИМХО. Все твои ухищрения основаны на желании открыть транзакцию при обращении пасажира и закрыть ее после ввода 600 документов. Я тебе в самом начале описал как можно сделать в системах с высокой конкуренцией за данные. Просто для этого надо продумывать соответствующую структуру данных. Извращаться на хреновой (гипотетически упрощенной и отвлеченной от конкретной задачи) структуре с уровнями изоляции конечно можно, но непродуктивно. Опять же повторюсь - ИМХО . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2004, 12:04 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
to gardenman: 1) Никто не говорит, что Ваше решение неправильное. Вообще в жизни нет такого понятия, как правильно. 2) На счет меньших затрат на программирование - это точно. В Вашем варианте Вы делаете работу (по программированию), которую должна выполнять СУБД. 3) Я не цензор, это мое мнение 4) Все имеют прваво на существование 5) Также медленно: к чему вообще селект? В том смысле зачем Вам селект в одной транзакции с апдейтом? Первая транзакция: селект состояния по билетам, далее по желанию вывод на экран, сохранение в файл, распечатка, отсылка и т.д. Вторая: клиент посылает апдейт на изменение значения доступного кол-ва либо добавляет в систему документ о проведении операции резервирования, которая влечет изменения статусов доступности. В зависимости от реализации. Если вторая транзакция вернулась с ошибкой, то все ясно, мест нет. И можно сразу смело посылать покупателя, т.к. мест нет. Если места есть, то вбиваются детали и переводится состояние из "резерв" в "продан". Поднимитесь вверх и медленно прочтите мое предложение о реализации системы резервирования. Я уже это писал. И не только я. А с прогнозированием это Вы загнули. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2004, 12:49 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Да не слышит человек ни одного другого, отличного от его самого, мнения и решения. Придумал кошмар ночной и радуется до смерти. До смерти - это потому, что помрут все с такой реализацией. Ну как не понять, что обычным резервированием дело решается - не знаю. Без открытых висячих транзакций, грязных чтений и т.д. Ээээхххххххх -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2004, 14:46 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Хорошие вы все ребята, душевные.... Я сначала было подумал не отвечать... но блин вчера было так скучно и тоскливо в форуме... А вообще чем попусту сотрясать воздух (а ля тигра) я предпочитаю сначала подумать, а потом дать аргументированный ответ. Для начала несколько ситуаций: 1) Студент вытаскивает на экзамене говорит препаду: 13 билет, но отвечать я буду на 1 билет, потому, что я только его выучил 2) Заказчик приходит к подрядчику и говорит: вот нужно написать такую-то систему, можете ее реализовать на Оракле. Подрядчик - конечно можем...так что тут у Вас? а.. отлично, мы беремся, вот только реализация будет на MSSQL и вот это и это вы как-нить сами... 3) Если кто-то расписался в своем бессилии доказать теорему Ферма, то не проще было бы поменять вообще эту теорему, так сказать изменить условия задачи? Ситуация из жизни, с которой я сталкиваюсь ежедневно на работе: представляете (сразу говорю, автор не я!!!!) у нас параметры в ХП передаются через запись в постоянной таблице!!! А что это значит? То, что если человеку взбредёт в голову войти под своим своим логином с двух компов, то получится конфликт параметров! Рассмотрим подробнее ситуацию с резервированием. Сия ситуация означает, что транзакций в системе будет несколько. Одна с резервированием, другая - собственно с продажей. Следовательно записи на резервирование нужно как-то идентифицировать. Варианты: по имени пользователя, по номеру сессии, по коду терминала. 1)По имени пользователя: если это так, то с двух терминалов под одним и тем же именем не зайти - конфликт параметров ХП (смотрите ситуацию, описанную абзацем) 2)По номеру сессии: в случае глюка/отсоединения терминала мы теряем номер сессии, придется каким-то образом оперативно чистить зарезервированные билеты.(у Оракла ведь есть триггер на закрытие соединения? в любом случае у MS такого точно нет). А как тогда быть с внесенными вами данными по 599 паспортам? *я читаю внимательно все что вы пишете, и ищу контраргументы*. 3)По коду терминала: та же самая ситуация что и по номеру сессии. Знаете, ну как-то влом писать сборщик мусора, который в тоже время должен отрабатывать достаточно оперативно. Намного более дешевое (с точки зрения I/O) и простое решение - просто откатить транзакцию. Вы думаете задача представленная здесь - единственная в своем варианте? Есть еще одна задачка над которой все думают и все решают по-совему. Нужно зачислить на счета зарплату 100000 человек. Предположим в компе уже имеется этот список в какой-то таблице. Хотите пообсуждать как будет выглядеть такое решение? С учетом, что в системе работает сразу несколько сотен юзеров? Как сделать так, чтобы все отработало в приемлемые сроки с минимумом накладных расходов? Или, например, как сделать так чтобы эта операция была распараллелена между несколькими процессами и количество конфликтов было бы минимальным? Ситуация из жизни (у меня на работе, делал не я ). Идет прием бланков строгой отчетности (БСО). Имеется документ на 20000 бланков. У каждого бланка свой индивидуальный номер. Бланки должны быть приняты одновременно (документ-то один! сервер Sybase ASE). Рузультат: После небольшого скандала документ решили разбить на 4 по 5000. Понятное дело - просто криво спроектированна реализация. А как бы вы решали эту задачу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 13:59 |
|
||
|
Задача для версионника
|
|||
|---|---|---|---|
|
#18+
Задачка специально для tygra, как для любителя MSSQL: Предположим, у нас имеется некий набор договоров. Над определенной группой договоров мы должны провести некую группу однотипных операций, например - банальное расторжение. Задача - Оператор в гриде на своем рабочем месте помечает эти договора (например заносит их id во временную таблицу) а затем передает этот список в ХП, которая все их закрывает. Затем дополняет список этих договоров еще некоторым количеством договоров (отбирая их по какому-нибудь критерию), а затем - передает их другой ХП, которая их переоформляет на новых условиях. Затем чистит пометки и повторяет операцию снова. Как это будет выглядеть на MSSQL? Понятное дело что временная таблица должна быть создана не в какой либо ХП, а самим приложением. И это должна быть не таблица с ##, потому как в этом случае она будет доступна всем сесииям. А тепрь еще наложим условие, что приложение у нас написано,исходников нет, и код мы можем только на сервере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 14:30 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32830471&tid=1546074]: |
0ms |
get settings: |
9ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
146ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
81ms |
get tp. blocked users: |
1ms |
| others: | 250ms |
| total: | 524ms |

| 0 / 0 |
