Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
23.09.2006, 22:27
|
|||
|---|---|---|---|
|
|||
GUI и целостность данных в БД |
|||
|
#18+
Всем доброго времени суток! Не уверен, что нужно было размещать вопрос в этом разделе... Ну да ладно, модераторы, в случае чего, подправят :) Ситуация следующая - есть нормально спроектированная БД. Например при попытке удаления записи мы получаем следующее сообщение от сервера БД: violation on FOREIGN KEY constraint "FK_BUILDING_1" on table "BUILDING". Вполне красивое и понятное сообщение. Для программиста или DB-админа. И возникает такой вопрос: как для конечного пользователя показать вразумительное сообщение на русском языке о попытке нарушения целостности данных в БД? Кто как решает эту проблему? P.S.: Просьба не советовать сделать проверку целостности данных на триггерах с нормальными exceptions на русском языке. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.09.2006, 22:38
|
|||
|---|---|---|---|
|
|||
GUI и целостность данных в БД |
|||
|
#18+
Кстати, чуть не забыл, естественно сообщение в клиентской программе, а не в администраторе базы данных... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.09.2006, 22:41
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
на клиенте или на сервере приложений перехват эксепшинов и их трансляция в "понятные" сообщения. СУБД-зависимо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.09.2006, 00:35
|
|||
|---|---|---|---|
|
|||
GUI и целостность данных в БД |
|||
|
#18+
Так это же кошмар получается! Для каждого варианта exception нужно создать строку-дубликат для сверки. Красивей решения ни у кого нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.09.2006, 00:56
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
Сергей ФроловТак это же кошмар получается! Для каждого варианта exception нужно создать строку-дубликат для сверки. Красивей решения ни у кого нет? Сергей, Вы не поняли. Это не "дубликат", как Вы изволили выразиться. Это обработка особых ситуаций, которая обязана иметь место быть в приложении. В чем разница? Попробую объяснить. - Сообщение для пользователя должно не просто быть переводом сообщения об ошибке на родной язык. Оно должно диагностировать ситуацию с точки зрения и в терминах предметной области. Например, пользователь заводит накладную и в процессе выяснилось, что в прайс-листе нет цены для какой-то из позиций. Сообщение должно так и выглядеть: "В ПРАЙС-ЛИСТЕ отсутствует цена для товара 'хомячок'". А не системное "no data found", перепертое на родной язык. Другой пример: регистрируем номерной документ. "violation on FOREIGN KEY constraint "FK_DOC_1" on table "DOC"" после обработки должно превратиться не в "нарушение целостности внешнего ключа FK_DOC_1 в таблице DOC", но в "документ с данным номером уже зарегистрирован в системе. Открыть существующий документ?" Т.е. это ни в коем разе не тупое дублирование - тот же violation on FOREIGN KEY в зависимости от контекста может быть как фатальной системной ошибкой, так и рабочей веткой бизнес-процесса. При этом хочу отметить еще одно важное свойство системы обработки ошибок: если в нее попадает непредусмотренный в даном месте exception, то его ни в коем случае нельзя "потерять". Скорее, надо показать что-то вроде "Произошла серьезная ошибка. Скопируйте следующую информацию и передайте сотруднику тех. поддержки: - Операция: - Модуль: - Входные параметры: - Строка кода: - Код ошибки: - Текст сообщения об ошибке:" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.09.2006, 01:08
|
|||
|---|---|---|---|
|
|||
GUI и целостность данных в БД |
|||
|
#18+
2 contr: Спасибо за столь подробное объяснение. Но видимо вы меня не совсем поняли. Вопрос несколько в другом: я перехватил exception (в данном конкретном случае у меня IBX и Firebird 1.5). Если посмотреть исходник ib.pas, то можно увидеть следующее: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Вот у меня и возникает вопрос: единственным вариантом будет создание что-то вроде массива сообщений в зависимости от SQLCode и IBErrorCode? Если это единственный вариант, то вопрос отпадает сам собой. Я думал может у кого-то есть более красивые решения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.09.2006, 12:32
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
Сергей ФроловВот у меня и возникает вопрос: единственным вариантом будет создание что-то вроде массива сообщений в зависимости от SQLCode и IBErrorCode? Если это единственный вариант, то вопрос отпадает сам собой. Я думал может у кого-то есть более красивые решения. Ну да. Только все коды транслировать не обязательно, только значимые для пользователя. На остальные штатный текст, типа "Произошла ошибка...и т.п." + нормальный диалог, который не ущемляет и разработчика с кнопкой Подробно, при нажатии на которую показывается панель с оригинальным текстом. Панель Подробно по умолчанию скрыта. Все будет нормально.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.09.2006, 13:55
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
iscrafm Сергей ФроловВот у меня и возникает вопрос: единственным вариантом будет создание что-то вроде массива сообщений в зависимости от SQLCode и IBErrorCode? Если это единственный вариант, то вопрос отпадает сам собой. Я думал может у кого-то есть более красивые решения. Ну да. Только все коды транслировать не обязательно, только значимые для пользователя. На остальные штатный текст, типа "Произошла ошибка...и т.п." + нормальный диалог, который не ущемляет и разработчика с кнопкой Подробно, при нажатии на которую показывается панель с оригинальным текстом. Панель Подробно по умолчанию скрыта. Все будет нормально.. +1 Я бы сказал проще - нужно отделять аварийные, по сути - нерегламентированные и необрабатываемые и непредусмотренные по умолчанию ошибки, от штатных и понятных пользователю. Говоря проще - отделить сообщения: "Вы не можете удалить договор, потому как по нему выполнены финаносвые операции" (которые, по сути, и есть бизнес правила), от "особо ценных" сообщений со смысловой нагрузкой вида: "Извините, ошибка бла-бла-бла, впрочем, х.з., т.к. разработчик оказался халтурщиком, впрочем, в чем проблема - думайте сами, если что". При этом - т.к. пользователи к этому бла-бла-бла привыкают, а изобретательность их - не имеет границ, а т.к. отделить халтуру от сбоя системы пользователь не может, то последствия разрушения данных - чаще могут и не иметь границ (себе дороже - потом приводить данные в чувство). ------ Практически же решение вопроса выглядит примерно так: заводится своя таблица/список регламентированных сообщений системы. Все мыслимые случаи действий пользователя предусматриваются, кодируются (через явные проверки, иногда - через обработчики стандартных ошибок - по сути, реализуются именно бизнес правила). Все что не прошло через блоки бизнес правил - халтура разработчика и по возможности должна быть отслежена и устранена (мы поощряеем пользователей отправлять ошибки стандартных экранов экспешинов по почте, с приаттачеными стек трейсами, логами и описаниями юзкейса (последовательности операций, которые привели к проблеме). И это, я считаю - нормально (т.к. системы пишутся - для человеков, а не роботов). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 12:48
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
Сергей ФроловВот у меня и возникает вопрос: единственным вариантом будет создание что-то вроде массива сообщений в зависимости от SQLCode и IBErrorCode? Если это единственный вариант, то вопрос отпадает сам собой. Я думал может у кого-то есть более красивые решения. Скорее всего так тоже не выйдет. Один и тот же код ошибки, например "дублирование первичного ключа" покрывает множество конкретных "бизнес правил". Поэтому для перевода системного сообщения об ошибке на "человеческий язык" придётся проводить его разбор с учётом контекста. Задача не из простых, а главное, мало что даёт для пользы дела. Решение может зависеть от СУБД. Можно развивать саму программу, но надо помнить, что программой написаной для идиота не станет пользоваться даже идиот. ИМХО, наиболее эффективный способ -- обучить пользователей, в том числе рассазать им про СУБД, БД и о том какие сообщения об ошибках они могут увидеть и как на них реагировать. "violation on FOREIGN KEY constraint ..." нужно обязательно перевести на национальный язык пользователя. Как правило это делается простой настройкой СУБД. Иногда приходится править файлы сообщений. Лично мне пока удавалось локализовывать программы без программирования. По "FK_BUILDING_1" нужно для пользователей сделать справочник, что именно это означает как минимум на уровне бизнес-логики. Некоторые СУБД позволяют настраивать текст сообщения для каждого ограничения целостности. Очень полезная штука. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 13:27
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
русский ответ сервера часто решается установкой русского MDAC если провайдер от MS. Если лень программировать и делать "дружественный интерфейс пользователя". ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 13:30
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
авторобучить пользователей, в том числе рассазать им про СУБД, БД и о том какие сообщения об ошибках они могут увидеть и как на них реагировать. "violation on FOREIGN KEY constraint ..." нужно обязательно перевести на национальный язык пользователя. Как правило это делается простой настройкой СУБД. Иногда приходится править файлы сообщений. Лично мне пока удавалось локализовывать программы без программирования. По "FK_BUILDING_1" нужно для пользователей сделать справочник, что именно это означает как минимум на уровне бизнес-логики. Ага. Еще надо перевести на русский "Access violation at address ..." и составить справочник адресов переменных и объектов с описанием, что именно они означают на уровне бизнес-логики Не проще ли уважить пользователя и перед добавлением записи проверить наличие такого "FK_BUILDING_1" в базе и культурно об это сказать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 13:34
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
CalmАга. Еще надо перевести на русский "Access violation at address ..." и составить справочник адресов переменных и объектов с описанием, что именно они означают на уровне бизнес-логики +1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 13:45
|
|||
|---|---|---|---|
|
|||
GUI и целостность данных в БД |
|||
|
#18+
CalmНе проще ли уважить пользователя и перед добавлением записи проверить наличие такого "FK_BUILDING_1" в базе и культурно об это сказать? Т.е. мы приходим к тому, что триггеры, которых я просил не предлагать, переходят на уровень клиента? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 13:52
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
Сергей Фролов CalmНе проще ли уважить пользователя и перед добавлением записи проверить наличие такого "FK_BUILDING_1" в базе и культурно об это сказать? Т.е. мы приходим к тому, что триггеры, которых я просил не предлагать, переходят на уровень клиента? варианта 3: - русская OS и MDAC - перехват в бизнес-слое в ХП с отправкой с сервера русского понятного текста - перехват на клиенте в коде с переводом русского понятного текста ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 13:59
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
п.п. 2 в виде исключения возбуждаемое сервером (для SQL Server) c кодом либо в логог-журнал OS либо в виде исключалки для клиента. ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 17:05
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
CalmАга. Еще надо перевести на русский "Access violation at address ..." и составить справочник адресов переменных и объектов с описанием, что именно они означают на уровне бизнес-логики Не проще ли уважить пользователя и перед добавлением записи проверить наличие такого "FK_BUILDING_1" в базе и культурно об это сказать? 1. Перевести. И в русском виндофсе это вроде сделано. Справочник адресов в данном случае излишен, поскольку это сообщение как правило говорит об ошибке в коде программы и нужно обращаться к разработчику, а у разработчика такой справочник скорее всего есть, например в виде map файла. 2. ИМХО, не проще. В любом случае, без знания концепции системы пользователи не смогут эффективно выполнять свои обязанности. Слово "ограничение целостности" не должно вводить их в ступор или вызывать рефлекторную реакцию "звони программистам". Кроме того, загромождая код анализаторами ошибок мы удорожаем и усложняем программу в сопровождении и создаём хорошую почву для создания новых ошибок. Реально, это нужно в автоматических отказоустойчивых системах, где исключительную ситуацию должен обработать автомат (чаще всего автомат не вникает в суть ошибки, а просто повторяет попытку или переходит к резервной процедуре). Когда речь идёт о человеке, который имеет допуск к системе, нет нужды принижать его интеллектуальные способности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 17:15
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
mcureenabСправочник адресов в данном случае излишен, поскольку это сообщение как правило говорит об ошибке в коде программы Исключения типа key violation чаще всего говорят ровно о том же. mcureenabСлово "ограничение целостности" не должно вводить их в ступор или вызывать рефлекторную реакцию "звони программистам". То есть пользователи сами должны разбираться в проблемах и потребностях криво реализованной программы. mcureenabКроме того, загромождая код анализаторами ошибок мы удорожаем и усложняем программу в сопровождении и создаём хорошую почву для создания новых ошибок. Хорошее обоснование для того, чтобы объяснять пользователю "access violation - в принципе нормальное состояние программы. Просто повторите операцию раз пять, если не поможет, подождите до завтра и повторите еще раз". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 18:01
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
Petro123 варианта 3: - русская OS и MDAC - перехват в бизнес-слое в ХП с отправкой с сервера русского понятного текста - перехват на клиенте в коде с переводом русского понятного текста Не вижу смысла без очень особых причин указывать в требованиях к ПО установки именно русской Windows и MDAC. mcureenab1. Перевести. И в русском виндофсе это вроде сделано. Вы всерьез считаете, что фраза "нарушение доступа по адресу ХХХ" более понятна пользователю, чем "Access violation at address ..." ? CalmНе проще ли уважить пользователя и перед добавлением записи проверить наличие такого "FK_BUILDING_1" в базе и культурно об это сказать? +1. Вот именно, перед добавлением. Nobody faults but mine... (LZ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 18:23
|
|||
|---|---|---|---|
|
|||
GUI и целостность данных в БД |
|||
|
#18+
aag CalmНе проще ли уважить пользователя и перед добавлением записи проверить наличие такого "FK_BUILDING_1" в базе и культурно об это сказать? +1. Вот именно, перед добавлением. А можно поподробнее, за что +1? Я приводил пример про УДАЛЕНИЕ! То, что целостность данных можно проверить перед добавлением, проблему не решает. Если я правильно понял, то вы предлагаете выполнить проверку непосредственно перед INSERT? А тот факт, что за время между проверкой и INSERT'ом запись в таблице, для которой создан foreign key, может быть удалена? Или вы предлагаете блокировать все связанные таблицы перед записью? Не самая разумная мысль. Хотя может я вас просто не так понял... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 18:54
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
CalmНе проще ли уважить пользователя и перед добавлением записи проверить наличие такого "FK_BUILDING_1" в базе и культурно об это сказать? О, это же сериализация доступа, тут тоже аккуратно надо. Всегда есть желание и часто необходимость не тормозить других пока один пошел чай пить. Пусть лучше он напившись чаю получит эксепшен , но по-человечески:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 18:58
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
aag mcureenab1. Перевести. И в русском виндофсе это вроде сделано. Вы всерьез считаете, что фраза "нарушение доступа по адресу ХХХ" более понятна пользователю, чем "Access violation at address ..." ? Эта фраза говорит пользователю только о том, что в процессе выполнения его запроса что то произошло. Естественно программа должна сообщить, что "Произошла ошибка, операция ХХ не выполнена" ну или что то в этом духе по обстоятельствам. Далее следует расшифровка причины, по которой операция не выполнена и (возможно) рекомендации. Не следует ожидать от пользователя знание английского языка, а слушать по телефону диагностическое сообщение на "английском" в исполнении пользователя (примерно: "тут ему фиолетово стало!"), который его никогда не изучал, заставляет меня плакать. Гораздо перспективнее, не объяснять пользователю, в чём он не прав, а строить его взаимодействием с системой таким образом, чтобы он не мог создать исключительную ситуацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 19:08
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
aag Petro123 варианта 3: - русская OS и MDAC - перехват в бизнес-слое в ХП с отправкой с сервера русского понятного текста - перехват на клиенте в коде с переводом русского понятного текста Не вижу смысла без очень особых причин указывать в требованиях к ПО установки именно русской Windows и MDAC. А что тут особого? Если в ТЗ прописано, что система должна общаться с пользователем на русском, то разработчик скорее всего потребует, чтобы базовое ПО (Windows и MDAC, например) тоже было локализовано. Перехват и "перевод" сообщений, это прямая привязка прикладного ПО к конкретной версии и даже конфигурации системного ПО. Локализовать системное ПО не в пример легче, и эффективнее, чем бороться с ним. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 21:01
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
mcureenabНе следует ожидать от пользователя знание английского языка, а слушать по телефону диагностическое сообщение на "английском" в исполнении пользователя (примерно: "тут ему фиолетово стало!"), который его никогда не изучал, заставляет меня плакать. Трогательная история. Именно поэтому в случае ошибки Вам на емейл должен уходить пакет информации: текст исключения и прочие свойства exception-объекта, стектрейс, скриншот, состояние датасета/датасетов. mcureenabГораздо перспективнее, не объяснять пользователю, в чём он не прав, а строить его взаимодействием с системой таким образом, чтобы он не мог создать исключительную ситуацию. Верно. Что, впрочем, совершенно не исключает возможность возникновения оной и не отменяет необходимости в качественно выстроенной обработке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.09.2006, 22:30
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
softwarer mcureenabНе следует ожидать от пользователя знание английского языка, а слушать по телефону диагностическое сообщение на "английском" в исполнении пользователя (примерно: "тут ему фиолетово стало!"), который его никогда не изучал, заставляет меня плакать. Трогательная история. Именно поэтому в случае ошибки Вам на емейл должен уходить пакет информации: текст исключения и прочие свойства exception-объекта, стектрейс, скриншот, состояние датасета/датасетов. Да уж, точно. Задача пользователя нажать на кнопку "Отправить", а не передавать словами описание ошибки. Обработка нужна всегда, даже если подозреваешь, что в этом месте ошибки быть не может. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.09.2006, 10:06
|
|||
|---|---|---|---|
GUI и целостность данных в БД |
|||
|
#18+
авторТо, что целостность данных можно проверить перед добавлением, проблему не решает. Если я правильно понял, то вы предлагаете выполнить проверку непосредственно перед INSERT? Угу. Это избавит разработчика от 95% вопросов пользователей. Ну или сэкономит нервы пользователям, если разработчику пофиг проблемы юзеров. авторА тот факт, что за время между проверкой и INSERT'ом запись в таблице, для которой создан foreign key, может быть удалена? Ну так и надо внятно написать почему не получается выполнить операцию. А не "key violation" в таблице такой-то. IMHO. С уважением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=33&tablet=1&tid=1549294]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
34ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 156ms |
| 0 / 0 |
