Поделиться

суббота, 1 октября 2011 г.

Жизненный путь: О СУБД и мучениях

Довелось тут в очередной раз попотеть над базой данных, а именно - над "Базой данных опасных и неблагоприятных процессов и явлений на территории Красноярского края". Бывает иногда производственная необходимость реализовать что-то не на языке программирования, а в рамках какого-то приложения (в основном это как раз приложения из группы Office - Access, Excel, Outlook, Visio). База была не то, чтобы слишком уж хитрая, но и не простейшая: пять таблиц, связи многие-ко-многим, каскады, целостность и т. д. Еще пришлось карты Google к ней подключать - для визуализации, так сказать, географического положения населенного пункта.

Обматерился. Я недавно высказался в пользу языка C# в таком ключе:

Я работал с C и С++, я работал с VB. Конечно, поскольку я не работаю в области создания ПО постоянно, а только время от времени, я многое забыл. Но того, что я помню, как раз хватает для эффективной работы в C#, поскольку он требует от меня как раз совмещения этих небольших, но системных воспоминаний. Даже удивительно...

С Access-ом ситуация другая. Я бы сказал, прямо противоположная. Кажется, ничто не способно подготовить человека к работе в Access-е: ни опыт разработки в Paradox-е, Clipper-е и FoxPro, ни знания в области теории СУБД и реляционных БД. И, что самое удивительное, опыт работы в нем самом, похоже, тоже не может подготовить к работе с ним самим. Да, с Access-ом я тоже сталкиваюсь на жизненном пути время от времени, и да, я и о нем многое забываю в промежутках, когда не сталкиваюсь, но все же: я читал книги, я имею опыт программерства на VBA, и все такое. Тщетно. На поверку выходит какая-то аномалия: какое бы решение я ни принял, какое бы свойство ни принял за нужное мне, наличие или поведение какой бы функции я ни предполагал - каждый шаг оказывается неверным. Каждый!

Немало способствуют этому и проектировочные и конфигурационные решения, заложенные в сам Access:
  • Кому пришло в голову переводить названия свойств? То есть кто тот человек, который сказал, что в русском Access-е свойства должны называться по-русски? Ё-моё, это же VBA - туда нормальный пользователь и лезть-то не должен.
  • Ладно, нормальному пользователю помимо использования готовых форм и отчетов может понадобиться поднастроить что-то. Но контекстную справку-то можно было выпрямить под это, хотя бы? Она же кривая, как бублик Мёбиуса.
  • В Access-e есть десяток способов сделать что-то одно... а нужен один. Такое впечатление, что сидел себе программист и создавал конструктор форм и отчетов в СУБД. Через плечо ему заглянул кто-то, кому мне очень хочется зла, и сказал: "Конструктор - это, конечно, хорошо, но давай еще сделаем режим макета". Программист согласился и принялся за работу (так толком и не доделав конструктор). Потом через его другое плечо заглянул еще один товарищ, которому я тоже добра не желаю, и заметил: "Слушай, нужны еще мастера - пользователь их любит"! И снова согласился программист, и снова переключился на разработку новых фишек, не доделав режим макета (который вообще лишний, на мой взгляд). Вот в итоге и получилось: создаешь поле со списком в режиме мастера, мастер тебя спрашивает: "У вас будет фиксированный набор значений, набор значений из таблицы или значение в поле будет использоваться для поиска записи в форме"? Да ситуации, когда необходимы сразу второй и третий варианты, встречаются на каждом шагу: например, значения в списке поступают из таблицы, и на основании выбранного значения нужно сделать перезапрос в подчиненную форму. Ну ладно, думаешь, исправлю / доделаю руками. Не тут-то было. Как было сказано выше, в Access-е десяток способов сделать что-то одно (фильтры, запросы, макросы, сценарии - это так для примера, всеми этими способами можно поменять то, что отображается на форме, причем одновременно), и какой из способов выберет тот или иной мастер - неизвестно. Вот и начинаешь плутать. Плутать можно часами.
  • Сообщения об ошибках - это притча во языцых. Представьте: у вас форма с двумя вложенными друг в друга подчиненными. Что-то меняем, сохраняем, открываем в режиме формы, пытаемся что-то изменить в данных... Бац! "У вас где-то в каком-то индексе ошибка!" - радостно заливается Access. Пять таблиц, десятки полей, десятки индексов. Где искать-то? Я когда работал системным аналитиком и техписателем, в нашей системе дистанционного обучения часто выскакивало сообщение "Системная ошибка", после чего ничего не происходило. Ну, кто хорошо знает исключения или знает их не очень хорошо, тот понимает, когда появляются в превеликом множестве и непредсказуемых местах такие вот безликие ошибки. По-моему (я сам исключения ненавижу, они для меня, как парадокс Монти-Холла - я способен их постичь, но через 5 минут уже не могу сказать, почему оно работает, так что, надеюсь, более грамотные коллеги поправят меня, если я ошибаюсь), это происходит чаще всего тогда, когда в один блок try заключается здоровенный кусок кода с вызовами всяческих функций или просто текст функции main(), а в catch(...) прописано отображение вот такого сообщения. Это означает: что бы и где бы ни случилось, результат будет одинаковым и диагностировать такую ошибку с целью исправления можно только одним путем - воспроизвести ситуацию, когда ошибка возникла, что далеко не всегда легко и даже возможно, в особенности если ошибка возникла на стороне клиента. "У нас выскочила ошибка"! "Какая"? "Системная ошибка"! "А что вы делали"? И дальше рассказ о том, что делал сотрудник клиента в момент, когда появилось сообщение, что он делал до этого (с утра), и что делали все остальные сотрудники клиента. Я "в детстве" тоже любил писать код наподобие:

    Public Sub foo()
    On Error GoTo ErrorHandler
       (some action)
    ErrorHandler:
    End Sub

    но уж никак не мог предположить, что такими же вещами занимаются разработчики Microsoft Office-а.
В общем БД, конечно, была реализована, получилось довольно симпатично. Однако я серьезно думаю, какое бы средство с меньшей фунциональностью и заморочками взять в качестве платформы для разработки базы в следующий раз. Больше всего из СУБД мне, в свое время, полюбился Clipper - исключительно теплые воспоминания.

6 комментариев:

  1. "Довелось тут в очередной попотеть над базой данных"

    и да.. помню я эти мучения ещё по старому аксессу..
    ещё даже на начальном уровне обучения и работы..
    что уж говорить про что-то более глубокое и масштабное..

    ОтветитьУдалить
  2. Я с ужасом вспоминаю лабораторные работы дисциплины "Базы данных" в акцессе.
    Это было что-то с чем-то.
    Больше я к акцессу не притрагивался.

    ОтветитьУдалить
  3. Ну а мне приходится иногда БД разрабатывать, и первая мысль: "Access", потому что он ближе всего. И все равно год от года поражаюсь.

    ОтветитьУдалить
  4. ты ошибку, мною указанную в первом комменте
    в кавычках, исправишь, или нет?

    ОтветитьУдалить
  5. Не надо катить баллоны на Аксесс! Это отличный инструмент для разработки пилотных проектов - и СУБД, и среда разработки, и отладка, все в одном флаконе! Руки надо прямые иметь. Тоже мне, "программисты"...

    ОтветитьУдалить
  6. Руки - ничьи, никогда не бывают абсолютно прямыми, в чем-нибудь они обязательно кривоваты, хотя дистанционно оценивать кривизну моих рук - это перебор. То же верно и по отношению к средам разработки - есть совершенно конкретные минусы в Access (и я их привел), которых могло бы уже за столько лет и не быть, и вижу я их не в первый раз, не первый год, не в первой версии и, кстати, на практике, а не теоретически и не дистанционно. Что касается того, что Access - это "все в одном флаконе", я совершенно согласен - это прекрасно. И в отношении пилотных проектов согласен, но проблемы начинаются не на пилотных проектах, а на промышленных.

    ОтветитьУдалить