Всем доброе время суток.
Что-то ничего не нашел в сети по разработке приложений типа "клиент-сервер", если дадите ссылок, буду очень признателен.
А вопрос такой: есть некий документ, который реализуется в базе на нескольких таблицах (шапка документа, состав, дополнительные данные и т.д.)
Пользователь хочет в приложении либо открыть существующий документ для редактирования, либо создать новый. Как это реализовать в приложении:
1. Создавать похожую структуру таблиц, связей и т.д., но в памяти клиента-компьютера, т.е. структура документа будет реализована средставми языка программирования - массивы в памяти, структуры и т.д. Для того чтобы сохранить новый или отредактированный документ в базе - из памяти переносится в таблицы базы. Неудобство - чем сложнее документ, тем сложнее его реализовать в памяти: структуры, массивы, проверки и т.д. Но из плюсов - меньше нагрузка на сеть и сервер БД. Выше скорость работы, т.к. обрабатывать данные в памяти компьютера в любом случае быстрее, нежели в базе.
2. Открывать транзакцию в базе, пользователь будет работать с документом (редактировать содержимое, дополнять или удалять что-то). Все изменения фиксируются сразу же в базе. По завершению редактирования - или COMMIT, или ROLLBACK (смотря что выберет пользователь)
Наверное, правильнее все же второй вариант с точки зрения технологии. Но в реальности все так же?
Подскажите, пожалуйста, или дайте ссылок :)
Заранее большое спасибо

У меня сейчас именно вариант1. Т.е. структура документа в базе реализуется в памяти локального компьютера. Вся работа с документом - в памяти, т.е. все связи, зависимости, целостность данных. Но действительно, уж больно геморройно. Вопрос возник из-за того, что понадобилось очередное "усложнение" документа в памяти компьютера.
А почему вариант2 - никогда? Не зная все тонкостей (не хватает опыта разработки БД), удобнее было бы. Есть куча вопросов о поддержании целостности в данном случае.
Что Вы подразумеваете на отвязанных рекордсетах? Т.е. получить данные, хранить в рекордсетах, а потом - UpdateBatch всех рекордсетов?
Если так, то идея неплоха!!! Надо обдумать. Или я неправильно понял?

Клиент на VC++. Сейчас все сделано не на рекордсетах, а, скажем так, на массивах, списках и т.д.

Сахават ЮсифовНет никакой разницы. Даже лучше. Свобода.
Между чем и чем Вы имеете в виду "нет разницы"? Между этими двумя вариантами?

Понятно, я примерно так и понял про рекордсеты. Буду получать нужные данные в рекордсет, менять уже в нем, но с отложенным обновлением. Если пользователь выберет - "сохранить документ", тогда UpdateBatch для рекордсета. Мне удобнее будет часть документа в приложении сделать на рекордсете, а часть все же на массивах и структурах. Ну да ладно, это уже все понятно.
Насчет транзакций, я и писал, что открывать в базе, а не на клиенте:
Kezya2. Открывать транзакцию в базе , пользователь будет работать с
Самое первое сообщение.
Cat2 - большое Вам спасибо, подсказали вариант, о котором я не знал !!!

Если в рекордсете будут данные из нескольких таблиц, то для полного обновления одного рекордсета с использованием ХП - придется в цикле вызывать ХП для каждой записи в рекордсете. Что тоже не очень хорошо в плане производительности. А иначе - я что-то не понимаю с обновлением :(

LSVАфтару
Мазохизм - неизлечимая болезнь ИТ-отрасли.
Массивы, списки, транзакции, отвязанные рекодсеты...УЖАС ! Зачем ? Ради чего ? Что было основанием для такого решения ?
Этож надо так усложнять себе жизнь. Эту тему тут сто раз перетёрли.
С таким подходом Вам не поможет НИОДИН совет. Вы утонете в сложностях и глюках раньше, чем соберёте хотя бы альфа-версию.
Спорить не буду, знаний маловато. Я же попросил вначале - если есть ссылки, ткните носом. Если Вы подскажите варианты (решение, понятное дело, не надо), буду лично Вам очень признателен :)

TemplarВам надо взять заточенный для работы с БД инструмент типа Powerbuilder/Delphi/C++Builder/FoxPro/Access и поскорее (я бы добавил, бегОм) упростить программку, пока не поздно. Не нужно тратить время и силы для создания механизмов, которые были оформлены стандартом "де-факто" еще 10 лет назад. Клиент у меня на VC++, база MS SQL Server, доступ через ADO. Какие инструменты именно Вы имеете в виду? :(

basТак и спрашивайте в форуме по VC++ про доступ к БД как и что там, кто-что использует, да и почитать книжечку типа работа с БД из VC++, тут нет темы связанной с проектированием БД Тема была про технологию клиент-сервер, согласен, раздел не самый подходящий, но куда бы поместили такую тему Вы?
У меня уже есть и доступ и база. Мне не нужны советы про то, как это работает. Нужен был совет относительно реализации документа и всего лишь. Templar сказал, что есть специализированные инструменты, но пока ничего про них не написал. Но очень хотелось бы почитать. Т.к. написал он в этой теме, то и спросил про инструмент я здесь же.
LSV же предложил другой вариант - без транзакций, но это все же другой вариант, а не другой инструмент!!! Так что Ваш последний пост вобщем-то не понял к чему вообще относится.

LSVЕсли сервер будет строго MSSQL, то рекомендую:
Delphi (с компонентами SDAC, EhLib, FastReport).
Сможете сотворить чудеса за очень короткое время.

По теме:
Используйте свой пункт 2, но без транзакций. Вааще без транзакций. Если нужно отказаться от документа, то просто удаляйте его. И всего делов. Боитесь неизбежных пропусков в нумерации ? Если это очень критично, то помечайте документ как "для удаления" и его можно будет потом заюзать повторно.
ХРАНИТЕ ВСЁ СРАЗУ В БАЗЕ. Никаких отложенных коммитов.
Вы наверно интербазы на MSSQL перешли ? Не правда ли ?
Ща наверно услышу: "Вах...Ты знал !" (с)
У меня VC++, учить Delphi нет желания. Вот насчет отсутствия коммитов и отложенных обновлений стоит подумать. Только мазохизма в моих действиях особого не вижу. Два разных подхода, ну и что. В Вашем - тоже есть минусы, можем обсудить :)

LSV авторТолько мазохизма в моих действиях особого не вижу. Два разных подхода, ну и что.Вот это и плохо, что не видите. :)
Переусложнение чревато ужасными последствиями. Чем больше ненужных наворотов, тем меньше шансов проге стать нормальным продуктом. Это и есть самый главный минус, который может перечеркнуть ВСЁ.
Насчет переусложнения - полностью согласен. Надо найти баланс между излишним переусложнением и обеспечением нормальной работоспособности