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

[errorrishe]

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

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

Comments

[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? Чтобы джойнов не считать, а только фильтровать?

[errorrishe.livejournal.com]

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