Petro123База не пропустит одно поле Иван" сохранить.может тебе весь алгоритм по шагам рассказать?

Kachalov- проблемы в реализации отмены сохранения, когда пользователь нажмет такую кнопку, и в продолжении работы с того места на котором пользователь остановился после того как случайно перезагрузил свой комп. Проблемы эти решаемы, но не всегда нужно их решать)тут никакой проблемы нет - кнопка удалить запись. у меня юзер ввёл значение - и может перегружать комп хоть случайно , хоть специально - введённое сохранено, зашел на нужную форму - данные есть , не нужны - кнопка удалить.
KachalovЛогика взаимодействия клиентов с интерфейсом специфична для предметной области - кому то важно сохранить промежуточные значения до нажатия на кнопку "сохранить", кому то важно снизить нагрузку на БД и упростить алгоритмы.ну дак это не отменяет 3 вариант сохранения.
если надо можно сделать кнопку сохранить для кучи введённых значений . у меня кнопки сохранить нет за ненадобностью - юзер покинул поле - данные сохранились.
Petro123я УЖЕ тебе рассказал - в сессию.зачем городить что-то с сессией, когда можно просто сохранить введённое значение - это намного проще, и не надо отслеживать сессию.

Kachalov- подход который Вы описываете, характерен для толстого клиента, а Petro123, видимо имеет в виду web-приложениеа какая разница? у меня это реализовано на веб-страничке.

Petro123У тебя нет работодателя и форму твою с 30 полями никто не видел.своими высказываниями ты просто подтверждаешь своё не умение делать такое.
причём здесь "работодатель" и "никто не видел" ?
приведи аргументы почему такое невозможно сделать.
я говорю, что такое можно сделать, а когда применять - это уже дело конкретной ситуации.

maytonТы решаешь одну проблему за счет введения новой. Еще более комплексной.опиши в чём для тебя "ещё более комплексная проблема"
и в чем "одна проблема"?
для меня тут не существует проблем.

Leonid KudryavtsevДостаточно было всего лишь фразы "системы разные бывают. поэтому и варианты сохранения должны быть разные"ну раз поднялся шум - значит не всем достаточно такого.
насчёт соотношения 90/10 можно спорить.
но чем большим вариантов владеешь - тем лучше.

maytonЯ давно уже в форуме ничего никому не доказываю. Это бесполезно. Люди упрямы и делают по своему.я несколько дольше на форуме :)
я не прошу доказывать, я просто прошу объяснить какие есть проблемы. потому как я не вижу проблем.
может я что-то не понимаю?

mayton,
странный ты человек - тебя просят озвучить проблему - ты начинаешь вилять.
Petro123 говорит, что такое не возможно.
Basil A. SidorovМногие (такие) проблемы решаются миграцией на трёхзвенку,у ТС и есть трёхзвенка.
Basil A. Sidorovто изгаляться в базе уже не требуется - приняли весь пакет исходных данных и на СУБД поехало:что значит "изгаляться в базе" ? update одного поля - стандартная операция любой субд.
Basil A. SidorovСохранение промежуточного состояния ввода пользователя - отдельная задача, которая никак не связана с этой сАмой бизнес-логикой.что значит "отдельная операция" ?
а если в этой "бизнес-логике" есть необходимость на сохранение каждого ведённого значения?
я что должен сначала сохранить в серверном приложении в объекте, а потом только все введённые в базу?
у ТС задача сохранить много данных из файла - mysql это позволяет сделать без использования java (что за дополнительная обработка - ТС не говорит, но mysql позволяет достаточно хорошо обработать ) .

из-а чего наезд? из-за того что предложил 3 вариант сохранения?
чем он вам не понравился? не можете/не знаете как его реализовать?



maytonговоришь такие вещи которые
нельзя говорить на собеседовании.какие вещи? что нельзя сохранять по мере ввода? т.е. юзер должен сначала всё записать на бумажку, и только потом перенести всё сразу в форму - это правильно?
Basil A. Sidorovмиграцией на трёхзвенку, где несложно обеспечить достаточно надёжную работу сервера приложений.и у меня используется трёхзвенка - и все решается просто -внесли значение в поле , вышли из поля - значение ушло на сервер - сервер - отправил в базу.
что здесь сложного? то что не вписывается в вашу логику?

Basil A. SidorovНет такой задачи "обновить одно поле".я привел реальный пример, когда одна строка отображаемой у юзера таблицы заполняется в течении нескольких часов, и могут продолжаться на следующий день. производятся измерения и заносятся данные.
Basil A. SidorovА типичная задача бизнес-логики приводит к необходимости обновления отдельных полей многих таблиц.ты разницу понял? у "обновления отдельных полей" - есть частный случай - когда "отдельные поля" состоят из ОДНОГО поля.
Basil A. SidorovПример?у же приводил.
Basil A. SidorovА самое главное - насколько долго должно сохраняться "каждое введённое значение"?навсегда, потому что значение является результатом измерения образца продукции.
Basil A. SidorovНу нет реальной задачи "сохранять каждое нажатие пользователя".я такое не говорил, я говорил о значении каждого поля.

Basil A. Sidorovнеобходимости обновления отдельных полей многих таблиц.а что мешает при обновлении одного поля в одной таблице произвести обновления ещё в N связанных таблицах?

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

Basil A. SidorovВ трёхзвенке, чтобы данные были отображены у всех, не требуется работа с базой: сервер приложений получил данные одного рабочего места и разослал их на все остальные.конечно, только сервер приложений должен хранить все полученные данные.
зачем серверу приложений хранить у себя , когда можно сохранить б базе?

Basil A. SidorovСохранение введённого набора в базу - совершенно отдельная задача.а в этом есть проблема? и почему не совместить?

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

Petro123Почему без цитаты? ))))достаточно?
Petro123База не пропустит одно поле Иван" сохранить.