Рискну спросить...

Имеется в наличии довольно большая база данных в билдере, при этом очень активно использованы элементы закладки DataContlols.
В этом есть свои плюсы, но как выяснилось минусов тоже достаточно.
Просто база сначала планировалась однопользовательской, а терь плавно переходит в много....

Возник вопрос, а не лучше ли было использовать обычные элементы, заполняя их при открытии, и записывая при нажатии на ок?

Здравствуйте, Ptaha, Вы писали:

P>Возник вопрос, а не лучше ли было использовать обычные элементы, заполняя их при открытии, и записывая при нажатии на ок?

Хм. Ну если решительно нечем занять время — можно, конечно, и так. Но кроме этого — ничем не лучше, исключительно наоборот.

Здравствуйте, Softwarer, Вы писали:

S>Хм. Ну если решительно нечем занять время — можно, конечно, и так. Но кроме этого — ничем не лучше, исключительно наоборот.

Может я что-нить делаю не так?
у меня MDI-приложение..Необходимо дать возможность пользователю открывать несколько окон одновременно, но при этом нужно время от времени обновлять инфу из базы (если были заполнены другие, вспомогательные таблицы, из которых данные попадают в LookUp-элементы). Поэтому, при активации формы запрос переактивируется, и следовательно если были внесены изменения, но не сохранены, то они теряются. Сохранять запись каждый раз при потере фокуса — совсем плохо.

модель ситуации: пользователь заполняет документ (1-я форма), в это время вспоминает, что ему нужно заполнить справочник (2-я форма), причем данные из этого справочника должны попасть в 1-ю форму. Он открывает соответственно справочник...

Здравствуйте, Ptaha, Вы писали:

P>у меня MDI-приложение..Необходимо дать возможность пользователю открывать несколько окон одновременно, но при этом нужно время от времени обновлять инфу из базы (если были заполнены другие, вспомогательные таблицы, из которых данные попадают в LookUp-элементы).

А что за лукап-элементы? Вообще говоря, я бы не советовал пользоваться lookup-полями; для небольших приложений они применимы, но лучше не приобретать вредную привычку

Лично я предпочитаю запрашивать данные справочника в тот момент, когда пользователь собственно и начинает выбор из справочника. Кэшировать справочник на клиенте — в принципе можно; принципиальных проблем для этого тоже не вижу; на худой конец, если это будет самым простым, можно воспользоваться ClientDataSet-ом.

P> Поэтому, при активации формы запрос переактивируется,

Какой? Если датасет "основных данных" — мягко говоря, непонятно зачем. Если какой-то лукаповский — хм, во-первых см. выше, во-вторых, если вдруг изменения в лукаповском запросе передергивают основной (что очень странно), значит, надо вставить между ними какой-нибудь буфер, опять же любой ClientDataSet, MemTable итп.

P> и следовательно если были внесены изменения, но не сохранены, то они теряются. Сохранять запись каждый раз при потере фокуса — совсем плохо.

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

P>модель ситуации: пользователь заполняет документ (1-я форма), в это время вспоминает, что ему нужно заполнить справочник (2-я форма), причем данные из этого справочника должны попасть в 1-ю форму. Он открывает соответственно справочник...

В том подходе, который предпочитаю я, он открывает справочник, вставляет редактирует данные, и когда жмет наконец Enter — данные вставляются в базу, а кроме того возвращаются в первую форму. Та, соответственно, заполняет поля своего датасета (включая псевдолукаповские). Впрочем, это не единственный подход.

Здравствуйте, Softwarer, Вы писали:

S>А что за лукап-элементы? Вообще говоря, я бы не советовал пользоваться lookup-полями; для небольших приложений они применимы, но лучше не приобретать вредную привычку

S>Лично я предпочитаю запрашивать данные справочника в тот момент, когда пользователь собственно и начинает выбор из справочника. Кэшировать справочник на клиенте — в принципе можно; принципиальных проблем для этого тоже не вижу; на худой конец, если это будет самым простым, можно воспользоваться ClientDataSet-ом.

DBLookupComboBox в основном.. Приходится конектится сразу, так как некоторые данные проставляются по умолчанию

P>> Поэтому, при активации формы запрос переактивируется,
S>Какой? Если датасет "основных данных" — мягко говоря, непонятно зачем. Если какой-то лукаповский — хм, во-первых см. выше, во-вторых, если вдруг изменения в лукаповском запросе передергивают основной (что очень странно), значит, надо вставить между ними какой-нибудь буфер, опять же любой ClientDataSet, MemTable итп.

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

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

P>>модель ситуации: пользователь заполняет документ (1-я форма), в это время вспоминает, что ему нужно заполнить справочник (2-я форма), причем данные из этого справочника должны попасть в 1-ю форму. Он открывает соответственно справочник...
S>В том подходе, который предпочитаю я, он открывает справочник, вставляет редактирует данные, и когда жмет наконец Enter — данные вставляются в базу, а кроме того возвращаются в первую форму. Та, соответственно, заполняет поля своего датасета (включая псевдолукаповские). Впрочем, это не единственный подход.
опять таки может быть длинная цепочка

Здравствуйте, Ptaha,

Не делай отдельных DataSet'ов для lookup источников данных. Используй одни и те же.

Здравствуйте, Ptaha, Вы писали:

P>все правильно, просто может быть длинная цепочка открытия из-под одних форм другими, и по этому хотелось написать нечто универсальное. отсюда — переконект всего

Хм. Не вижу логики в этом "отсюда" Кроме того, мне кажется это ответ не совсем на то, что я говорил и спрашивал.

"Всего" — это чего именно всего? Всех датасетов, которые вообще есть в приложении?

P>неудобно пользователю

Хм. Просто я вряд ли мог предусмотреть, что Вы используете этот механизм для общения объектов внутри приложения. Я полагал, обновление запускается для учета изменений, сделанных другими пользователями.

P>опять таки может быть длинная цепочка

И что из этого? Длинная цепочка правильно работающих элементов, каждый из которых знает свой интерфейс. Идеальный подход с точки зрения общей теории.

Хм. Задекларирую одно утверждение: при правильно выстроенных взаимодействиях (что есть ключевая задача проектирования) количество взаимодействующих элементов не играет роли; если правильно взаимодействуют каждые два элемента в цепочке, правильно работать будет цепочка любой длины.

Здравствуйте, Softwarer, Вы писали:

P>>опять таки может быть длинная цепочка

S>И что из этого? Длинная цепочка правильно работающих элементов, каждый из которых знает свой интерфейс. Идеальный подход с точки зрения общей теории.

S>Хм. Задекларирую одно утверждение: при правильно выстроенных взаимодействиях (что есть ключевая задача проектирования) количество взаимодействующих элементов не играет роли; если правильно взаимодействуют каждые два элемента в цепочке, правильно работать будет цепочка любой длины.

Пришло на ум одно извратное решение:
— Форма самого нижнего уровня при завершении редактирование шлет через PostMessage() сообщение, на которое реагирует самая верхняя форма (Application.MainForm например)
— MainForm дергает все открытые формы более нижнего уровня на предмет выполнения RefreshData();

Здравствуйте, DarkMaster, Вы писали:

DM>Пришло на ум одно извратное решение:

Можно менее извращенно. http://softwarer.ru/Describe/describe_stsnotifier.html

Здравствуйте, Softwarer, Вы писали:

P>>все правильно, просто может быть длинная цепочка открытия из-под одних форм другими, и по этому хотелось написать нечто универсальное. отсюда — переконект всего
S>Хм. Не вижу логики в этом "отсюда" Кроме того, мне кажется это ответ не совсем на то, что я говорил и спрашивал.

S>"Всего" — это чего именно всего? Всех датасетов, которые вообще есть в приложении?
не, ток тех, которые есть на форме

P>>неудобно пользователю
S>Хм. Просто я вряд ли мог предусмотреть, что Вы используете этот механизм для общения объектов внутри приложения. Я полагал, обновление запускается для учета изменений, сделанных другими пользователями.


P>>опять таки может быть длинная цепочка
S>И что из этого? Длинная цепочка правильно работающих элементов, каждый из которых знает свой интерфейс. Идеальный подход с точки зрения общей теории.

S>Хм. Задекларирую одно утверждение: при правильно выстроенных взаимодействиях (что есть ключевая задача проектирования) количество взаимодействующих элементов не играет роли; если правильно взаимодействуют каждые два элемента в цепочке, правильно работать будет цепочка любой длины.

ясно.. прийдется повозится.. я просто думала что проще будет при входе — заполнить форму из запроса в обычные элементы (в смысле не связанные с БД), а по нажатию ок — записать..
но если это концептуально не правильно... будем возится
Спасибо

Здравствуйте, Ptaha, Вы писали:

S>>"Всего" — это чего именно всего? Всех датасетов, которые вообще есть в приложении?
P>не, ток тех, которые есть на форме

То есть: сначала Вы размахиваетесь кувалдой, а потом боретесь с тем, что под удар попало что-то лишнее. Может быть действовать более избирательно?

P>ясно.. прийдется повозится.. я просто думала что проще будет при входе — заполнить форму из запроса в обычные элементы (в смысле не связанные с БД), а по нажатию ок — записать..
P>но если это концептуально не правильно... будем возится

Это не то что концептуально неправильно; на самом деле DBControl-ы внутри себя именно это и делают Это просто большое количество абсолютно тупой и чреватой ошибками работы. Кроме того, как и любой неосмысленный код, такое решение снижает качество программного решения (программа становится менее удобной для понимания, более дорогой в сопровождении и т. д.) Ну и наконец, это отсекает большое количество dbaware-решений, для которых нет "нормальных" аналогов.

Также я бы указал на очень опасную тенденцию: Вы принимаете одно неудачное решение (дергать все подряд), натыкаетесь на связанную с ним проблему, и вместо того, чтобы скорректировать подход, заново оценить ситуацию в целом — принимаете другое, еще более неудачное решение, следующее из постулата о непогрешимости первого. В результате такой практики программа очень быстро превратится в огромную и сложную конструкцию из костылей, занятых в основном поддержкой друг друга. При любой попытке доработки такая программа будет рассыпаться как карточный домик.

Здравствуйте, Ptaha, Вы писали:

P>Здравствуйте, Softwarer, Вы писали:

S>>Хм. Ну если решительно нечем занять время — можно, конечно, и так. Но кроме этого — ничем не лучше, исключительно наоборот.

P>Может я что-нить делаю не так?
P>у меня MDI-приложение..Необходимо дать возможность пользователю открывать несколько окон одновременно, но при этом нужно время от времени обновлять инфу из базы (если были заполнены другие, вспомогательные таблицы, из которых данные попадают в LookUp-элементы). Поэтому, при активации формы запрос переактивируется, и следовательно если были внесены изменения, но не сохранены, то они теряются. Сохранять запись каждый раз при потере фокуса — совсем плохо.

P>модель ситуации: пользователь заполняет документ (1-я форма), в это время вспоминает, что ему нужно заполнить справочник (2-я форма), причем данные из этого справочника должны попасть в 1-ю форму. Он открывает соответственно справочник...

Лучше использовать простые контролы типа TComboBox и прочее и заполнять на открытии. И придумать систему сообщений (как простых, так и сетевых), а при изменении инфы в другом окне — посылать сообщение что, мол, "изменена запись №2 в справочнике №3", а на формах, где элементы из справочника №3 используются, ловить события об изменении или добавлении этих записей и изменять только ту часть что изменилась.
Сумбурно объяснил, но, надеюсь, понятно (:

S>Это не то что концептуально неправильно; на самом деле DBControl-ы внутри себя именно это и делают Это просто большое количество абсолютно тупой и чреватой ошибками работы. Кроме того, как и любой неосмысленный код, такое решение снижает качество программного решения (программа становится менее удобной для понимания, более дорогой в сопровождении и т. д.) Ну и наконец, это отсекает большое количество dbaware-решений, для которых нет "нормальных" аналогов.

S>Также я бы указал на очень опасную тенденцию: Вы принимаете одно неудачное решение (дергать все подряд), натыкаетесь на связанную с ним проблему, и вместо того, чтобы скорректировать подход, заново оценить ситуацию в целом — принимаете другое, еще более неудачное решение, следующее из постулата о непогрешимости первого. В результате такой практики программа очень быстро превратится в огромную и сложную конструкцию из костылей, занятых в основном поддержкой друг друга. При любой попытке доработки такая программа будет рассыпаться как карточный домик.

убили.. наповал.. я в общем по этому и решила заподозрила, что делаю что-то не то
спасибо за разяснение

Здравствуйте, .silent, Вы писали:

S>Сумбурно объяснил, но, надеюсь, понятно (:
спасибо, понятно.. система сообщений, эт конечно весчь нужная, особенно если продуманная

Тогда искну задать еще один вопрос, в связи со всем предыдущим..

у меня в проге несколько дата-модулей, где располагаются компоненты TIBDataBase, TibTransaction, TIBDataSet, TDataSource.
TIBDataSet, TDataSource, расположенные на формах подключаются соответственно к базам и транзакциям в дата-модулях
Не следует ли для каждой формы сделать свою транзакцию

P>Тогда искну задать еще один вопрос, в связи со всем предыдущим..

P>у меня в проге несколько дата-модулей, где располагаются компоненты TIBDataBase, TibTransaction, TIBDataSet, TDataSource, TIBDataSet, TDataSource, расположенные на формах подключаются соответственно к базам и транзакциям в дата-модулях Не следует ли для каждой формы сделать свою транзакцию

Ну, это зависит от БД.
Например, для MS SQL Server и вообще всех "блокировщиков" — однозначно не следует. Потому что транзакции из разных форм могут заблокировать друг друга. Транзакций должно быть мало — вообще, как можно меньше.

А для Oracle (или другого "версионника")? Ну, вероятно эффект будет не так заметен... Не знаю.

Здравствуйте, Ptaha, Вы писали:

P>Не следует ли для каждой формы сделать свою транзакцию

Это больше зависит от постановки задачи. В принципе это нормальный подход, и задачи работы с документами часто делают именно так.

Здравствуйте, Arsu, Вы писали:

P>>Тогда искну задать еще один вопрос, в связи со всем предыдущим..

P>>у меня в проге несколько дата-модулей, где располагаются компоненты TIBDataBase, TibTransaction, TIBDataSet, TDataSource, TIBDataSet, TDataSource,
A>А для Oracle (или другого "версионника")? Ну, вероятно эффект будет не так заметен... Не знаю.

компоненты TIBDataBase, TibTransaction, для Oracle???
не, у нас Interbase.
а про заблокировать.эт конечно прийдется пересматривать отдельно
но если транзакция будет находится только в дада-модуле, то может быть такая ситуация:
открыты 2 записи одной таблицы в 2-х разных формах.. после этого одна запись корректируется и сохраняется, а вторая — не получает об этом никакой информации, без переактивации запроса.. а насчет переактивации основного запроса к форме уже было выше..

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, Ptaha, Вы писали:

P>>Не следует ли для каждой формы сделать свою транзакцию

S>Это больше зависит от постановки задачи. В принципе это нормальный подход, и задачи работы с документами часто делают именно так.

спасибо, очень помогли

P>>>Тогда искну задать еще один вопрос, в связи со всем предыдущим..

P>>>у меня в проге несколько дата-модулей, где располагаются компоненты TIBDataBase, TibTransaction, TIBDataSet, TDataSource, TIBDataSet, TDataSource,
A>>А для Oracle (или другого "версионника")? Ну, вероятно эффект будет не так заметен... Не знаю.

P>компоненты TIBDataBase, TibTransaction, для Oracle???
P>не, у нас Interbase.

Ой, и правда

P>а про заблокировать.эт конечно прийдется пересматривать отдельно
P>но если транзакция будет находится только в дада-модуле, то может быть такая ситуация:
P>открыты 2 записи одной таблицы в 2-х разных формах.. после этого одна запись корректируется и сохраняется, а вторая — не получает об этом никакой информации, без переактивации запроса.. а насчет переактивации основного запроса к форме уже было выше...

Я слышал краем уха, что для внесения изменений в БД принято использовать 2 метода — "оптимистическая блокировка" и "пессимистическая блокировка". Пессимистическая — это когда эксклюзивно блокируют ресурсы в самом начале редактирования, и, следовательно, параллельно редактировать одно и то же просто невозможно. Оптимистическая — это когда ресурсы блокируются в момент сохранения изменений — это, конечно, повышает параллельность и масштабируемость и всё такое, но есть проблема, которую ты указала (я правильно пол уловил? если нет, то заранее прощу прощения...) — надо поставлять обновления после сохранения и ловить попытки затереть сохранённое новое — старыми данными.

Я так понял, что ты используешь именно оптимистическую блокировку. Однако тут тоже есть два подхода — начинать транзакцию в момент начала редактирования или же начинать её при сохранении.

В первом случае — если второй человек попытается сохранить изменения поверх уже сохранённых, то БД ему скажет — гуд-бай, парниша, у тебя старые данные. И все его изменения будут утеряны (в БД не сохранятся).
Во втором случае — если второй человек попытается сохранить изменения поверх уже сохранённых, то всё будет ОК. Но будут потеряны данные первого юзера.

Первый вывод. Если ты используешь TDBEdit'ы и т.п. в том же духе — то есть компоненты прямого доступа в БД, то ты при наложении изменений — теряешь данные (или первого юзера, или второго).
Второй вывод. Если используешь оптимистичекую блокировку, то конфликты надо регулировать. Ручками чаще всего.

Куда определить транзакции — это, конечно, вопрос. Однако хочу заметить, что ты будешь создавать по транзакции на окно, то это не решит проблему потери данных. А если это не решает проблем, то зачем это делать?

Проблема, мне кажется, именно в этом — как обрабатывать конфликты при сохранении изменений.

Мне лично кажется логичным, если эти конфликты будет решать нечто в единственном экземпляре — соответственно, и транзакция у этого "нечто" может быть всего одна — так и так он всех в очередь построит.

Здравствуйте, Arsu, Вы писали:

A>Оптимистическая — это когда ресурсы блокируются в момент сохранения изменений — это, конечно, повышает параллельность и масштабируемость

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

Концептуально же параллельность повышается только для варианта "один человек редактирует левую половину записи, другой — правую половину записи", что, назовем так, довольно сомнительный подход.

A>Первый вывод. Если ты используешь TDBEdit'ы и т.п. в том же духе — то есть компоненты прямого доступа в БД, то ты при наложении изменений — теряешь данные (или первого юзера, или второго).

Вывод неправильный (c) полковник Петренко.

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

A>Второй вывод. Если используешь оптимистичекую блокировку, то конфликты надо регулировать. Ручками чаще всего.

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

A>Куда определить транзакции — это, конечно, вопрос. Однако хочу заметить, что ты будешь создавать по транзакции на окно, то это не решит проблему потери данных. А если это не решает проблем, то зачем это делать?

Брр. "Вывод неверный".

Основное и даже единственное, что решают несколько транзакций — возможность независимого редактирования в немодальном интерфейсе. Например, если началось редактирование документа, потом была вставлена запись в справочник, потом пользователь отказался от сохранения документа — запись справочника сохранится, а не потеряется при rollback-е документа. Тем более это актуально, когда возможно параллельно редактировать несколько документов.

A>Проблема, мне кажется, именно в этом — как обрабатывать конфликты при сохранении изменений.

Гораздо удобнее их не допускать.

A>Мне лично кажется логичным, если эти конфликты будет решать нечто в единственном экземпляре — соответственно, и транзакция у этого "нечто" может быть всего одна — так и так он всех в очередь построит.

Хм....... Ничего не понял.

A>>Оптимистическая — это когда ресурсы блокируются в момент сохранения изменений — это, конечно, повышает параллельность и масштабируемость

S>Оптимистическая блокировка в общем случае не то чтобы заметно повышает параллельность и масштабируемость. Просто другой подход легко может убить блокировочник

Ну почему же. У меня сейчас на работе — старая система на Informix, которая работает на пессимистических блокировках. И замечательно работает (блокировки, правда, время от рвемени админы ручками удаляют. ну дык это ни на стабильность, ни на скорость не влияет — только на удобство пользования).

S>Концептуально же параллельность повышается только для варианта "один человек редактирует левую половину записи, другой — правую половину записи", что, назовем так, довольно сомнительный подход.

Опять же не согласен
На форме для редактирования какого-нить документа могут быть данные из десятков полей. Так вот один юзер меняет одно поле, другой (в то же самое время) — другое (повезло, замечу в скобках, но тем не менее)

A>>Первый вывод. Если ты используешь TDBEdit'ы и т.п. в том же духе — то есть компоненты прямого доступа в БД, то ты при наложении изменений — теряешь данные (или первого юзера, или второго).

S>Вывод неправильный (c) полковник Петренко.
S>Данные можно потерять исключительно из-за кривых рук, а не из-за используемой технологии блокировки.

Да. Думать всегда полезно.

A>>Второй вывод. Если используешь оптимистичекую блокировку, то конфликты надо регулировать. Ручками чаще всего.

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

Хочу напомнить, что мы говорить про блокировщик.

A>>Куда определить транзакции — это, конечно, вопрос. Однако хочу заметить, что ты будешь создавать по транзакции на окно, то это не решит проблему потери данных. А если это не решает проблем, то зачем это делать?

S>Брр. "Вывод неверный".
S>Основное и даже единственное, что решают несколько транзакций — возможность независимого редактирования в немодальном интерфейсе. Например, если началось редактирование документа, потом была вставлена запись в справочник, потом пользователь отказался от сохранения документа — запись справочника сохранится, а не потеряется при rollback-е документа. Тем более это актуально, когда возможно параллельно редактировать несколько документов.

Желание автора топика сделать по транзакции на окно я понял так — перейти от формализма "транзакция на бизнес-процесс" к формализму "транзакция на окно". Мне кажетя, такой переход не стоит усилий (я лично всегда в обратную сторону перехожу )

A>>Проблема, мне кажется, именно в этом — как обрабатывать конфликты при сохранении изменений.

S>Гораздо удобнее их не допускать.

Полностью согласен.

A>>Мне лично кажется логичным, если эти конфликты будет решать нечто в единственном экземпляре — соответственно, и транзакция у этого "нечто" может быть всего одна — так и так он всех в очередь построит.

S>Хм....... Ничего не понял.

Ну, значит, это был гон

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, Arsu, Вы писали:

A>>Оптимистическая — это когда ресурсы блокируются в момент сохранения изменений — это, конечно, повышает параллельность и масштабируемость
S>Оптимистическая блокировка в общем случае не то чтобы заметно повышает параллельность и масштабируемость. Просто другой подход легко может убить блокировочник
S>Концептуально же параллельность повышается только для варианта "один человек редактирует левую половину записи, другой — правую половину записи", что, назовем так, довольно сомнительный подход.

угу, просто вопрос о блокировке тож еще не решен.. пожалуй будет пессимистическая

A>>Первый вывод. Если ты используешь TDBEdit'ы и т.п. в том же духе — то есть компоненты прямого доступа в БД, то ты при наложении изменений — теряешь данные (или первого юзера, или второго).
S>Вывод неправильный (c) полковник Петренко.
S>Данные можно потерять исключительно из-за кривых рук, а не из-за используемой технологии блокировки.

Да ладно вам, тормоз — тоже человек

S>Основное и даже единственное, что решают несколько транзакций — возможность независимого редактирования в немодальном интерфейсе. Например, если началось редактирование документа, потом была вставлена запись в справочник, потом пользователь отказался от сохранения документа — запись справочника сохранится, а не потеряется при rollback-е документа. Тем более это актуально, когда возможно параллельно редактировать несколько документов.
угу, особенно если к таблице Person- есть подчиненная — PhonesOfPeron

A>>Проблема, мне кажется, именно в этом — как обрабатывать конфликты при сохранении изменений.
S>Гораздо удобнее их не допускать.

Здравствуйте, Arsu, Вы писали:

S>>Оптимистическая блокировка в общем случае не то чтобы заметно повышает параллельность и масштабируемость. Просто другой подход легко может убить блокировочник
A>Ну почему же. У меня сейчас на работе — старая система на Informix, которая работает на пессимистических блокировках. И замечательно работает (блокировки, правда, время от рвемени

Не совсем понял, на что именно Вы возражаете Преимуществ оптимистической блокировки это не показывает. С тем, что аккуратно используя пессимистическую блокировку, можно и не убить блокировочник, я нисколько не спорю.

A>Опять же не согласен
A>На форме для редактирования какого-нить документа могут быть данные из десятков полей. Так вот один юзер меняет одно поле, другой (в то же самое время) — другое (повезло, замечу в скобках, но тем не менее)

В первую очередь это означает либо странный дизайн базы, либо странный бизнес-процесс, а весьма вероятно и то, и другое (почему я и назвал этот подход сомнительным).

С чем Вы не согласны, я опять же не понял, с учетом того, что сказали Вы то же самое, что и я.

Наконец, обращу Ваше внимание на слово "заметно". Прикиньте вероятность такого совпадения — и, собственно,...

A>Хочу напомнить, что мы говорить про блокировщик.

Хм. Хочу напомнить, что вопрос был задан про Interbase; что касается моего ответа, то он не зависит от сервера. Я только упомянул, что лично не проверял свое предположение, поскольку не было нужны делать оптимистическую блокировку.

Здравствуйте, Ptaha, Вы писали:

P>угу, особенно если к таблице Person- есть подчиненная — PhonesOfPeron

C точки зрения редактирования подчиненных данных в отдельной транзакции есть один технический вопрос — нужно будет ввести понятие "подчиненной транзакции", для того, чтобы нельзя было закоммитить деталь при вставляемом но незакоммиченном мастере. Впрочем, я не вижу в таком подходе особого смысла; есть понятие "бизнес-объекта", и как бы они ни были выделены, логично редактировать объект целиком (в одной транзакции), а не по частям. В то же время вполне возможно одновременное редактирование либо независимых бизнес-объектов (тех же нескольких документов), либо зависимых (тех же записей в справочниках).