Пишу, по большей части, про историю, свою жизнь и немного про программирование.

Анализатор БД

Целый день бьюсь с базой данных Testlink, пытаюсь найти путь как связать test case и его версии. Так как внешних ключей, описания базы и моделей нет, чувствую себя, как в лабиринте — где-то есть выход и мне его надо найти. Но не получается. Есть таблица «A», есть «B», есть «A_B», в «A_B» есть «A_id» и «B_id». Вроде все ясно — две таблицы и таблица связей. Ан нет, не работает, не связываются данные.

Очень хочется анализатор БД, который взял бы лог запросов SQL и построил бы по нему связи между таблицами. Самому написать времени нет, да и, может, готовый уже есть. Может кто знает? А то я за целый день проблему так и не победил, по коду смотреть — тоже тот ещё квест.

Добавлено 18 декабря 22:10: перед уходом домой я разобрался, что всё связано через другую таблицу.

Для конкретики: есть таблицы tcversions, testplan_tcversions и testplans.

В testplan_tcversions есть поля testversion_id и testplan_id. Поле testversion_id указывает в таблицу tcversions, но поле testplan_id не указывает на testplans. Оно указывает в таблицу nodes_hierarchy, ту да же указывает id у tcversions, а связь между ними осуществляется через дерево внутри nodes_hierarchy.

Кажется, так всё работает. Это мне ещё предстоит выяснить в понедельник, а сейчас я домой пойду.

8 комментариев
www.livejournal.com/users/_saper_/ 2009

Ууу, я бы за такую штуку много отдал, у нас биллинг из коробки, много труда ушло чтобы выяснить что в нём и как, для того чтобы прикрутить к нему свою опцию.

Евгений Степанищев (bolknote.ru) 2009

Комментарий для www.livejournal.com/users/_saper_/:

Идея-то, вроде, достаточно простая и обозримая, хоть и несколько рутинная.

pechnikov.livejournal.com 2009

В одной окаменелой финансово-учетной программе (диасофт) именно для таких целей есть режим работы с просмотром отправляемых SQL-запросов. И он значительно облегчает понимание связей в огромном количестве таблиц без внешних ключей.
Интересно было бы увидеть инструмент для анализа неструктурированных таблиц, но хоть немного более продвинутый, чем просто query sniffer.

Евгений Степанищев (bolknote.ru) 2009

Комментарий для pechnikov.livejournal.com:

Я мог бы его написать, программа несложная, просто там столько ситуаций, которые надо отследить (простое равенство/неравенство, JOIN, вложенные запросы, запросы-таблицы и т. д.), что времени уйдёт немало, а я сейчас занят. Если ничего не найду, может когда-нибудь и вернусь к этой идее.

Как дела-то вообще, Олег?

masterspammer.livejournal.com 2009

Комментарий для Евгения Степанищева:

7-ю 1Сную базу ковырять доводилось — мрак и срань — мало того, что таблицы названы псевдослучайно, так ещё и связи... эээ... ну например индекс — строка фиксированной ширины, содержащая число, отформатированное как деньги (справа три пробела под точку и копейки), а на него ссылаются просто числом или строкой, но переменной длины. Самой же жестью были шестнадцатеричные строки, отформатированные как деньги.

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

Евгений Степанищев (bolknote.ru) 2009

Комментарий для masterspammer.livejournal.com:

С testlink’ом предложенная мной штука справилась бы на 5+. Связи, которые делаются через всякие функции она, конечно, не найдёт, но у меня такой задачи и нет.

masterspammer.livejournal.com 2009

Комментарий для Евгения Степанищева:

Ковырялся с системой разбора базы — она строила схему по ключам и по соответствию данных. Название уже не вспомню. Ошибалась порой сильно, но вот логи не понимала. Кстати, логи могут помочь отделить «рабочее ядро» базы от старых таблиц (и может быть даже полей), которые пора бы удалить.

Евгений Степанищев (bolknote.ru) 2009

Комментарий для masterspammer.livejournal.com:

По ключам они все умеют. Например, MySQL Workbench умеет, это продукт, который делают ребята из MySQL AB.