Девяносто пятый год, пишем систему отображения результатов выбора в ГосДуму с использованием иерархической СУБД OpenM (папа Cache). В ходу такие понятия, как "ствол", "ветви" и "листья". Двое коллег обсуждают структуру базы данных:
— А давай-ка мы каждого кандидата в депутаты повесим на отдельной ветке!...
Не спорьте со специалистом по БД. Он знает толк в оптимизации иерархических структур!
Коллега-админ «сходил налево» — настроил кому-то на стороне Oracle. Через два дня пошли жалобы — по вечерам сервер недоступен, подключится невозможно. Коллега почитал логи, очень удивился: по всем признакам это был не сбой, а именно что плановое выключение СУБД в штатном режиме. Коллега начал задавать вопросы и удивился еще сильнее.
Местные кулибины решили, что важные данные следует резервно/архивно копировать. Желательно ежедневно. Поэтому в шесть часов вечера некто, ответственный за сервер, останавливал Oracle и архивировал весь каталог с датафайлами.
Слова «резервное копирование» и «архивация» все знали, а вот про «экспорт» и «дамп» никто из сотрудников не слышал.
У нашей конторы есть небольшие (машин на двадцать) представительства в разных городах, и там, естественно, нужно поддерживать и обслуживать IT-инфраструктуру.
Работает на компьютерах жутко секретный софт, местных админов приглашать никто не торопится, и мне приходится мотаться из одного города в другой, чтобы работа нигде не встала. В последнее время вместо меня занимается этими функциями пара молодых, толковых эникейщиков.
Раздаётся часа в три ночи звонок от одного из бойцов, поехавшего в филиал устанавливать софт: «Ничего не работает». Для запуска программы нужно было настроить базу данных, до этого юный эникейщик ни разу этим не занимался, так что отправился на задание с кучей распечатанных руководств.
После непродолжительного анализа я понимаю, что движок не может найти файл с самой базой данных. Естественно, командую ему проверить файл с путями к файлам. Боец рапортует: «Всё тут правильно».
Через пару часов, когда уже были перепробованы все возможные попытки исправить ситуацию и я, тупо уставившись в свой монитор, думал о своей нелёгкой участи, это чудо позвонило и выдало уникальную фразу: «Может, не недо было перед строчкой с адресом базы ставить решёточку?». Я пытался найти подходящие к ситуации слова, но в итоге просто бросил трубку.
В итоге успокоился, перезвонил и поддтвердил его догадки. Эникейщик посмотрел на комментарий в начале конфиг-файла и решил, что так и надо.
В работе с базами данных не силен, но попросили написать простое приложение для обработки-хранения заявок от клиентов и последующей печати накладных и маркировочных наклеек. Кое-как вспомнил, что мы проходили год назад по предмету "Базы данных". Набросал малюсенькую фаербердовскую базу. Ваяю клиентское приложение (все команды к базе данных генерируются через OLE DB провайдер, так как SQL тоже слабо помню).
Все таблицы нормально обрабатываются - грузятся, строки добавляются и удалаются. А с одной таблицей не заладилось - выгружается она нормально, а обновляться не хочет. И самое главное - процедура-то та же самая, что и для обработки других таблиц. Два дня бился, очень переживал, много курил, так как хотелось поскорее доделать и взяться за лабораторные, которых к сессии еще очень много сдавать, а Новый год уже близко. В итоге, решил для локализации ошибки создать совсем пустую базу с единственной таблицей, полностью скопировав структуру той злополучной таблицы. Но IBExpert не дал мне ее скомпилировать - он ругался на поле с названием DATE и выдавал мне тот же номер ошибки, что и мой клиент. Назвал поле O_DATE и все отлично - таблица компилируется, клиент добавляет и удаляет записи.
Наверное, если бы я исправно ходил на лекции по соответствующему предмету, я бы знал, что нельзя использовать в названиях колонок зарезервированные имена.
P.S. Если добавлять эту дурацкую колонку к уже существующей таблице - вас ждет успех и никаких ошибок при ее создании вы не увидите.
Полгода назад работал в одной маленькой веб-студии. Программистов было двое: я и ещё один юноша. Юноша - студент, но толковый и нелепых ляпов не допускал. До поры.
Как-то раз сидит, пишет что-то, ругается сквозь зубы. В конце концов зовёт меня. Запрос, говорит, не работает. Я ему советую распечатать запрос - сразу, мол, поймёшь, что не работает. Распечатывает, вставляет в phpMyAdmin. Работает!
Я, немного офигевши, иду смотреть на это чудо. Действительно, в скрипте запрос сбоит, а в phpMyAdmin'е работает за милую душу. Лезу в исходник. Смотрю на строку, где формируется запрос, и начинаю сползать под стол. Строка выглядит следующим образом:
$query = "SELECT * FROM ..."
Зачем, спрашиваю? На что он мне так основательно отвечает: на всякий случай, мол, мало ли что...
Очень давно работал на одном предприятии, единственной особенностью которого являлась строжайшая отчетность - приняли, обработали, списали. Меня, после исправления "ненужных" функциональностей 1c, кинули на забивку базы со старого формата (что-то там на FoxPro) на новый и "красивый" 1с. Работы мало, а деньги капают. В начальниках только главбух. Лафа.
Заполняю базу. Идет одна проводка (бумажка) - 20 выключателей X1Y1, 23 выключателя X2Y2, провода Z1T1... наименований штук 20. Ищу в старой базе - нет. Смотрю число и номер проводки - есть. И значится только одно наименование - "энергокомплект". Не понимаю. Смотрю в проводку - 20 наименований, а сверху большими жирными буквами написано название предприятия - "энергокомплект".
Так как есть проводка на прием, то значит (если было дело давно - скорее всего) будет акт списания. Ищу и нахожу: от электрика - акт списания. Бла-бла-бла "списывается энергокомплект".
Поднимая историю, выяснил следующее - электрик использовал пару розеток из "энергокомплекта", они благополучно сгорели. Электрик заявил, что такие-то розетки утрачены. А бухгалтерия, не найдя записи "розетки", списала полностью наименование "энергокоплект" - т.е. 20 реальных наименований и т.д.
После этого "по характерным признакам" были обнаружено около 10 аналогичных ошибок. Мне так кажется, у нас половину государства так списали.
Работал над одним проектом, который до меня делали другие. Проект достаточно большой, и одна из его частей считывает некоторые данные с базы. Есть возможность регулировать дату от и до при считывании. Возникла проблема, из-за которой клиент очень ругался. Если промежуток от и до очень большой, к примеру кто-то захочет считать данные за несколько лет, то скрипт работает нереально медленно, а иногда даже выдаёт таймаут.
Бились над проблемой 3 дня, перелопатили кучу кода, даже нашли некоторые другие баги, которые не имели отношения к проблеме. В итоге наткнулся на кусок кода в том месте, где искать никто просто не додумался:
$res = $DB->getData($query); //считывает данные с ДБ и загоняет в пронумерованный массив $data = new array(); foreach ($res as $key=>$value) { if (!$data[$key]) $data[$key] = $value; };
Все это вместо простого $data = $res; Что имел ввиду кодер, родивший это чудо, так и осталось загадкой.
Проходила в свое время живая ролевая игра по "Дозорам" Лукьяненко.
К этой игре была написана база данных, в которой хранились всякие документы, досье на именных персонажей, описания древних ритуалов (игровых, естественно) и прочее. Если кто не помнит, по Лукьяненко, Ночной Дозор иногда выдает вампирам лицензии на питье крови людей. Так вот, эти лицензии тоже хранились в базе.
Проблема была в том, что проектировщик базы случайно перепутал в коде поля "кем выдана лицензия" и "на кого выдана лицензия". Поэтому все вампиры Дневного Дозора в первый же день изумленно переглядывались, держа в руках бумажки за подписью всяких Васей Пупкиных и Дусь Губкиных, в которых же было означено, что вампирам разрешается однократное выпивание крови начальника Ночного Дозора г. Москвы мага вне категорий Гесера.
Работал я программистом на VFP в начале трудовой деятельности.
В один прекрасный момент мой принтер (расшаренный по сети) начал получать постоянно запросы на печать. Бумагу клали только тогда, когда нужно было печатать (просто так не лежала), поэтому принтер постоянно шуршал и жаловался на отсутствие бумаги. На третий день всему кабинету это изрядно надоело, и было принято решений покормить зануду бумагой, чтобы понять, чего он хочет. В результате мы получили распечатку экономического отчета.
Вот тут-то я в ступор и впал. Ко мне шли мной же разработанные отчеты на VFP, которые я как раз сдал 4 дня назад людям, удаленным от нас на 5 км и имеющим модемное соединение с нами. Мистика!
Но все выяснилось, когда мне позвонил один из заказчиков и пожаловался, что отчеты не печатаются. Оказалось, что в инструменте Report в VFP был переключатель, на который никто внимания не обратил, "сохранить окружение принтера" (save printer envirountment). И поэтому из любого места сети, где был виден мой принтер, экономисты отправляли на него отчеты.
