Булат Кутлиев: Ну тут абстрактно сложно присоветовать... наверное стоит смотреть план выполнения самой вложенной части и пытаться оптимизировать ее, потом следующую.
John_Nash: А в чем проблемы? Это всего лишь пространство имен - своего рода табличка на двери кабинета и не больше. Если что-то не работает - то отнюдь не этой причине. Так что нужны как минимум подробности "что и как не работает"
Иван Стародубцев: ну язык - частично наверное потянется из предметной области. Будь это системная часть из серии работы с оборудованием - то с и чуть-чуть с++, парсинг логов оборудования - вплоть до awk и т.п.
И чуть больше того - можно сказать этакая детская бигдата: совокупность запросов по интенсивности, повторяемости относительно других сотрудников.
А это уже иной уровень, который замечательно проиллюстрирован анекдотом "шеф провел чемпионат по тетрису и первую десятку рекордсменов уволил" -)
Читаем внимательнее -)
1. получаем ОДНУ запись для шаманства
2. шаманим
3. по результатам шаманства - пишем результат шаманства
Естественно в больших конструкциях зачастую в п.3 может быть и отметка времени и стэйт, а в п.3 отбор не только не окученных, но и для повторных попыток позиции со стэйтами подразумевающими повтор (сервис занят, таймаут) и счетчики попыток
GromWolf: не надо этот цикл делать. точнее делать пока sql что-то отдает.
А вот у sql просить "дай мне ОДНУ строчку по условиям..." - в общем то, что я и расписал выше.
по результатам дальнейшего шаманства с логином-паролем - писать в базу результат
в конечном итоге запрос перестанет возвращать результат (если в условии where будет только неокученные) - это и будет критерием окончания цикла.
Притом такая программа может быть прекращена в любой момент, а при повторном запуске продолжит перебирать только не окученных.
GromWolf: такого типа программа, подразумевая что она может прекратить свою работу и начать потом снова в любой момент как минимум должна уметь "помнить" на чем она остановилась.
Вполне разумным будет хранить такую информацию в БД рядом с логинами-паролями. Например в виде даты-времени последнего обращения. То есть структура будет состоять как минимум из трех столбцов (логин, пароль, отметка времени). Вполне очевидно что последняя колонка должна быть nullable - когда "еще не использовали пару"
Соответственно логика будет выглядеть так:
получить
одну строку
логин-пароль-[дата-время]
из таблицы
отсортированной по дате-времени
на sql это будет ровно так же как же как и словами:
select
top 1
[логин], [пароль], [дата-время]
from [имя таблицы]
order by [дата-время] asc
с полученной парой логина-пароля делаем нечто
и при нужном результате пишем в базу текущую отметку времени
update [имя таблицы]
set [дата-время] = getdate()
where [логин]= логину AND [пароль]=паролю
далее возвращаемся на исходную и получаем следующую одну строчку
p/s/ естественно логин и пароль - не лучший уникальный ключ для выбора - так что потребуется некий "уникализатор", дальше захочется сохранять результат прошлого обращения и в зависимости от результата возможно больше записи не выбирать, далее захочется делать это в несколько потоков...
M-Misha-M: ну да. Т.е. exception - это когда произошло что-то неожиданное и непредсказуемое или фатальное, а вот если вполне очевидно ожидаемое - то проверять это и что-то делать.
Adamos: я тоже реализовывал подобное, но при лицензионном аудите было немало замечаний. Даже при нехилых бюджетах закупки много чего и предварительных витках внутреннего аудита.