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

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

В настройках этого форума для каждого аккаунта хранятся такие параметры, как, например, количество сообщений за страницу темы и на страницу форума, отображение/скрытие разделов и протчая... в общем настройки того же порядка. 
Удобство интерфейса для конечного пользователя. И я лично считаю аксиомой, что требование удобства клиента для конечного пользователя, если он не специалист, а дефолтный юзер, носит статус "важное" и относится как раз к категории best practice. Привычность среды, отображения и пр. - обычный юзер есть существо крайне консервативное. Заодно минус головняк поддержке - "А где мои запросы?"... сервер от одной таблички с тремя полями и десятком записей на юзера не распухнет, зато отпадёт потребность гнать с клиента на сервер список ID-ов из его предыдущих запросов, достаточно будет заджойнить во вьюв эту таблицу.  Юзер - это определённый человек. А для сервера юзер - это аккаунт этого человека именно на сервере, а отнюдь не экземпляр клиента на рабстанции. А где юзер, там и его данные.


Это сообщение отредактировал(а) Akina - 28.4.2010, 09:13

Akina, если бы речь шла о php + mysql я бы вообще не ввязывался в дисскусию, тк. для меня было бы очевидно, что речь идет о тиражных решениях. Однако ТС упомянул об оракле+делфи. Этот инструментарий обычно выбирают для эксклюзивных решнеий. А в эксклюзивных решениях требования к эргономике обычно сильно оттеснены требованиями к масштабируемости и требованиям к цене/срокам реализации.

Но тут, таки не последнюю скрипку играют и  ограничения платформы. Если в связке php+mysql в принципе отсутствует возможность использования файловой системы или же реестра для хранения специфичной для клиента информации, то в связке оракл+делфи она есть. А переносимость пользовательского профиля на различные рабочие станции вполне себе обеспечивается средствами контролера домена винды и реализация этого механизма собственными силами - впустую потраченное время/деньги.

Это сообщение отредактировал(а) Zloxa - 28.4.2010, 09:55