рабоче-странное

[errorrishe]

на работе временами у меня случается проблема
у нас слегка дофига таблиц в базе данных ( ну так больше 5K ). А я последнее время занимаюсь нашим bpm и часто приходиться вникать что и как и откуда выковырять - и не только для себя но и для консультантов
хочеться штуковину которая могла бы мне помочь вот таким образом
- набрал имя поля - увидел все места в которых он используется как foreign key, возможно даже более сложные связи - типа вот это можно получить от сюда использовав такие два ключа
- показать историю изменения схемы и увидеть в каком бранче что происходит
- просто супер быстро искать по именам полей и других сущностей с поддержкой всяких wild cards
Подъебка в том что использовать оркакл как источник данных - плохая идея. Тк хочется понимать git контекст тоже
Хорошая новость - все метаданные есть красиво описанные в db-agnostic формате (бггг xml конечно же)
Вопрос собственно - из чего это стоит пробовать лепить... Есть желание для этого не использовать java ( ибо заебало)
быстро искать по тексту можно lucen' ом но тут все усложняется прикольными данными и желанием понимать реляционную структуру в процессе поиска. Короче я пока еще не понял как к этому подступиться.

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

Comments

[qvb.livejournal.com]

У нас есть такая штука, причем она еще и работает с тэгами, показывает lineage, юзеры ставят свои рейтинги и много всякого еще, но эта система closed source и сделана "для себя". Может мы со временем сделаем на ее основе коммерческий сервис, но это в неопределенном будущем.

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

[errorrishe.livejournal.com]

да объем работы тоже пугает
думаю что то на коленке попробовать соорудить, посмотрю как пойдет

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

[qvb.livejournal.com]

Со структурами данных как раз все просто - запихиваем все эти метаданные в SQL и начинаем строить нужный функционал. Обьем этих данных крайне невелик, и можно делать почти что угодно не беспокоясь особо о производительности.

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

У нас на такой системе сидят тысячи юзеров, и данных там сотни тысяч датасетов, и все работает ОК.

[errorrishe.livejournal.com]

да, данных не то чтобы сильно много
полная одна дата модель что то типа 30 мегабайт, комитов на нее не то чтобы сильно дохера
были мысли что может вообще это хозяйство в памяти держать - даже с сиквелом не связываться. но то такое, засунуть в inoDB тоже проблемой не будет. Даже не уверен что парсилку надо многопоточной делать, ну что такое даже гигабайт другой с ssd прочитать ..

[qvb.livejournal.com]

SQL просто удобен развитым функционалом - широкие возможности для весьма замысловатых queries, а такие обьемы данных он все равно будет в памяти держать. Смысла нет изобретать что-то свое когда стандартная база все прекрасно сделает.
Тем более что всяких тулзов и UI controls для сиквела - чуть более чем дофига. Плюс репликация и прочие радости продакшена.

[errorrishe.livejournal.com]

да умом понимаю что база как хранилище будет норм, но жаба просит извращений
но она уступит если станет понятно что иначе ни как )

[qvb.livejournal.com]

Ну если тянет на подвиги - то мешать благородному порыву не следует :-)

Хотя можно напомнить что 80% проблем в софтверном деле начинаются с идеи "а давайте мы что-то этакое запилим вместо стандартных средств" :-)

[errorrishe.livejournal.com]

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

[qvb.livejournal.com]

Я бы где-то так и делал. Денормализованная таблица с индексами и все. Поверх можно легко прицепить OData API, и можно ваять требуемый UI на ангулар или подобном.

[errorrishe.livejournal.com]

о посмотрю на этот OData API, спасибо
заодно будет новый ангулар или реакт палочкой потыкать

[zeit-raffer.livejournal.com]

А чем лучше денормализованная таблица по сравнению с той же sql information schema? Чтобы джойнов не считать, а только фильтровать?

[bvlb.livejournal.com]

Если сделать дамп схемы в текстовом виде, то многие вещи можно просто грепом делать, и быстро.

[bvlb.livejournal.com]

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

[errorrishe.livejournal.com]

Ага, во многих случаях это сильно быстрее. Правильно выбрал индексы и тогда это хорошо работает( можно жить без единого full scan)

[errorrishe.livejournal.com]

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