Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
Собственно сабж. Сообщения типа "Неправильно выбрано то-то", естественно, с возможностью подставлять в эти сообщения свои данные (ну это уже клиентская часть решает). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 10:18 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
Как спроетируешь так и будет :) можно хранить и на клиенте в ресурсах например, можно на сервере (в справочниках) я например храню в таблице бд все сообщения на пользовательские исключения таблица двуязычная, язык выбирается в зависимости от настроек конкретного пользователя .... единственное из сообщений, что хранятся на клиенте - это сообщение о невозможности соединиться с базой ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 10:36 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
Канечна нужен ! Как патом узнаишь, аткуда какое саабщение выдаетса ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 10:49 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
olk...можно хранить и на клиенте в ресурсах например, можно на сервере (в справочниках) я например храню в таблице бд все сообщения на пользовательские исключения... Я храню в лог файлах. На каждого юзверя создается отдельный лог. Отказался от хранения в БД, чтоб ненароком сервер не уронить (пример: циклическая ошибка). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 11:02 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
Dik76 olk...можно хранить и на клиенте в ресурсах например, можно на сервере (в справочниках) я например храню в таблице бд все сообщения на пользовательские исключения... Я храню в лог файлах. На каждого юзверя создается отдельный лог. Отказался от хранения в БД, чтоб ненароком сервер не уронить (пример: циклическая ошибка). Нет я не то имел ввиду Пользователь что то например делает неправильно (нарушет например констрейн) и СУБД в тригере допустим делает raise_application_error - т.е. сообщение которое обрабатывается на клиенте вот текст этого сообщения я и храню в БД ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 11:06 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
olkНет я не то имел ввиду Пользователь что то например делает неправильно (нарушет например констрейн) и СУБД в тригере допустим делает raise_application_error - т.е. сообщение которое обрабатывается на клиенте вот текст этого сообщения я и храню в БДИ я про то же.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 11:19 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
Сдается мне, что вы не про одно и то же ;-) Что касается вопроса, отвечу: да, это будет хорошее решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 11:48 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
Я сначала тоже думал, что это хорошее решение. Но по мере роста количества сообщений получилось: чтобы добавить новое сообщение в этот справочник, нужно сначала искать, нет ли уже такого сообщения. Потом в клиентской части не разберешь сразу, откуда что берется. То есть наверное это хорошо, когда сообщений не больше сотни. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 12:06 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
MassiveЯ сначала тоже думал, что это хорошее решение. Но по мере роста количества сообщений получилось: чтобы добавить новое сообщение в этот справочник, нужно сначала искать, нет ли уже такого сообщения. Потом в клиентской части не разберешь сразу, откуда что берется. То есть наверное это хорошо, когда сообщений не больше сотни. а какая разница, если хранить на клиенте - что сразу разберешься ? в том же ресурсе или непосредственно в коде или в текстовом файле или еще где ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 12:53 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
У нас тоже сообщения в БД, так как проще найти сообщение в базе, чем в коде приложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 12:54 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
Все я въехал Сообщения тоже храню в БД. MassiveЯ сначала тоже думал, что это хорошее решение. Но по мере роста количества сообщений получилось: чтобы добавить новое сообщение в этот справочник, нужно сначала искать, нет ли уже такого сообщения. Потом в клиентской части не разберешь сразу, откуда что берется. То есть наверное это хорошо, когда сообщений не больше сотни. На оракле в эту таблицу закинул все стандартные русифицированные сообщения. Например: кодконстрейнт сообщение1 ORA-00001: нарушено ограничение уникальности (.)1 CHK_U_SS_NAME Подсистема с таким названием уже существует! Если возникает ошибка по констрейнту, то сначала ищется ошибка с именем констрейнта, если она не найдена, то выводится стандартная. Другими словами, пользователь всегда видит русифицированное сообщение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 13:16 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
а чтоб ручками не проверять есть ли уже сообщение, добавлен констайнт на таблицу ошибок: код+констрайнт UNIQUE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 13:18 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
Dik76 Если возникает ошибка по констрейнту, то сначала ищется ошибка с именем констрейнта, если она не найдена, то выводится стандартная. Другими словами, пользователь всегда видит русифицированное сообщение. Имхо - ты сделал прорву лишней работы ;) То есть в данном случае напрашивается "нормализация" - хранить информацию типа "констрейнт - название". Ну и дальше - вместо констрейнта использовать таблицу/поля, вместо названия - данные из комментариев. И подставлять в "рыбу" сообщения. Другой вопрос - возможность ошибки при формировании сообщения об ошибке :) Она существует всегда и должна быть предусмотрена. Предусмотреть можно на сервере - в соответствующей процедуре ловить exception-ы и выдавать, например, стандартное сообщение - либо на клиенте, куда заранее закачивать таблицу ошибок с сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 13:27 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
softwarer Имхо - ты сделал прорву лишней работы ;) То есть в данном случае напрашивается "нормализация" - хранить информацию типа "констрейнт - название". Ну и дальше - вместо констрейнта использовать таблицу/поля, вместо названия - данные из комментариев. И подставлять в "рыбу" сообщения. А можно подробнее, повнятнее.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 13:59 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
Но неужели все сообщения, касающиеся бизнес-логики приложения тоже надо запихивать в эту таблицу ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 14:51 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
MassiveНо неужели все сообщения, касающиеся бизнес-логики приложения тоже надо запихивать в эту таблицу ? Да кто же вам сказал и вообще делайте как вам удобнее кажеться, если бизнес логика на сервере - то вроде логичнее и сообщения держать там, если на мидле тире то можно хранить на апликейшен сервере ну и т.д. я вам даже скажу что у нас не только сообщения но и практически весь интерфейс лежит в репозитарии в бд ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 15:20 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
Dik76А можно подробнее, повнятнее.... Хм. Глядя на таблицу КонстрейнтСообщениеOBJECT1_UKОбъект1 уже существуетOBJECT2_UKОбъект2 уже существует......OBJECTN_UKОбъектN уже существует возникает желание ее нормализовать - выделить "рыбу" (коих может быть два-три варианта, если нужно - но, грубо, "%s уже существует") и оставить соотношение констрейнтов с именами объектов. Далее приходит в голову, что это соотношение можно выделить из dba_cons_columns и dba_col_comments - если, конечно, придерживаться соответствующей дисциплины при создании объектов. Собственно, вторая часть уже совершенно необязательна - вопрос в том, что я совершенно уверен в наличии в твоей таблице большого количества "почти одинаковых" сообщений. И минус в этом как и в любой денормализации - если для конкретного клиента потребуется поменять (ну не нравится ему такая формулировка) - придется делать какие-то странные, неочевидные update-ы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 18:04 |
|
||
|
Нужен ли в БД справочник сообщений пользователю ?
|
|||
|---|---|---|---|
|
#18+
>softwarer Ваша мысль понятна. Спасибо. На самом деле у меня тоже не все так страшно, как кажется. Стандартные сообщения об ошибках, как я уже и сказал, сидят в бд (закачиваются элементарно). А если юзверям не нравится формулировка, то адаптировать под проблему легко. Обработчик ошибок тоже свой и при появлении сообщения есть возможность скорректировать сообщение, т.е. мне не приходится ручками забивать код ошибки и имя констрейнта, а достаточно ввести сообщение, которое должно появляться. Само собой это может сделать только лицо наделенное правами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2004, 14:27 |
|
||
|
|

start [/forum/topic.php?fid=32&tid=1546179]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
133ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
| others: | 229ms |
| total: | 461ms |

| 0 / 0 |
