Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Необходимые и достаточные проверки операций
|
|||
|---|---|---|---|
|
#18+
Привет! Интересно если кто поделится соображениями о методологии проверок при операциях с базой данных. После выполнения операции (или блока операций) требуется убедиться, что операция изменила данные только те и так, какие и как задуманы разработчиком. То есть затронуто целевое множество - не больше и не меньше, а изменения (новое содержание) соответствуют задуманному. Чтобы сузить задачу, можно принять, что оперции выполняются на реляционной базе с помощью SQL. Понятно, что это делается в зависимости от сложности операции, серьезности задачи и кучи ограничений (например производительности). Опять же можно сузить по фактору серьезности до операций, не таких, которые отвечают за жизнь людей, атомную станцию или траекторию спустника ценой 10 миллиардов, но, скажем, таких, на которых реализуется коммерческая система и ошибки "очень нежелательны". Может кто-то уже выработал для себя некоторую практическую методологию на этот счет, как например: - у меня все запросы правильные (проверены при отладке), так что проверять при операциях нечего - у меня вся ответственность на правилах ограничения целостности - высчитываю кол-во записей, котоые попадают под операцию и сравниваю с реальным результатом - пишу полную проверку результатов операции (какие записи и на что изменены) Проблема в том, что не всегда все возможные ситуации удается имитировть при отладке. У меня небольшой опыт по коммерческой разработке приложений с базами. Хочется понять как все делается серьезно. Я в курсе, только, как строятся "лимфатические системы" обычных программ. Может подскажете что почитать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2004, 20:27 |
|
||
|
Необходимые и достаточные проверки операций
|
|||
|---|---|---|---|
|
#18+
Думаю модератор перенесет скоро эту темку в проектирование БД. Все зависит от конкретной специфики приложений. Например у меня ХД и основной критерий правильности это возрастание количества информации. Поэтому после каждого Inserta проверяю на увеличение числовых и суммовых показателей в контексте загружаемой информации. Если увеличились, то все ОК. Если не увеличились, то либо выходной день, либо проблемы. Если уменьшились(например суммы продаж), то значит траблы. Плюс увеличение не должно сильно выскакивать за среднезагрузочное увеличение, иначе возможно гдето лишне накручиваются итерации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2004, 09:16 |
|
||
|
Необходимые и достаточные проверки операций
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2004, 09:27 |
|
||
|
Необходимые и достаточные проверки операций
|
|||
|---|---|---|---|
|
#18+
автор...реализуется коммерческая система и ошибки "очень нежелательны". От всех ошибок очень трудно избавиться - это вопрос времени и денег, потраченных на разработку и тестирование. автору меня все запросы правильные (проверены при отладке), так что проверять при операциях нечего Проверять нужно не только при отладке. Главное в этом смысле - это тестирование. И вот при тестировании нужно постараться проверить все возможные ситуации. авторвысчитываю кол-во записей, котоые попадают под операцию и сравниваю с реальным результатом В принципе, такие проверки могут понадобиться, но, мне кажется, что перед операцией и вряд ли очень часто. Можно подумать еще над изменением в отдельных местах уровня изоляции транзакций. Очень важно обрабатывать ошибки, тем более, в критических участках кода. Итого: писать грамотный код и тщательно его тестировать :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2004, 09:32 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32510103&tid=1546503]: |
0ms |
get settings: |
10ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
87ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 257ms |
| total: | 444ms |

| 0 / 0 |
