Dmitry V. LiseevПростой пример: оператор вводит в систему накладную на отгрузку товара. Накладная состоит из "шапки" (номер склада, дата, фамилия оператора и т.д.) и нескольких записей в табличной части (название товара, количество коробок и т.д.).Очевидно, что накладную в систему нужно ввести целиком за одну транзакцию.Я бы сказал, что Вы привели удивительно неудачный пример. Если Вы действительно предполагаете, что подобную структуру данных следует заполнять в одной транзакции в случае, если мы говорим об интерактивном вводе данных, то как вы представляете себе такого оператора, который не отрываясь вводит тысячи полторы-две позиций?

Dmitry V. Liseev Каким образом Вы предлагаете спроектировать данные, чтобы сделать это все за один SQL запрос?
Передергиваете, юноша. Процитирую Ваши слова повторно
Dmitry V. Liseev Даже прочитать нужные нам данные
одним запросом не получается.

Dmitry V. Liseev !!! Dmitry V. LiseevВообще, вопросы
изолирования транзакций и стратегии блокировок описаны
в специальной литературе.А про отложенные проверки целостности слыхали?Впервые слышу. Это как? Можно было бы просто отослать вас к RTFM, но, поскольку мы не обсуждаем достоинства и недостатки конкретных серверов БД, скажу только о том, что существуют СУБД, позволяющие отложить декларативную проверку целостности на конец транзакции.

Dmitry V. LiseevТут соседний магазин неделю торговал по ошибочным ценникам раза в полтора дешевле. Потом решили ценники проверить: "А мы понять не могли, откуда такой наплыв покупателей". Такой отложенной проверки целостности не надо, спасибо. В моей системе инженеры потом месяцами будут руками все разгребать и перепроверять. Если системе задан констрейн, то она должна его обеспечивать в реалтайме.И тут все наконец начинают понимать, что Вы пытаетесь проектировать системы с длинными транзакциями, а про то, что транзакции могут быть короткими, Вы вероятно не слышали. Пора в школу

Dmitry V. Liseev !!! Dmitry V. LiseevТо есть нужен
принцип "один пакет - одна транзакция". Аналогично,
было-бы хорошо, если бы все нужные для отображения данные
передавались бы с сервера на клиент также одним пакетом.Правильно, не пойму только, почему бы так и не поступить?В двухзвенке через ODBC? Именно в двухзвенке. Про ODBC Вы сами только что придумали.


Dmitry V. LiseevКаким образом? Пример задачи с вводом накладной за одну транзакцию я приводил. Как делать предлагаете?Очевидность использования в приведенном примере длинной транзакции очевидна только Вам. Никто не мешает оформить сохранение накладной в виде:
1. Сохранение заголовка
2. Сохранение порций строк между, введенных после предыдущего сохранения.
Транзакции при этом точечные и все надуманные Вами проблемы пропадают сами собой.


Dmitry V. Liseev !!! Dmitry V. LiseevА с другой стороны наш СП имеет толстый канал связи
с СУБД. Совсем физически независимая сеть, даже
отдельная сетевая карта, чтобы никто не мешал ему
как можно быстрее провести транзакцию.А если работать с сервером напрямую, через ХП, то никакой независимой сети вообще не нужно. Не говоря уж об отдельной сетевой карте Можно и без отдельной подсети. Только экономии на копейки, а масштабирование ухудшится весьма заметно.Так-так, ну ка, расскажите нам поподробнее о масштабировании, особенно в случае самописного сервера приложений, написанного на скриптовом языке, желательно в сравнении, скажем, с возможностями масштабирования Oracle 10g
Dmitry V. Liseev !!!Интересный подход. А если не отчет, то тоже может исправить в хорошо откомментированных исходниках ? А отвечают за это рукоблудие, насколько я понимаю, другие разработчики (см. ниже)Отвечает за рукоблудие тот, кто исправляет. То есть, системный администратор заказчика.Ага, т.е., Вы с себя всю ответственность за поддержку и развитие системы снимаете? Ну что ж, тоже вариант. Только, к сожалению, не наш.

Dmitry V. Liseev !!! Dmitry V. LiseevЕсли заказчик не может сам сделать отчет, то просит нас.Скорее, не "если", а "когда". Когда испортит все до такой степени, что исправить будет сложнее, чем написать все заново.Когда что-нибудь испортит, сервер приложений за пять минут можно переустановить с дистрибутивного диска.Измененный заказчиком функционал, обеспечивающий процессы заказчика у вас тоже на дистрибутиве?

Dmitry V. Liseev...тут лишнее скипнуто...
!!!Я только бумажку с красивыми и умными словами напишу, а что в результате получится - это не мои проблемы, для этого есть другие разработчики .Что получится в результате - как раз мои проблемы, ибо мне это потом годами сопровождать.Вы постоянно противоречите самому себе. То вы отдаете заказчику все в исходниках - правь-не хочу, то сначала заявляете, что заказчик не может написать ТЗ, но пишет требования. Вы уж определитесь сначала, какой именно линии собираетесь придерживаться в дискуссии

МетапрограммистЯзык интерпретатор должен быть таким, чтобы эту бизнес логику писать влет. Так чтобы в паре десятке строк можно было уместить нехилый отчетик. Открою Вам страшную тайну - такой язык уже есть. Более того, он довольно широко распространен и худо-бедно стандартизирован - это Язык Структурированных Запросов. Ну и интерпретаторы этого языка тоже имеют место быть - про СУБД, надеюсь, слыхали?