Базы данных

Дело было давно — я работал программистом в сфере разработки банковского софта под Oracle версии 7 или 8.

Звонят как-то из банка с проблемой. После разбирательств выяснилось, что надо кое-что подкрутить от «супер-юзеров» sys или internal, о чём я и сообщил. Трубку положили на стол, но связь была хорошая и диалог банковских айтишников был прекрасно слышен:

— Какой пароль у internal на боевой базе?
— «change_on_install»!

Работаю в небольшой конторке, занимаемся поставкой различной съедобной продукции.
Имеем две базы 1С: одна управленка, а другая чисто бухгалтерия. И так уж вышло, что директория с бухгалтерией находится в директории базы-управленки. Всё это бэкапится хорошей (на мой взгляд) программкой-бэкапером.

Спустя некоторое время пришлось переселить управленку на SQL, а бухгалтерию оставить, как было, в файловом хранении, в той самой папочке со старенькими файликами управленки. Настроили бэкапер на бэкап скульной базы и отключили бэкап старой, файловой базы, позабыв о работающей бухгалтерской.

Сегодня утром, главный бухгалтер что-то не то выгрузил и загрузил в свою базу. И, конечно же, сразу обратился ко мне, чтобы я восстановил свеженький бэкапчик. Но как только я понял, что речь идёт о той самой базе, которую удалил из задач бэкапера ещё неделю назад, я упал в осадок. Перед тем как расстроить бухгалтера, решил глянуть, за какое число есть последний бэкап. Как же велико было моё удивление, когда я увидел, что последний бэкап той самой базы был сегодня! Все счастливы, все рады.

Спасибо бэкаперу, что вовремя заглючил и продолжил делать свою работу несмотря на то, что правило уже давно было удалено.

Работаю в одной госконторе в центральном офисе. В мои обязанности входит проверка XML-файлов, присылаемых филиалами, для последующей отправки дальше по «пищевой цепочке». Особенность проверки заключается в том, что эти файлы приходится отсматривать вручную — открывать, проглядвыать содержимое и при необходимости править. Для учёта файлов программисты написали утилитку.

Каждый месяц мы сдаём отчёт о проделанной работе, чтобы получить в итоге свои кровные. С появлением программы учёта мы решили, что со встроенной статистикой составлять отчёты будет проще — ан нет! То ли кодеры поленились, то ли программа подглючивала — у пользователей статистика не работает. Иду к ведущему программисту: «Женя, открой базу данных и дай мне количество файлов, проверенных за месяц». Он кивает и приступает.

Разговорился с админами. Краем уха слышу, как Жека что-то бубнит под нос. Наверное, думаю, мантры программерские читает. Поворачиваюсь и вижу, что это чудо, отсортировав строки по датам, с помощью стрелки «вниз» пересчитывает строки вручную. Долго смеялись, но он их всё-таки пересчитал — когда статистику в итоге починили, количество сошлось.

Изучаю чужую БД и вижу поле (bool) IS_FEMALE. Зову товарища и восхищаюсь нетипичностью решения.

— Обычно это поле называется SEX и значение «true» закреплено за мальчиками.
— И действительно, почему это мужчины — «тру»? Хотя в некотором смысле логично обозначать мальчиков единичкой, а девочек — ноликом.

Сам же создатель же схемы так прокомментировал этот диалог: «Логическое поле должно быть названо так, чтобы значение трактовалось однозначно — например, HAS_PENIS. Так как базу будут читать приличные люди, назвали IS_FEMALE».

В этой базе мне до сих пор копаться приятнее, чем в большинстве остальных.

Работаю программистом 1С — в основном занимаюсь чисткой, оптимизацией и восстановлением работоспособности баз данных.

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

Начинаю думать. Вариантов рабочих два: первый состоит в том, что есть ошибка в алгоритмах пересчёта сумм. Маловероятно, тем не менее проверяю и, естественно, ничего не нахожу.

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

Вечером на грани нервного срыва сажусь за терминал и раскуриваю трубку. Через клубы дыма смотрю на клавиатуру и чуть не плачу.

Кто-нибудь видел, как работают операторы со стажем? Пальцы мелькают с фееричной скоростью, для ввода цифр используется, как правило, цифровая клавиатура. Клавишей Enter в 1С пропускают поля, не нуждающиеся в ручном заполнении. А что рядом с энтером? Правильно — тройка.

Девяносто пятый год, пишем систему отображения результатов выбора в ГосДуму с использованием иерархической СУБД OpenM (папа Cache). В ходу такие понятия, как "ствол", "ветви" и "листья". Двое коллег обсуждают структуру базы данных:

— А давай-ка мы каждого кандидата в депутаты повесим на отдельной ветке!...

Не спорьте со специалистом по БД. Он знает толк в оптимизации иерархических структур!

Коллега-админ «сходил налево» — настроил кому-то на стороне Oracle. Через два дня пошли жалобы — по вечерам сервер недоступен, подключится невозможно. Коллега почитал логи, очень удивился: по всем признакам это был не сбой, а именно что плановое выключение СУБД в штатном режиме. Коллега начал задавать вопросы и удивился еще сильнее.

Местные кулибины решили, что важные данные следует резервно/архивно копировать. Желательно ежедневно. Поэтому в шесть часов вечера некто, ответственный за сервер, останавливал Oracle и архивировал весь каталог с датафайлами.

Слова «резервное копирование» и «архивация» все знали, а вот про «экспорт» и «дамп» никто из сотрудников не слышал.

У нашей конторы есть небольшие (машин на двадцать) представительства в разных городах, и там, естественно, нужно поддерживать и обслуживать IT-инфраструктуру.

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

Раздаётся часа в три ночи звонок от одного из бойцов, поехавшего в филиал устанавливать софт: «Ничего не работает». Для запуска программы нужно было настроить базу данных, до этого юный эникейщик ни разу этим не занимался, так что отправился на задание с кучей распечатанных руководств.

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

Через пару часов, когда уже были перепробованы все возможные попытки исправить ситуацию и я, тупо уставившись в свой монитор, думал о своей нелёгкой участи, это чудо позвонило и выдало уникальную фразу: «Может, не недо было перед строчкой с адресом базы ставить решёточку?». Я пытался найти подходящие к ситуации слова, но в итоге просто бросил трубку.

В итоге успокоился, перезвонил и поддтвердил его догадки. Эникейщик посмотрел на комментарий в начале конфиг-файла и решил, что так и надо.

В работе с базами данных не силен, но попросили написать простое приложение для обработки-хранения заявок от клиентов и последующей печати накладных и маркировочных наклеек. Кое-как вспомнил, что мы проходили год назад по предмету "Базы данных". Набросал малюсенькую фаербердовскую базу. Ваяю клиентское приложение (все команды к базе данных генерируются через OLE DB провайдер, так как SQL тоже слабо помню).

Все таблицы нормально обрабатываются - грузятся, строки добавляются и удалаются. А с одной таблицей не заладилось - выгружается она нормально, а обновляться не хочет. И самое главное - процедура-то та же самая, что и для обработки других таблиц. Два дня бился, очень переживал, много курил, так как хотелось поскорее доделать и взяться за лабораторные, которых к сессии еще очень много сдавать, а Новый год уже близко.
В итоге, решил для локализации ошибки создать совсем пустую базу с единственной таблицей, полностью скопировав структуру той злополучной таблицы. Но IBExpert не дал мне ее скомпилировать - он ругался на поле с названием DATE и выдавал мне тот же номер ошибки, что и мой клиент. Назвал поле O_DATE и все отлично - таблица компилируется, клиент добавляет и удаляет записи.

Наверное, если бы я исправно ходил на лекции по соответствующему предмету, я бы знал, что нельзя использовать в названиях колонок зарезервированные имена.

P.S. Если добавлять эту дурацкую колонку к уже существующей таблице - вас ждет успех и никаких ошибок при ее создании вы не увидите.