Правильная ссылка на эту страницу
http://az-design.ru/Projects/AzBook/TestDB/20081231_Prof.shtml

Как Вы тестируете базы данных
Дискуссия на сайте proffesionali.ru

       Андрей Архангельский(В поисках работы), 31 декабря 2008 в 09:03
Поделитесь опытом - как Вы тестируете базы данных?
Не интерфейсы, не программы а именно базы данных.

Айрат Давлетшин (Владелец, ООО Линукс Технологии), 31 декабря 2008 в 11:29
Андрей, какие еще базы данных?! Новый год сегодня!:)
Оставьте работу на следующий год и идите протирать стакан;)
Андрей Архангельский (В поисках работы), 31 декабря 2008 в 12:10
Стакан протер, а наливать еще рано
Данияр Муслимов (Ведущий программист ГСРПО, ОАО "СЗТ"), 31 декабря 2008 в 12:56
да пора-пора уже ;)
Олег Суханов (Начальник отдела, РБК/ Медиа Мир), 31 декабря 2008 в 11:47
Какая СУБД вас интересует?
Интернет проект?
Андрей Архангельский (В поисках работы), 31 декабря 2008 в 12:09
1) СУБД может быть любой, важны принципы.
2) А причем здесь интернет-проект? Других баз данных в мире не существует?
Vladimir Doubrovski (агент, Крым наш дом), 5 января в 18:09
Загрузкой реальных данных и отладкой СУБД на соседних компьютерах разной мощности.
Андрей Архангельский (В поисках работы), 6 января в 09:54
Загрузка реальных данных в достаточном количестве - единственный способ убедится в том, что проектировщик понимает какие свойства имеют данные.
Однако большинство, следует принципу К.Дж.Дейта "Проектирование БД должно быть отделено от данных".
Как говорил мне мой отец "Я решу все твои проблемы, только знать не желаю в чем они заключаются".
В июле 2008 года директор фирмы KV-Expert Вдовин Владимир Евгеньевич сказал мне мнесколько фраз, после которых мы с ним расстались окончательно:
"Архитектуры не продаются, продаются картинки, интерфейсы"
"Мы тут не научными исследованиями занимаемся, а создаем продаваемые системы"

Исследование реальных данных имеет минусы:
- это очень дорого, нужно привлекать экспертов в отдельных предметных областях.
и плюсы:
- база данных выдает данные, которым можно доверять
- база данных работает быстрее, потому что а) она лучше нормализована, б) в ней нет мусора.
Vladimir Doubrovski (агент, Крым наш дом), 6 января в 18:37
На основании 20-ти летней эксплуатации авторской системы САПФИР для анализа и обработки данных в СУБД могу сообщить KV-Expert. Развитие идет по спирали. Как в свое время банки данных развились в СУБД. Сейчас картинки & интерфейсы заказчик желает наполнить данными собственных исследований в упорядоченном, систематизированном виде.
В результате на предприятиях имеем Интегрированные многоплатформные системы вместо реально необходимых баз данных с интрументами анализа. Попробуйте подсчитать и сравнить стоимость первого и второго - работа обеспечена всерьез и надолго.
Александр Б (Директор, Рекламное агентство "Нефтегаз"), 1 января в 02:33
Были проблемы с базой www.oil-gas.ru
Дмитрий Московой (CIO, NvisionGroup), 31 декабря 2008 в 13:59
Тестируем руками тестеров.
А если серьезно, вопрос весьма широкий, инструментарий тоже. Может быть, есть смысл сузить вопрос до конкретики - конкретные СУБД, тип тестирования - нагрузочное тестирование, тестирование селектов, апдейтов, etc.
Андрей Архангельский (В поисках работы), 31 декабря 2008 в 16:27
Конкретика простая: Создали базу данных - как проверить что она работает.
Если один оператор ввел данные, то сможет ли другой оператор найти эти данные СТАНДАРТНЫМИ для этой базы данных средствами?
Наталья Желнова (IT-тренер, консультант, *), 13 января в 08:00
Простите великодушно, что значит "стандартными для этой базы данных средствами"?
Хранимые процедуры, прямые запросы к данным, обращения к базе данных, инициированные пользовательской сесией из пользовательского интерфейса через средства доступа к данным (ODBC, ODBC, DAO, OLE DB и ADO) - это все СТАНДАРТНЫЕ средства.
Олег Кузьмин (Системный администратор, ООО Завод кондиционеров "Август"), 31 декабря 2008 в 14:21
Не знаю как базы, а нагрузочное тестирование можно проводить запостив ссылку на хабрахабр.
Евгений Гуляевский (менеджер проектов, Топ-Книга), 31 декабря 2008 в 14:32
Без привязки к задаче?
А смысл? Всегда смотрел на этот процесс прагматично, есть задача - есть что тестировать.
Нет задачи - нечего время терять.

С Новым годом, коллеги!
Андрей Архангельский (В поисках работы), 31 декабря 2008 в 16:35
Чрезвычайно прагматично!
За последине 5-8 лет я не встретил ни одной базы данных, которая бы работала.
Причем все ошибки, которые были в этих базах данных сделаны на этапе проектирования.
Точнее проектирования как такового не было - было первое попавшееся решение.
При этом авторы кричат, что "ИХ то база данных работает".
Например, бухгалтерская система "Фрегат". В ней невозможно ввести в качестве работника генерального директора фирмы, которая разрабатывала эту систему - Абасова Рауфа Гули оглы. Уж такое простое тестирование можно было провести?
Примером могу приводить множество.
Итак, если Вы считаете, что Ваша база данных работает, то расскажите как Вы ее тестировали (как Вы узнали об этом).
Евгений Гуляевский (менеджер проектов, Топ-Книга), 31 декабря 2008 в 23:14
Ваш пример с Фрегатом подтверждает мое утверждение.
Вы тестируете не БД, а конкретное приложение, другими словами - конкретную задачу.
Удачи!
Андрей Архангельский (В поисках работы), 1 января в 10:50
Чушь!
Конкретное приложение вносит данные в то место в базе данных, которое она позволит. А если этого места нет, то виновата база данных, а не приложение.
Если база данных позволяет вводить неправильные данные, то переносить бизнес-логику на приложение неправильно. Всегда найдется другое приложение, которое введет неправильные данные.
Евгений Гуляевский (менеджер проектов, Топ-Книга), 1 января в 20:57
Сожалею.
Вы путаете понятия и пытаетесь запутать других. Есть БД (Oracle, MS SQL, DB2 и т.п) и есть БД с набором таблиц и прочего для конкретного приложения.
Вы под БД понимаете последнее и тестируете не БД, а конкретное приложение.
Приложение тестируется в соответствии с задачами, для которого оно предназначено. Есть задача или список задач - есть план тестирования.
Андрей Архангельский (В поисках работы), 2 января в 11:03
Это не я путаю, а Вы!
(Oracle, MS SQL, DB2 и т.п) - это СУБД (Система Управления Базой Данных)
Есть база данных с набором таблиц и есть клиентское приложение, которое работает с этой базой данных.

Если Вы создали таблицу в базе данных, как Вы докажете, что структура таблицы правильная? Как Вы докажете, что сможете правильно внести в нее ВСЕ необходимые данные?

При этом клиентского приложения еще может не быть.
Евгений Гуляевский (менеджер проектов, Топ-Книга), 8 января в 19:40
Все-таки Вы не понимаете о чем задаете вопрос.
Одна и та же таблица может быть правильной для одного приложения и совершенно неправильной для другого.
Правильность структуры таблицы оценивается не абстрактно, а всегда применительно к конкретному приложению.
Если бы это было не так то все приложения были бы одинаковые
Наталья Желнова (IT-тренер, консультант, *), 13 января в 08:09
Соглашусь с Евгением.
Одна и та же таблица действительно может быть правильной для одного приложения и совершенно неправильной для другого.
Другое дело (возможно, я ошибаюсь) - Вы, возможно, "неожиданно" познакомились с понятиями ограничений (CHECK, FK) в РСУБД.
Мой совет: возьмите любую книгу с названием "Основы проектирования баз данных" или "Программирование баз данных" http://www.dialektika.com/books/978-5-8459-1138-4.html Там говорится о том, как использовать стандартные средства конкретных баз данных для того, чтобы гарантировать, что Вы сможете правильно внести в нее все необходимые данные.
Андрей Архангельский (В поисках работы), 14 января в 10:14
Вот начиталась девушка рекламных проспектов, а ручками ничего не делала.
Евгений не знает, что такое декомпозиция проекта, что такое унифицированные модули и прочеее. Он не знает, что существуют например такие системы как Delphi или Builder, которые напичканы унифицированными компонентами, кторые пригодны для любого приложения.
Если я делаю таблицу "Персоны", то она пригодна для любого приложения, которое использует информацию о персонах. И ее можно рассматривать отдельно. И вообще, с одной БД может работать множество различных приложений. Если Евгений этого не знает, то мне жалко его работодателя.
Наталья Желнова (IT-тренер, консультант, *), 14 января в 12:35
Вот не дорос, значит, мальчик-то до позиции system architect, а теперь пытается выступать в форумах. Жаль, однако.
Андрей Архангельский (В поисках работы), 14 января в 12:56
Вот нахватала девочка всяких дипломов и думает, что все знает. А по факту предъявить нечего. Доказательств NULL.
Vladimir Doubrovski (агент, Крым наш дом), 6 января в 18:50
Любое приложение работаем на основе СУБД (системы управления) именно ее концепция, логическая и физическая схема и реализация не допускают введения неправильных данных.
В обычной жизни на компьютере работает Операционная система, аналогично, она запускает процессы, а если процессу вздумается ввести неправильные данные или испортить ось - извините, это уже вирус.
Андрей Архангельский (В поисках работы), 6 января в 19:09
Не совсем так!
СУБД отслеживает типы данных и связи. НО!
если я создам таблицу типа
Create table Persons (
     ID          Integer not null primary key,
     FirstName   Char(50),
     MiddleName  Char(50),
     SurName     Char(50)
     unique key (FirstName,MiddleName,SurName));
То несмотря на уникальный ключ это позволит ввести бесконечное множество неправильных данных. подробнее можно посмотреть здесь:
http://www.azdesign.ru/Projects/AzBook/Review/LITMO2.shtml
При этом СУБД признает эту таблицу правильной. Любые тесты будут считать ее правильной. В реальности колечество мусора в таких таблицах значительно превышает 20%. Кроме того далеко не все данные можно ввести.
И наконец, определение уникальности человека только по имени, отчеству и фамилии дает только по Москве примерно 550 повторений. А это значит, что в эту БД можно ввести только 1 из 550 жителей города Москвы.
Vladimir Doubrovski (агент, Крым наш дом), 6 января в 21:27
Данный подход не является правильным.
Таблица ФИО не имеет права создаваться. В основе СУБД лежат словари и справочники. Что мешает разработчику воспользоваться телефонным справочником, или базой регистрации по месту жительства и прочими доступными и легальными источниками информации.
Реляционная база данных должна отслеживать целостность данных. А уникальность ID в вашем случае соблюдается. Тот же ORACLE признает что не является по настоящему реляционной табличной БД.
Мы забыли начало - иерархические базы данных. А самая сильная (и сама сложная) сетевая модель данных. Кстати, коллега из Севастополя реализовал ее на примере Крыма http://www.crimaniak.com.ua/info/feodosia/4404.html
Жаль новая, 5 версия php не совсем совместима с реализацией.
Андрей Архангельский (В поисках работы), Вчера в 09:23
1) Такая таблица имееется в 99% БД (в остальных еще хуже)
2) Такая таблица, как пример, используется во ВСЕХ учебниках по разработке баз данных.
3) Я начинал с телефонных справочников и баз регистрации (что незаконно). Я тогда делал БД для директ-маркетинга. У меня было 10 девочек-операторов, которые были очень ответственны, которые понимали что от качества их работы напрямую зависит их зарплата. Тогда я впервые столкнулся с этой проблемой. Я исследовал практически все регистрационные БД, которые продаются у пиратов. Все это оказалось бесполезным. Это главная проблема - создать словарь
Vladimir Doubrovski (агент, Крым наш дом), Вчера в 17:25
Здесь в словаре и зарыта собака. При разработке СУБД сами создавали словарь. Зашита от дурака, минимум, максимум, выпадающий список, челое число или текст... В систему включили статистические и математические операции с данными в том числе и для их проверки.
Не оператор, а специалист предметной обласи занимался тестированием и обкаткой в течении нескольких месяцев базы перед промышленным внедрением. Эти данные были включены в технические характеристики.
Сам лично внедрил САПФИР в Тюмени, Сургуте, Нижневартовске, Киеве, Ташкенте, Нарьян-Маре, а сотрудники в других не менее известных нефгегазовых районах.
Евгений Гуляевский (менеджер проектов, Топ-Книга), 8 января в 19:41
Значит эта таблица не подходит именно для этой задачи, а для какой-то другой вполне подойдет.
Наталья Желнова (IT-тренер, консультант, *), 13 января в 08:15
Дык, мил человек! Если Вы будете реализовывать проверку данных, скажем, путем написания сложных триггеров или создания ограничений на таблицу, Вы знаете какая будет производительность у Вашей системы... очень низкая будет у Вашей системы производительность.
Для того, чтобы гарантировать правильность ввода данных, давным-давно используют маски ввода и справочники (как подсказывают уважаемые коллеги чуть ниже). Маски ввода программируются в клиентской части, а не на серверной стороне.
Справочники создаются как отдельные таблицы БД.
Андрей Архангельский (В поисках работы), 14 января в 10:05
Милая девушка!
1) А Вы хоть раз создавали справочник. Не из 2-3 строк, а более или менее приличный. Например, пробовали положить в таблицу "Товарную Номенклатуру Внешнеэкономической деятельности" - всего 17500 строк. Я уже не говорю про УДК. Если делали (в чем я сильно смневаюсь), покажите - предъявите публике.
2) Покажите мне заказчика, который горит желанием оплатить разработку справочника. Он же думает, что из этого справочника он будет использовать только 10 значений, правда он не знает какие.
3) Напишите маску ввода, котора позволит правильно ввести:
фамилии - мАлина и малИна
имена - Наталья и Наталия
4) А знаете ли Вы какие виды ошибок пользователей бывают? Распределение ошибок по группам можно посмотреть у меня на сайте.
Знаете ли что требование к оператору постричь ногти имеет такое же значение, как требование к хирургу помыть руки перед операцией.
Наталья Желнова (IT-тренер, консультант, *), 14 января в 12:59
Про 3) - сделайте так, чтобы оператор обязательно проверял данные, которые он вводит, и исправлял ошибки.
Маску ввода, которая будет отлавливать опечатки, особенно в фамилиях, Вам, разумеется, никто не напишет, милый юноша. Здесь может помочь только обязательная проверка данных после ввода. Сам оператор или его старший товарищ будет проверять данные - неважно. Но обязательная проверка важных данных после ввода и возможность исправить ошибку перед сохранением данных в базе позволяет существенно сократить количество "мусора". Да, это потребует больше времени на ввод данных. Поэтому всякий раз стоит задавать себе вопрос, а действительно ли так важно, чтобы введенные данные не содержали ошибок.
Про 1) - придумать, как создать иерархический справочник из нескольких тысяч строк строк, конечно, можно (ключевое слово - иерархический). Делали это опять же в тысяча девятьсот лохматом году для Росфинмониторинга и продолжаем делать для других клиентов. Никакой сверхсложной задачи я в этом не вижу.
По всем остальным пунктам - (с "а вы знаете"), - честное слово, неинтересно даже беседу продолжать. Да, я - знаю. Я вообще много знаю и умею. Поэтому я называюсь системным аналитиком и даже учу этому ремеслу других людей.
Я понимаю, это Ваш первый проект. Ничего, с опытом приходит мудрость.
Учитесь, и успехов Вам.
Андрей Архангельский (В поисках работы), 14 января в 13:38
>>> Про 1) - придумать, как создать иерархический справочник из нескольких тысяч строк строк, конечно, можно (ключевое слово - иерархический). Делали это опять же в тысяча девятьсот лохматом году для
Итак Вы не знаете и не делали.

И несмотря на то, что это чисто иерархический справочник, и размер не велик. НО!
В нем 60% ошибок первого порядка, т.е. 10500 строк,
Например, 750 строк содержат только слово "Прочие" и указатель подуровней.
В результате раскрытия получается до 8 слов "Прочий" в строке.
И как Вы поставите уникальный индекс на это поле?
А теперь учтите, что менять в этом справочнике ничего нельзя, так как он утверждается Правительством.
Весь справочник хорошо выглядит пока напечатан на бумаге, но при переводе его в таблицу возникают проблемы.

Вы может много знаете того, что написано в книгах, но НИКОГДА не тестировали БД на качество проектирования. Во-первых, теория далеко не всегда работает (например, бесполезно ставить уникальный ключ на текстовое поле, если данные вводит случайны оператор), во-вторых - ни в одном учебнике не сказано как ПРОЕКТИРОВАТЬ БД. Много говорится об операторах, функциях и прочих кирпичиках, но нигде не говорится как построить инфологическую модель и убедится в том, что эта модель работает. Ни в одном учебнике не говорится ни о системах классификаций, ни о области видимости данных. Хотя об области видимости переменной каждый студент знает.
Все что Вы написали про проверку старшим товарищем - это идиалистическая картинка предавателя, но не пользователя. Мусор в БД означает, что полученной из БД информации Вы не можете доверять. Вы же не хотите ездить на автомобиле, у которого колеса поворачиают куда им захочется.

И, наконец, по поводу мальчика и первого проекта.
Базами данных я занимаюсь с 1987 года, плюс 5 лет занимался тестированием (и разработкой тестов) для микро-ЭВМ и микропроцессоров, плюс 10 работал конструктором по точным приборам.
Поэтому я знаю как тестировать, я знаю как выделить из проекта унифицированный модуль, обеспечить его работоспособность и вставить в любой проект.
Если Вы не сталкивались с проблемой, это не значит что ее не существует.
Если Вы называетесь системным аналитиком и даже учите чему-то других, но не можете привести доказательств и даже не можете оценить проблему, лежащую на блюдечке, то можете называться как угодно.
Наталья Желнова (IT-тренер, консультант, *), 14 января в 15:44
Ну, если Вы только сейчас открываете для себя очевидные вещи вроде "бесполезно ставить уникальный ключ на текстовое поле, если данные вводит случайный оператор", то у Вас действительно серьезная беда с проектированием баз данных. Впору сначала читать толковые книжки по проектированию баз данных (основы основ, там как раз объясняют, какие поля можно использовать в качестве уникальных ключей, а какие - нет), а потом к толковым консультантам обращаться. Они, кстати, объяснят, что уникальный ключ вообще довольно редко создается на полях, "в которые вводят данные случайные операторы". А вот уникальные индексы, в отличие от уникальных ключей - таки да, на таких полях создаются, часто бывает. В чем отличие уникального индекса от уникального ключа, Вам объяснят другие товарищи, я надеюсь.
Данные, при вводе которых не может быть использован справочник или маска ввода, и которые тем не менее должны быть введены правильно, действительно проверяются лицом, контролирующим правильность составленных документов - в ситемах автоматизации документооборота, например. Быть может, Вы слышали о таких, со своим "опытом с 1987 года"?
И потом, мил человек, вопрос-то у Вас, как я вижу, не о тестировании баз данных. Вопрос о том, какими средствами обеспечить правильность ввода данных пользователем. Ответ, разумеется, самоочевиден: только средствами БД это сделать не удастся. И "тестировать базы данных" (терминология, разумеется, Ваша) в отрыве от реального бизнес-процесса в данном случае попросту означает зря терять время.
Извините, мне - мое очень дорого. Дальше развивать дискуссию с человеком, пытающимся с авторитетным видом преподнести как проблему то, что успешно делает любой мало-мальски квалифицированный системный аналитик, мне попросту неинтересно.
Алексей Подружко (ИТ-специалист), 31 декабря 2008 в 16:36
Вас интересует технология тестирования вообще ?
тут единых приёмов нет.
советую почитать об этом в интернете.
Например, на специализированных форумах
Андрей Архангельский (В поисках работы), 1 января в 10:39
Мне это напоминает старый анекдот - человек хотел купить баранов, а ему все давали советы, где это можно сделать. Под конец объяснили - Мы же живем в стране советов, а не баранов.
Это наверное 20-й форум на котором я задаю этот вопрос. На всех специализированных форумах задавал. Просто надеялся, что здесь ПРОФЕССИОНАЛЫ.
Алексей Подружко (ИТ-специалист), 1 января в 20:59
Есть регрессионное тестирование, нагрузочное,
метод чёрного ящика
Какое тестирование вас интересует ?
Андрей Архангельский (В поисках работы), 2 января в 11:16
Я хотел получить нечто подобное:
Метод:
-- нагрузочное тестирование
Что проверяется:
-- время реакции СИСТЕМЫ на действия пользователя или время выполнения СИСТЕМОЙ определенной функции
Как проверяется:
-- БД заполняется некоторым количеством данных и имитируется множство подключений пользователей. Для этого могут применятся генераторы тестовых данных и программы, моделирующие различное поведение пользователей. Примером таких программ может служить система Avarda.
Результат:
-- метод дает близкие к реальным результаты в случае билинговых систем, хуже для АСУ, и практически непригоден для информационных систем.

Я хотел получить не список методов, которые существуют (или могут существовать) в мире. Я хотел получить ответ - какие методы ЛИЧНО ВЫ применяете, для того чтобы проверить ИМЕННО БАЗУ ДАННЫХ, а не СУБД, Железо, линии связи или что-нибудь подобное.
Наталья Желнова (IT-тренер, консультант, *), 13 января в 08:25
А какой смысл проверять "саму базу"?
Правильность ввода данных Вам будет гарантировать правильное выполнение всех тест-кейсов, написанных по пользовательским сценариям с учетом всех альтернативных путей пользовательских сценариев.
Опишите сценарии, напишите тест-кейсы, выполните тест-кейсы, будет (или не будет) Вам счастье. Других методов проверки (в отрывае от готовой системы), к сожалению, не существует.
Правильность заполнения базы данных (скажу банальность, Вы не поверите!) проверяется проверкой результатов имеющих смысл выборок из таблиц - при помощи специального автоматизированного скрипта или "глазами человека". Первое надежнее, второе дешевле.
Тестируют при этом, как правило, уже готовую систему, а не "просто базу данных". Потому, что, как я уже упоминала, обеспечение правильности ввода данных пользователями может быть реализовано отнюдь не средствами программирования БД.
Алексей Подружко (ИТ-специалист), 31 декабря 2008 в 16:38
И ещё,
работоспособнасть базы оценивается исходя из ТЗ
Андрей Архангельский (В поисках работы), 1 января в 10:42
О том как ТЗ соотносится с реальной жизнью почитайте в этом замечательном рассказе:
http://www.az-design.ru/Projects/AZLibrCD/Fantast/TZ_janitov.shtml
Мой отец, будучи главным инженером завода, давал этот рассказ свои конструкторам вместо инструкции по технике безопасности.
Андрей Пестовский (manager, Barclays Global Investors), 1 января в 01:52
there are a lot of technics and tools to test DBs... start with testing data schema in relational db based on technical specification, this will cover logic. you can use some testing tools (depending of type of data base) or even manually entering sql statements... of cause this will have objective to conform existing db to the schema. then there are a lot of ways to test performance of a db.. load test etc. if you want to test via interfaces then depending on technology used there are tools like soa test to test via services etc... if you can tell what data base is used (sybase, MS sql, oracle, DB2 etc) i might suggest some testing tools. also, test imlementation depends on architecture, client app, web app etc... each can use different approach. sorry for not typing in russian: some techi things easier to explain in english.
Андрей Архангельский (В поисках работы), 1 января в 10:35
1) Вы, как и К.Дж.Дейт, не делаете различий между системой баз данных, системой с базой данных, базой данных и системой управления базой данных. Отсюда неизвестно что Вы тестируете.
2) Специалист, который реально знает что-то про тестирование напишет табличку вида:
Метод тестирования | ЧТО проверяет | КАК проверяет
Андрей Пестовский (manager, Barclays Global Investors), 1 января в 12:19
you dont specify DB you test nor methodology that would take to test one. and you have no idea about testing in general. since any Метод тестирования depends on technical specification about DB. your question is useless question, and you provide no relevant informatin to test one. if you think that test professionals from cillicon valley are not profesional enough then i rest my case. good luck to get replies to generate interest to your "question". for me it's waist of time. regards
Андрей Архангельский (В поисках работы), 2 января в 11:40
1) Если Вам нечего сказать, то зачем встревать в дискуссию, да еще на англиском языке с вкраплениями русского.
2) В книге Роберта Гласса "Руководство по надежному программированию" (1982г) даны десятки методов тестирования, которые никак не привязаны к конкретной задаче, компьютеру или языку программирования.
3) Архитектура базы данных очень мало зависит от типа СУБД, на которой она будет использоваться. В то же время в архитектуре заложены глобальные причины ошибок в базе данных.
4) Я ничего не говорил о "тестировщиках из силиконовой долины", но если Вы молитесь на них, как на богоподобных, то могу привести десяток примеров глупостей как Microsoft, так и Apple, которые появились на этапе проектирования и никак не тестировались. И при этом нанесли громадный ущерб пользователям.
5) О моем опыте тестирования:
1980-1982гг - наладчик микро-ЭВМ С5-21М и многомашинных комплексов на их основе (ЛКТБ ЛОЭМ "Светлана"). По моим тестам удалось найти пылинку на фотошаблоне для микросхем 5730РФ1
1983 - разработка тестов и тестирование процессоров 1801ВМ1, ВМ2, ВМ3 (НИИТТ)
В дальнейшем разработка тестов для спутников специального назначения.
А вопрос мой полезный! Так как на сегодняшний день базы данных представляют собой некоторый набор данных, которые не являются достоверной информацией. И никто их не тестирует. Это показывает и этот опрос.
Андрей Пестовский (manager, Barclays Global Investors), 6 января в 22:40
так вы саморекламой занимаетесь... а я думал вам помощь нужна. если вы спрашиваете о методиках тестирования, тогда читайте книжки. если у вас есть конкретный вопрос, то изложите, и просьба излагать без эмоций. а насчет силиконовой долины так я там уже 14 лет работаю и сам на себя не "молюсь" и вам не советую... если вы считаете, "базы данных представляют собой некоторый набор данных, которые не являются достоверной информацией и никто их не тестирует" то вам нажна помощь специалиста который поможет вам вернуться в реальность.
Андрей Архангельский (В поисках работы), 7 января в 09:07
Если бы Вы задали мне вопрос "На каком автомобиле Вы ездите?", а я начал в ответ рассуждать какие автомобили существуют и на каких выставках их показывают. Вы бы что обо мне подумали?
Правильно! Человек сам на автомобиле не ездит, автомобили выидел только в журналах на картинках. И сказать ему нечего.
Повторяю вопрос! КАК ВЫ ТЕСТИРУЕТЕ БД.
не я, а ВЫ. Если Вы не тестируете, то нечего пальцы веером кидать. А если теструете, то ответьте на вопрос прямо.
А пока судя по ответам никто БД не тестирует.
Андрей Пестовский (manager, Barclays Global Investors), 7 января в 10:01
с таким подходом к саморекламе вы не только 2 года, вы навсегда без работы останетесь. вы что хотите чтобы вам описывали на форуме такие азы как методики тестирования баз данных? у какого нормального занятого человека есть столько свободного времени и желания?! читайте книги или если так опытны, то пишите свои. и пожалуйста оставьте ваши эмоции при себе.
Андрей Архангельский (В поисках работы), 7 января в 10:15
1) если методики тестирования баз данных являются азами, то почему Вы не описали ни одной из них.
2) Книгу пишу, и именно для нее собираю информацию
3) С каких это пор менеджер инвестиционной компании является профессионалом в базах данных и тестировании
4) Quick Test Pro is a good testing tool - не тестирует базы данных, а предназначен для тестирования итнтерфейсов и web-сайтов. (см. описание)
5) По видимому у Вас в связи с кризисом образовалось много времени, что Вы тратите его на бесполезный разговор о том, в чем Вы не разбираетесь
Андрей Пестовский (manager, Barclays Global Investors), 7 января в 11:40
ну зачем так? вы взрослый человек а ведете себя как ребенок :) мне забавно читать ваши нападки и у меня рабочий день давно закончился... точнее сейчас сдесь полночь но не спится, а тут вы, такой забавный человек, вот и "обчаюсь" хахаха во первых методики описывать долго и скучно а вы наверно не собираетесь оплачивать затраченное время, во вторых, поздравляю с рукописным трудом, напечатаетесь, может почитаю, но делать за вас домашнюю работу бесплатно не охота...в третьих, я IT manager, в 4-х QTP, как я уже сказал, тестирует через GUI (Graphical User Interface)...также как и Silk , и WinRunner (QTP replaced WinRunner as part of HP tool set) и многие другие автоматизированные test tools, есть и те которые не используют User Interface, есть более ДБ специализированные test tools которые чаще всего разрабатываются к определенным ДБ, потому я и спросил какую ДБ вы тестируете ;). QTP может тестировать получение данных из ДБ, сверку с ожидаемыми данными и так далее, хотя вы наверно очень знакомы с QTP мне обяснять вам азы не нужно ;) и в 5-х у меня с работой все хорошо, чего и вам желаю :)
Ирина Бурякова (Самозанятое лицо), 2 января в 15:32
Извините,но не пробовали ли вы использовать QTP?В любом случае прийдется пару раз пройтись по самой базе в ручную.И с новым годом всех!!!
Андрей Архангельский (В поисках работы), 3 января в 17:24
Вопрос не в том, что я пробовал или не пробовал.
Вопрос о том, ЧТО ВЫ ИСПОЛЬЗУЕТЕ
А Вы уверены, что пройтись по самой базе в ручную придеться только пару раз?
Ирина Бурякова (Самозанятое лицо), 4 января в 19:46
Для большего количества стоит автоматизировать процесс и просто запускать программу ....
Андрей Архангельский (В поисках работы), 5 января в 09:22
КАК?
Ирина Бурякова (Самозанятое лицо), 5 января в 18:58
есть специальные программы автоматического тестирования.
Андрей Архангельский (В поисках работы), 6 января в 09:35
Конкретно!
Андрей Пестовский (manager, Barclays Global Investors), 6 января в 22:53
по-моему он не ищет конкретного ответа, потому и не задает контретного вопроса... пустая трата времени... человек занимается саморекламой и доказывает что никто кроме ниго ничего не знает про тестирование, все что он сказал могло быть "открытием" лет 30-40 назад.
Quick Test Pro is a good testing tool, хотя разработан и используется для тестирования DB через GUI. в зависимости от DB есть очень много test tools, которые тестируют DB схемы, DB service layer, load and performance без GUI.
Михаил Кузнецов (Инж. прогр./электронник, Мосэнерго), 3 января в 16:50
Андрей, Вы задали очень классный вопрос, в корень смотрите. Я только недавно заинтересовался SQL, поэтому многого могу не знать. Наверное понятие тестирование не совсем подходит для Вашего Вопроса. Вопрос похоже в том, как оценить насколько правильно спроектирована база данных, и насколько полезна она будет для заказчика, т.е. существуют ли какие-то инструменты позволяющие автоматизировать этот процесс? Т.е. проверка самой заложенной логики, ПО на котором реализовано не при чём. Тут наверное всё на совести разработчика, который начинал проект. Чем больше сил было положено в разработку правильной основы, тем лучше. На практике в большинстве случаев наверное чаще получается латание дыр, и поиск методов обхода заложенных изначально неправильных решений. Вряд ли от этого спасёт какой-нибудь инструмент. Это моё субъективное мнение.
Андрей Архангельский (В поисках работы), 3 января в 18:37
Это все-таки тестирование. Но если не произносить таких умных слов, то посмотрим в историю вопроса:
Когда Вы покупаете кофеварку за 3000 рублей, то Вы из продавца "душу вынете", но заставите его доказать, что эта кофеварка действительно варит кофе. Так!
А почему, покупая базу данных за 1 млн. долл. Вы не хотите убедится в том, что база данных выдаст правильные результаты?
Я задавал этот вопрос на профессиональных форумах (sql.ru, source.ru, ibase.ru и им подобных) и на общих площадках. Ответа за 2 года не получил. Пока были дисскусии на МойКруг.ру запустил такую же дисскусию и там. Одна администратор баз данных, которая разрабатывала БД под Oracle 10 лет, БД объемом 30-50 млн. записей, по женски ответила на вопрос вопросом - А ЗАЧЕМ?
Я знаю как тестировать, я провел много исследований. Этот опрос преследовал одну цель - понять если профессионалы, которые понимают что сегодняшние базы данных таковыми не являются, а представляют собой хранилище буковок и циферек. Примеров можно приводить множество:
В БД "ГИБДД Москвы 2002г" слово "Александр" записано 153 способами, какими см. здесь:
http://www.az-design.ru/Support/DataBase/GMSK200202_tName.shtml
В БД "Прописка Москва и МО 2005г" из 23 млн. записей я вычистил только 3 млн. Из этих 3 млн. 20% являются мусором. Предварительная оценка - около 50% записей для всей БД являются мусором. И когда милиционеры ОШИБОЧНО шли брать уклониста от армии в другую квартиру, избили отца, мать и 12-летнего мальчишку, то они пользовались ЭТОЙ БД. Но это могли быть ВАШИ отец и мать.
Роберт Гласс в 1979 году описал метод тестирование "Инспекция за столом". Сегодня в книге "Факты и заблуждения профессионального программирования" он пишет, что до сих пор это САМЫЙ МОЩНЫЙ метод. Анализ маленькой таблички из БД "Билиотека" (учебник проф. Кириллова В.В. "Ведение в реляционные базы данных") выложен здесь:
http://www.az-design.ru/Projects/AzBook/Review/LITMO2.shtml
Естественно если основная таблица БД не работает, то и вся БД не работает.
И, когда, профессионалы вместо конретных вопросов на конкретный вопрос начинают кидать пальцы веером и требовать конкретики, то понятно почему я 2 года не могу найти работу.
Михаил Кузнецов (Инж. прогр./электронник, Мосэнерго), 3 января в 20:36
Согласен с Вашими доводами. Сам очень осторожно выбираю учебники которые нужно читать, чтобы не жалеть о потраченном времени.
О каком качестве БД или программ может идти речь, когда их нужность для самого заказчика вызывает сомнения? Система откатов - вот это интересней.
Существование низкокачественных программ и БД отражает сегодняшние потребности нашего общества. Если они существуют, то на них есть спрос, хотя спрос скорее всего искуственный. Хочется верить, что существующее положение дел измениться.
Насчёт форумов и присутствия на них профессионалов. Я думаю, что профессионалы всё-таки больше работают, а не сидят целыми днями на форуме.
Vladimir Doubrovski (агент, Крым наш дом), 5 января в 18:16
Спасибо - в самою точку и вопросы и ответы.
Спасибо за профессионализм на профессионалах!
А форумы правильные, жаль не встретились там.
Андрей Архангельский (В поисках работы), 6 января в 10:05
Проблема в том, что "продавать волшебные палочки" много выгоднее, чем реальные продукты. Красивая коробочка, красивые интерфейсы, много рекламы и можно покупать виллу на Канарах.
Мои исследования показали, что по крайней мере в базах данных проблема заложена как в людях, которые развивали проблемы, так и в образовании сегодняшних студентов и специалистов. Это напоминает как весьма профессиональные математики исследовали алгебраические уравнения, разработали всю теорию (хорошо разработали), а уравнение в результате дает 1.5 землекопа.
Информатику и что такое информация никто и нигде не преподает.
Vladimir Doubrovski (агент, Крым наш дом), 6 января в 18:21
С образованием - проблемы как в средней так и высшей школе. По последнему замечанию: есть преподдаватели, а спецам за информатику нормально не платят.
Андрей Архангельский (В поисках работы), 6 января в 18:59
Я имею в виду, что то что называют информатикой таковой на самом деле не является. В Америке это называется более точно "компьютерные науки".
По настоящему информатика - это наука об информации и работе с информацией.
Любой программист среди ночи расскажет, что переменная существует в пределах области видимости, и в этой области она должна быть уникальной. Но как только дело переходит в реальный мир все это забывается. Журналист может спокойно выдать в эфир текст "Высокопоставленный чиновник Иванов сказал ..."
Кто сказал:
- Министр обороны С.Б.Иванов
- Министр иностранных дел Игорь Иванов
- зам. главы администрации президента В.Иванов?
Если в сообщении нельзя идентифицировать объект, то сообщение не несет информацию и является шумом.
Точно также в БД если нельзя идентифицировать объект, то все что к нему относится является мусором.
Программист же кроме операторов SQL ничего не видит.
К сожалению я сам был причастен к становлению такой информатики. В конце 80-х я консультировал управление информатики Мин. Образования СССР. Но мой вес по сранению с академиками Ершовым и Наумовым был несравнимо мал. То, что дается в сегодняших учебниках информатики в школе, иначе как бредом назвать нельзя. Институтские учебники пытаюсь отледить, но тоже ничего приличного не вижу.
Андрей Похилько (Руководитель отдела ИТ, Кыргызский Инвестиционно-Кредитный Банк), 8 января в 09:17
Уважаемый Андрей.

Спасибо за интересную дискуссию. Сам постоянно сталкиваюсь с подобными проблемами. Из Ваших ответов действительно непонятна Ваша цель. То-ли Вы занимаетесь саморекламой, то-ли Вы хотите, чтобы присутствующие здесь признали и посокрушались вместе с Вами, что информатике в мире не уделяется достаточно внимания.

Однако давайте сначала по существу. Мы недавно внедрили индийскую автоматизированную банковскую систему. АБС поставляется как БД (Оракл), плюс набор встроенных процедур.

Контроль целостности вводимой пользователем информации выполняется на уровне как ключей в таблицах, так и на уровне самого приложения. Есть также информация, которую формирует само приложение, однако там нет описанных Вами текстовых вариантов, поэтому такую информацию легче контролировать (и с ее целостностью и уникальностью все в порядке).

Разумеется, мы проводили тесты при внедрении. Однако, учитывая то, что мы - клиент, получающий готовое решение, то мы тестировали всю систему в комплексе. Дизайн базы, ключей и индексов нас не интересовал, постольку, поскольку пользователи напрямую с ней не работают.

Приведу пример ввода статической информации о клиенте банка. (ФИО, налоговые номера, адрес и т.п.)
При внедрении мы проводили тесты на контроль целостности вводимой пользователем информации о клиенте. Тесты были провалены и в то же время прошли успешно. Провалены, потому что в базовой конфигурации уникальность клиента проверяется только по двум полям - номеру клиента и его налоговому номеру. И в то же время они были пройдены успешно, потому что мы смогли изменить механизмы контроля и добавить нужные нам поля для контроля и их уникальности в том числе. Однако, текстовые поля мы не контролируем, именно по причинам, описанным Вами в Вашем предыдущем сообщении (один и тот же текст может быть записан разными способами). Контроль за правильностью и уникальностью ввода таких данных возложен на конечных пользователей и регулируется процедурно. Автоматизировать такое было бы слишком сложно.

Соотвественно, тут у меня возникает вопрос к Вам (этот вопрос все еще актуален для нас): как Вы видите себе контроль уникальности ТЕКСТОВОГО поля? Как БД (или приложение) может определить, что в базе уже введен клиент Иванов Петр Викторович и что второго такого клиента вводить нельзя? Или наоборот, как определить, что ООО МММ, ООО "МММ" и Общество с Ограниченной Ответственностью "Международные Маркетинговые Мчто-нибудь" - это одно и то же?

С уважением,
Однако
Андрей Архангельский (В поисках работы), 8 января в 10:10
1) Спасибо за Ваш ответ. Вы единственный, кто ответил на вопрос по существу, чего я собственно и добивался.
2) Здесь Vladimir Doubrovski уже предлагал создавать справочники.
Я немного уточню эту идею. В информационной БД достаточно много информации описывающей объекты реального мира. Эту информацию можно и нужно заложить в справочники, которые должен разрабатывать разработчик, пользователь не должен изменять эту информацию. За уникальность в справочнике отвечает РЕДАКТОР, специально обученный человек, эксперт в данной предметной области, который в добавок оснащен некоторым количеством специализированных инструментов для этого. Поставщик (разработчик) должен указать пределы, в которых обеспечивается уникальность.
Например, если Ваш банк работает в Москве, то вполне вероятно, что клиентом банка может стать любой житель Москвы и области. Значит для проверки уникальности необходимо ввести в БД 23 млн. реальных записей. Если банк хочет иметь филиалы по всей России, то возможно что уникальность основанная на полях "Фамилия, Имя, Отчество, 2 имя, дата рождения" окажется недостаточной и необходимо ввести еще какой-либо признак. Если банк хочет иметь филиалы в других странах, то возникает дополнительная проблема а) с языком, б) транскрипцией с языка клиента на основной язык банка.
Все это должно быть описано в ТЗ, в выходной документации и в методике тестирования.
Кроме того, даже когда имеется эталонный справочник, оператор все равно может ошибится - а) по невнимательности, б) данные передаваемые голосом или письмом не всегда несут ПОЛНУЮ информацию. Следовательно должен быть механизм уточнения введенной информации.
Например, есть
мужская фамилия мАлин (склоняется) и женская фамилия мАлина (склоняется)
и
мужская фамилия малИна (не склоняется) и женская фамилия малИна
Следовательно, в уникальность фамилии должно входить ударение и возникают дополнительные вопросы - как это отобразить в интерфейсе, как это отобразить в документе и так далее.
Естественно, что в выходной документации должны быть описаны система прав доступа к этим и другим объектам. В выходной документации должна быть описана процедура, что должен делать оператор если в справочнике отсутствует необходимое значение.

Я пока изучил не далеко не все.
Я хорошо представляю как обеспечивается уникальность объекта "Персоны", сейчас ведутся статистические исследования, осталось несколько проблем, которые я знаю, но пока не решил.
Я достаточно хорошо представляю себе как обеспечивается уникальность объекта "Товары", но многие проблемы не имеют решения на уровне разработчика почтому что определяются правительством и фирмами-изготовителями.
Я представляю проблемы по объектам "Юридические лица" и "Адреса", есть некоторые наметки по их решению, но мои возможности ограничены (я работаю один, все мои заказчики в ответ на эти проблемы крутят пальцем у виска и говорят - я за это платить не буду)
Поэтому я и задаю эти вопросы на форуме, чтобы узнать - это только у меня проблемы или кто-то еще с этим сталкивался. Из всех 20 форумов только Вы ответили по существу.
Андрей Похилько (Руководитель отдела ИТ, Кыргызский Инвестиционно-Кредитный Банк), 8 января в 10:42
Спасибо, однако я в этой области больше потребитель, а не разработчик, поэтому, возможно, и написал :)

То есть Вы действительно хотите контролировать уникальность и правильность ввода текстовых полей? Это будет очень сложной задачей по двум причинам:
1. Элементарно пользователь может ошибиться при вводе данных. Как это проконтролировать? То есть даже после внедрения механизмов контроля мусор в базе будет оставаться со всеми вытекающими. Опять же, если полагаться на автоматику, то ошибок будет еще больше.
2. Целесообразность с точки зрения владельца бизнеса будет невысокой. Проще мириться с некоторым количеством мусора в базе клиентов и другой статической информации (в нашем случае количество мусора составляет около 2%), чем платить кругленькую сумму за ввод дополнительных механизмов контроля, которые вряд ли принесут действительно ожидаемый эффект.
Андрей Похилько (Руководитель отдела ИТ, Кыргызский Инвестиционно-Кредитный Банк), 8 января в 10:53
А по поводу Вашей идеи №2 могу сказать, что да, действительно, мы могли бы использовать реальные справочники. То есть, если я правильно понял, покупаем у некой третьей организации справочник всех физ.лиц со всеми нужными нам данными, и загружаем его как есть в нашу БД?

В этом случае также есть сложности:
1. где гарантия, что этот справочник является верным?
2. люди меняют информацию о себе, и может возникнуть ситуация, когда у банка будет более полная и обновленная информация о человеке, нежели в начальном справочнике. Как следствие, необходимо разрабатывать механизмы обновления справочников, опять же, вводить данные, что опять же приводит к риску ошибки.
3. Все равно есть информация, которую банк генерирует независимо (номера счетов, платежные документы и т.п.)
Андрей Архангельский (В поисках работы), 8 января в 12:07
1) Во-первых любая информация имеет несколько уровней.
- реальные фамилии, имена, отчества
- реальные идентификаторы физических лиц (это можно распространять без опаски, т.к. это только Фамилия, Имя, Отчество, дата рождения, но гарантируется что такой человек есть
- персональная информация о физическом лице - сбор и распространение ограничивается законом.
Вообще в идеале, такая информация должна собираться в точке ее возникновения и изменения, например МВД. А БД, например банковская система использует только централизованный идентификатор и в любой момент может запросить актуальную информацию у источника. Но это мечты - в МВД отсутствуют минимально грамотные люди (есть достаточно много знакомых) и, тем более, там нет понимания что такое информация вообще.
2) Для начала считаем, что у нескольких банков информация представлена в унифицированном виде, тогда банки могут выбрать "хранителя информации" и осуществлять обмен информацией в пределах группы по определенной процедуре. Выгода от этого очевидная.
3) Вся информация имеет различные уровни по правам доступа. Если ее проанализировать, то можно выделить довольно значительную часть, которой можно обмениваться. Довольно значительная часть может быть секретной, но ее формат унифицированным и в своей структуре иметь некоторые способы по защите от ошибок. Я просто пытаюсь доказать, что вложив силы и средства в первоначальный анализ информационных объектов можно значительно сократить будущие потери от скрытых ошибок. Сегодня, как это следует из учебников и реальных проектов, которые я видел и изучал, берется первое попавшееся решение в лучшем случае основанное на анализе бизнес-процессов и строится некоторая архитектура в терминах бизнес-процессов. Как результат - БД Федерального Медицинского Центра при Управлении делами Администрации президента - Врач и пациент - это разные люди. Врач не может быть пациентом. Нет разделения по правам доступа к диагнозам (а это уголовное преступление), а заказчика интересует более красивый интерфейс.
Андрей Архангельский (В поисках работы), 8 января в 11:45
1) Давайте разберемся в чем может ошибится пользователь (назовем его оператором):
- У нас есть справочник правильных фамилий (имен, отчеств), которому мы доверяем.
- оператор может выбрать только правильные фамилии (имена, отчества) - сам вводить он ничего не может.
- оператор может ошибочно (возможно) выбрать вместо одного правильного имени другое. Например,
Ренат/Ринат - вероятность 50/50
Наталья/Наталия - вероятность 99/1
и так далее.
Значит система должна предложить оператору выбор из нескольких правильных имен, дав в качестве дополнительной информации статистику и возможно по дополнительному запросу историческую справку. Значительная часть ошибок относится к классу "1 символ пропущен,изменен, добавлен". Таблица ошибок такого вида очень легко генерируется. Плюс добавляются неочевидные ошибки типа - Георгий/Григорий. Реально оператору предлагается выбор максимум 4-5 вариантов, но это заставляет его задуматься и переспросить клиента.
2) Если один маленький владелец будет внедрять эту систему, то для него это будет дорого. НО! Многие объекты универсальные. Много ли Вы знаете информационных систем, в которых нет объекта "Персоны"? Следовательно, если разделить эту стоимость на достаточно большое количество копий, то он может ее незаметить.
3) Ошибочное представление о мусоре в БД, как о бытовом. Мусор в БД - это доверие к получаемым данным. Вы ведь не знаете правильные данные, которые Вам дает БД или нет. Один пример из Роберта Гласса:
"Уважаемые члены комиссии по расследованию, всю неделю самолет был исправен. Просто в середине Индийского океана на три минуты прекратилась подача топлива. Предполетную проверку самолет прошел в полном объеме"
Ваша БД работает как этот самолет, просто в один момент она выдаст недостоверную информацию и Вы должны просчитать свои потери от этой ошибке. Но в отличие от самолета, Вы не знаете какая информация верная, а какая нет.
Андрей Похилько (Руководитель отдела ИТ, Кыргызский Инвестиционно-Кредитный Банк), 8 января в 12:53
1. То есть Вы будете предлагать на продажу готовую базу всех жителей России? В этой базе одна строчка будет иметь реквизиты ФИО, паспортные данные, адрес прописки, адрес фактического проживания, номер соцфонда и т.п.?
А как быть с жителями, которые не являются гражданами России?

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

2. Внедрение такой системы многим клиентам потребует индивидуального подхода к каждому. Каждому заказчику надо будет интегрировать эту систему с его имеющейся системой (у всех стоят разные, да еще и кастомизированные). Поэтому затраты будут большими в любом случае.

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

Критичны ошибки в финансовых данных, но они не являются следствием ввода текстовых данных, и подход к их контролю в корне отличается от обсуждаемого здесь. Опять же такой контроль легче реализовать, поскольку там нет текстовых полей.
Андрей Архангельский (В поисках работы), 8 января в 13:33
1) Я не могу (не имею права) предлагать на продажу персональные данные. МВД может предоставить доступ к такой информации при определенных условия.

Можете мне поверить на слово что получить справочник правильных фамилий много легче, чем перепроверить паспортные данные в многомиллионном справочнике. Делал то и другое. В БД "Прописка Москва и МО 2005г" (23 млн. записей) реально удалось только по ФИО вычистить 3 млн., остальные без правильного справочника ФИО можно отнести к мусору. Есть например и такие - Иванов Анастасия Георгиевич.
Из того что удалось вычистить - 20% мусор. Например, человек 1 раз переехал и 1 раз поменял паспорт по закону 1999 года. На этого человека 89 записей - которая из них верная неизвестно. Рекорд - на 1 человека 1536 записей.
БД по фамилиям, именам и отчествам собирается из биографических справочников (они более надежны). Из последнего справочника было добавлено 3205 новых персон, при этом новых фамилий - 33.8%, новых имен - 6.7%, новых отчеств - 6.8%. При этом указанные проценты имеют сильное стремление к 0.
2) Внедрение к существующим системам действительно вызовет значительные проблемы. Но новые системы разрабатываются на таких же принципах как старые. И вот в новых системах пора изменить принципы.
3) Я согласен, что банковские системы имеют меньше подобных (информационных) проблем, хотя бы потому что многие идентификаторы генерируются внутри системы. И в этом случае АБС стоят особняком. Но есть еще множество других информационных систем, для которых это критично или важно.
Антон Агальцов (руководитель отдела, ГК ), 8 января в 23:16
добавлю пару замечаний по реализации такой базы данных в России:

1) Чтобы завести такую базу данных требуется автоматизировать большое количество предприятий (паспортные столы, загсы, аэропорты, вокзалы и т.д. и т.п.) при этом замечу что эти предприятия и контролируют заполнение справочников верными данными.

2) Не забывайте про безопасность такого справочника. Методологически сложно представить систему прав доступа которая бы 100 процентов решала проблему. Тоесть как пример:
Загсу нужны паспортные данные всех людей. Попасть за компьютер загса не сложно. А написать скрипт который будет тащить из базы данных нуобходимую информацию проблем не составит.

Если отсечь данные которые не нужны мошеникам (или кому они еще нужны в грязных целях), то данные справочники по большей степени будут не нужны и бесполезны.

3) мой Вам совет: прежде чем начинать работу по подобным системам оцените необходимость и возможность ее внедрения где либо. Я понимаю что рассматривать данную систему в масштабах страны не совсем правильно и бесполезное занятие не зная всех процессов. Возможно ее следует применять на круппных предприятиях. Но большие конторы пишут свою БД со своими справочниками (для своих нужд) под свои бизнес-процессы.

P.s.: В свое время профессор в институте рассматривал такую схему работы БД которую вы приводите в данной дискуссии, проблема лиш в том что данные БД разрабатываются под определенные процессы, а сделать унифицированную практически утопично.
Роман Камалов (Самозанятое лицо), 8 января в 13:01
С точки зрения философии электронный мир это отражение реального. Если в реальном мире есть неверная информация, то она обязательно будет в электронном. По другому просто не может быть. Как гласит пословица "Нечего на зеркало пенять, коли морда крива".
Аркадий Куров (Менеджер по развитию ИТ-систем, ОАО "Вымпелком"), 12 января в 23:23
Ответ на вопрос - не тестируем.

"Одна администратор баз данных, которая разрабатывала БД под Oracle 10 лет, БД объемом 30-50 млн. записей, по женски ответила на вопрос вопросом - А ЗАЧЕМ?" - почему именно по-женски? Я тоже не понимаю смысла в тестировании самой БД, это некий "сферический конь в вакууме", практического применения не имеет.

Архангельский Андрей





Дата последнего изменения:
Thursday, 21-Aug-2014 09:11:43 MSK


Постоянный адрес статьи:
http://az-design.ru/Projects/AzBook/TestDB/20081231_Prof.shtml