Kull Damned > собственноручно кастрирую каждого, кто рефрешит записи в гриде на основании событий
Прошу прощения за оффтоп, но я тут рыдаю.
У kdv - бита, у МП - серп, у Amris'а - канделябр, а ты, Дим, чем будешь орудовать?


У коллеги Лоа тупые кусачки для отстригания пальцОв одолжит на время. Функциональность в общем и целом близкая.

А внедрить в таблицу хотя бы таймштамп дефаулт нау и селектить по нём - не готично?

ЛебедкинА насчет кастрирований там - лучше бы, перед тем как холодным оружием махать предложили бы тогда нормальное решение задачи:


Имхо с кастрацией уже поздно. С родителем надо было разбирацца :)

Лебедкин
Данные обновляются несколько раз в минуту, юзер должен видеть таблицу всегда со свежими обновлениями


Лично мне незнакомы задачи, в которых это на самом деле нужно. Знакомо много народу, искренне уверенного что нужно, но объяснить зачем они не могут. Знакомы также люди, втискивающие в СУБД-приложения несвойственные этим приложениям функции.

Лентяй[quot Лебедкин]
Ну возьми, для примера, хотя бы мою задачу:
Большой таксопарк. В минуту в БД записывается разными операторами до 10 заявок. Несколько диспетчеров, занимающихся распределением заявок на автомобили непрерывно должны видеть как поступающие заявки,


Гы, таки мой ТЛ в отличной форме даже в понедельник Так и знал, что задача именно эта. Тык вот, ему не нужно непрерывно видеть все поступающие заявки, ему нужно знать что они есть. И даже это не непрерывно, а только когда он (диспетчер) а) idle б) присутствует на рабочем месте. Т.е. евент должен сообщать только о факте появления в базе новых заявок. А уже диспетчер на осоновании этой информации должен самостоятельно инициировать себе рефреш набора именно в тот момент, когда он намерен взяться за новую заявку. И первое, что он должен сделать когда выберет себе строку для обслуживания - осуществить её пессимистическую блокировку и ещё раз отрефрешить именно эту строку персонально, ибо с тех пор, как он её пофетчил, её уже мог а) взять на обслуживание другой (для этого блокировка) и б) оное обслуживание даже вообще завершить (для этого рефреш). И по завершении обслуживания одной заявки безусловно перечитать весь набор, были там эвенты, не были... Насчёт состояния машин присоединяюсь к предыдущим ораторам.

2 Лентяй: помнишь ты меня спрашивал, зачем нужна возможность задавать транзакцию RefreshSQL персонально и управлять ей? Кроме того, что я тебе тогда сказал, ещё и этот случай - совпадение с транзакцией не SelectSQL, а ModifySQL. А бывает, что нужно то так, то этак - когда основной набор рефрешится не всегда целиком, а построчно тоже.

Лебедкин
И что бы тут не говорили про кривое программирование, система на основе рефрешей по событиям реально работает (не без огрехов кончно, а где их нет?), а значит имеет право на жизнь

Право на жизнь имеют все, включая олигофренов. Не нам решать кому жить, на то повыше есть. А вот как жить... Ысчо раз: диспетчеру информация о заявках нужна только в момент, когда он готов и собирается принять решение об обслуживании и выбор заявки. В режиме idle ему нужна информация только о _наличии_ заявок, чтобы принять другое решение - просмотреть список или пойти попысать. То есть, по уму эвенты нужны всего лишь для накручивания визуализации счётчика заявок при регистрации (а возможно и скручивания по событию завершения обслуживания), ну и, может, помявкивания в стиле аськи. Но если нужно поддерживать у начальства уверенность в том, что не зря вбухали бабки в высокоскоростную сеть с дорогими свитчами и мощный сервак - что ж, можно и порефрешить.

АВП FreemanZAVНу вот опять. Если миллион записей вставляем, куда складывать параметры до комита и в какой форме давать параметры клиенту.


а сейчас где "миллион эвентов" лежит"? - шутка ;)


Гусары, молчать! В одном счётчике.

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


Иногда лучше жевать (С). Примерный код _строкового_ (а у нас других нет, но насчёт табличного тоже можно похихикать) триггера:



АВП
Есть же такие проверки при других операциях.


При каких, если не секрет? Имеется в виду изумление сервера на подзапросе, возвращающем курсор, в селекте? Разницы не осчусчаем?

АВП
Хотя я конечно не специалист по написанию серверов БД


Это заметно. Однако тут нужно просто быть специалистом сначала подумать, потом сказать, а не наоборот. Серп что-то совсем ржавчиной зарос, пора заточить да омыть красненьким.

Нафик-нафик. Всё на мои старческие плечи взвалить возжелал?