|
|
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Нужно дать пользователю формировать простые (без СТЕ и пр.) sql -запросы по существующей структуре данных. Есть ли на просторах готовая структура данных для хранения информации о запросах или это лисапед?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2014, 18:27 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
sp, Совсем не понятно что нужно... можно более развернуто? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2014, 18:41 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
lLocust, Нужно чтоб пользователь мог составить запрос на клиенте (не руками написав select......, а с помощью дизайнера запросов создал запрос) и сохранить его в БД в виде структуры, которую можно валидировать на корректность и доступность объектов и анализировать и повторно представлять юзеру для изменений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2014, 19:11 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
lLocust, - запрос должен именоваться - запрос должен предоставлять список результирующих колонок, чтоб можно было в интерфейсе выбирать какие прятать/показать - запрос должен ограничить пользователя разрешенными объектами (есть таблица прав доступа) - запрос должен хранить правила и способы соединения сущностей - ..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2014, 19:20 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
- запрос должен хранить условия выборки - запрос должен хранить порядок группировки и сортировки - ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2014, 19:24 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
sp, Встречал нечто подобное в Business Intelligence (вреде от Microsoft). Что там было: возможность как в режиме мастера добавлять, связывать таблицы и вьюхи (в том числе с указанием характеристик связи: Left, Full jons...) На счет выбора колонок уже не помню, но что понравилось что можно было даже оракловые хинты указывать. И с правами уже не помню что было, но продукт использовался так: На основные формы системы строились такие "структуры", указывались возможные фильтры и настройки, и все это хозяйство ложилось в базу. Далее при запуске системы из базы тянулись настройки фильтров (по ним динамически формировались компоненты для фильтрации в ИС), а для работы с эти добром была целая схема с энным количество таблиц и пакетов. Только инструмент для рядового пользователя был мягко говоря сложноват.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2014, 19:32 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
sp, ну и группировки и сортировки там естественно были... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2014, 19:33 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
lLocust, А задача то какая, написать своими силами промышленную BI систему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2014, 19:39 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
~lLocust, А задача то какая, написать своими силами промышленную BI систему? Написать хранилище запросов! БИ весь нам не нужен) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2014, 20:19 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
spсохранить его в БД spхранилище запросов Поле в таблице БД типа nvarchar(8000). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2014, 20:29 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
splLocust, Нужно чтоб пользователь мог составить запрос на клиенте (не руками написав select......, а с помощью дизайнера запросов создал запрос) и сохранить его в БД в виде структуры, которую можно валидировать на корректность и доступность объектов и анализировать и повторно представлять юзеру для измененийА диазйнер запросов в SSMS не подойдёт? Или ваши требования намного больше его функциональности? Если боьше, то ещё взгляните на Access ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2014, 22:21 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Не вырисовывается пока, что именно надо. Есть сервер и есть дизайнер запросов. Последний (как я вижу такой дизайнер) берет из БД инфу о существующих таблицах и видах, графически показывает её пользователю, пользователь перетаскивает квадратики, ставит галочки, а на выходе дизайнер генерит SQL строку, которая передается на сервер для выполнения, или может быть сохранена на сервере как View. Что дальше? Не вдаваясь в эти детали могу предложить использовать какой нить yacc, что бы распарсить запрос и сохранить дерево, каждый узел в отдельной строке, у каждого узла будет своя семантика, там всё это "...можно валидировать на корректность и доступность объектов и анализировать...". Но 1) для этого BNF надо в точности знать (если его знать, то и самому парсер написать не сильно сложнее, чем yacc пользовать) 2) такой анализ с успехом делает сама СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2014, 23:50 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
splLocust, Нужно чтоб пользователь мог составить запрос на клиенте (не руками написав select......, а с помощью дизайнера запросов создал запрос) и сохранить его в БД в виде структуры, которую можно валидировать на корректность и доступность объектов и анализировать и повторно представлять юзеру для изменений Ну, есть реляционный язык QBE. Он графический. И "дизайеры" для него. Например, В Аксцессе он юзается. Есть тулсы и для других СУБД. Сохраненные запросы в РБД - это собственно представления. В Аксцессе просто сохраняются запросы. Другое дело, что пользователь, который "составлят запросы", все равно должен иметь понятия в БД. Ить о должен знать структуру БД, а не представления данных в окнах клиентской проги. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 00:01 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
petalvikspсохранить его в БД spхранилище запросов Поле в таблице БД типа nvarchar(8000). я б может понял вас еслиб в вопросе не обозначил требования.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 00:09 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
U-gene, вы мне предлагаете хранить текст, а мне нужно хранилище реляционное - связанные таблицы, условия связей, поля результата... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 00:11 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
vadiminfo, мне не нужно сразу готовый запрос в виде представления - мне нужна структура хранящая метаданные запроса по которым можно легко сгенерировать вью или сформировать динамический скуль. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 00:13 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
spU-gene, вы мне предлагаете хранить текст, а мне нужно хранилище реляционное - связанные таблицы, условия связей, поля результата... нет, я говорю, что "структуру запроса" можно вытащить из запроса после того, как его распарсили, представили в виде дерева. Дерево - это не текст. По узлам дерева, по их семантике, можно дальше вытаскивать все, что угодно. И я ничего не предлагаю. Я вопроса то еще не понял... а Вы еще загадок подкидываете. Что такое "метаданные запроса"? Ка понимать фразу "а мне нужно хранилище реляционное - связанные таблицы"? Вы запятыми хотя бы озаботьтесь, или согласованием слов. Я дал схему типичного (в моем понимании) взаимодействия дизайнера запросов и СУБД. Ваш случай с ней как соотносится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 00:29 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
U-gene, таблица "запрос", таблица "связанные сущности", таблица "условия связей сущностей" и т.д. это и есть метаданные по которым можно сгенерировать запрос - это и есть метаданные хранящие информацию о запросе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 00:43 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
sp, я предлагаю хранить sql в виде - кто бы мог подумать? - sql! Именно в виде простой строки текста. Пользователь может вводить эту строку в любом текстовом поле ввода. Если нужно сделать визуальный конструктор - делай. Как именно - можно подсмотреть в имеющихся софтинах, например, в DbForgeStudio. Для парсинга sql в виде строки заюзать парсер. Берём грамматику отсюда . Генерируем парсер - используем в своём приложении. Если по какой-либо причине (какой?) хранение запроса в виде обычной строки не подходит, ничто не мешает хранить его в виде дерева/коллекции узлов с параметрами. Тут уже вопрос используемого языка, используемого диалекта sql и т. п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 01:59 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
sp, Смотрите структур каталога БД. Там же все запросы храняться? И СУБД их как то валидирует? Например тот же Access(что под руку попало) хранит всё о запросах в 2х таблицах MSysObjects и Msys Queries. В первой общее описание объекта (Имя, ID, тип) по строке на запрос, в другой на каждый запрос набор строк, в целом подозрительно напоминающих (кто бы мог подумать!) на сохраненный в таблицу узлы дерева синт. разбора SQL выражения. Но не совсем дерево. Навскидку, впечатление, что строки с атрибутом 5 перечисляют выводимые таблицы, с атрибутом 6 - поля, 7 - описывают JOINы между таблицами и тд. Покурите, как пример. А общего решения наверное нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 02:30 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Хочу задаться вопросом, в чем смысл и почему возникла необходимость "дать возможность пользователю самому формировать запросы" ? С моей точки зрения причин две - лень или недостаточная искусность разработчика , не предоставившего пользователю возможность манипулирования информацией во всех нужных разрезах, рассматривать ее с разных точек зрения на уровне презентации объектов в конечной бизнес-форме, в терминах бизнеса. Вторая - ограниченность знаний о предметной области, известных разработчику на момент написания системы. Предметная область может быть динамичной, быстро развививаться. Того, что было заложено в систему в момент ее сдачи заказчику, через некоторое время перестает хватать для решения бизнес-задач. Субъективно я вижу такие пути решения этих двух проблем. Первая. Непосредственный контакт разработчика с заказчиком, глубокое погружение в его проблемную область, разработка презентационного слоя системы "про запас". Решение задач пользователя, известных на момент написания системы, должно быть не высшей точкой ее реализации, а одним из частных случаев применения более широкого спектра заложенных в систему умений. Пользователь должен иметь возможность на раз, по щелчку пальцев разворачивать представление бизнес-информации любой стороной, хоть к лесу задом, хоть в коленно-локтевую позу. Очень близко к этому тезису стоит возможность создания "пользовательских фильтров". Если разработчик не предусмотрел и не предугадал все актуальные и возможные в будущем бизнесовые фильтры (выраженные в терминах бизнеса) и возможность их комбинации для уточнения критериев отбора, то пользователи вынуждены считать за благо долгую возню в некоем бланке, вручную отмечая галками поля и соображая в каком порядке должны выполняться операции OR, AND. Вторая. Система должна быть построена в виде конфигурации, сделанной на хорошем конфигураторе (примеры, часто появляющиеся в этом топике - искра, випрос). В системе должны быть высокоуровневые специализированные конфигураторы ключевых бизнес объектов, которые находятся под присмотром аналитика-конфигураста. Это может быть свой квалифицированный пользователь, внешний разработчик на договоре или по аутсорсингу. При появлении новых требований за счет настройки в этих конфигураторах поведение системы должно меняться во всех модулях, использующих эти ключевые объекты. Мне самому удалось только в небольшой степени воплотить эти подходы в своих разработках. Желаю остальным читателям-писателям форума дальше пройти по этому пути. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 11:55 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Программист-Любитель, Возможно, у sp "пользоваетль" = у Вас "разработчик". Например, 1с разработчики с СУБД напрямую не общаются, но они не конечные пользователи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 12:42 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Программист-Любитель... С моей точки зрения причин две - лень или недостаточная искусность разработчика , не предоставившего пользователю возможность манипулирования информацией во всех нужных разрезах, рассматривать ее с разных точек зрения на уровне презентации объектов в конечной бизнес-форме, в терминах бизнеса. ... А если даст - запросы уже не нужны? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 12:47 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Программист-Любитель, Ну тут 2 тезиса: - все не предусмотриш - по каждому хотению юзера напрягать программера - негоже! А возможность самому юзеру формировать представления информации на основе сформулированных им критериев - это и правильно и гибко - демократия у на типа в конце концов или нормальные отношения с юзерами??)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 14:27 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
[quot sp]"мне нужна структура хранящая метаданные запроса по которым можно легко сгенерировать вью или сформировать динамический скуль.[quot] Ну по "методанным" описывающим схему (т.е. таблицы) QBE, можно, "возможно" максимально "легко" для РМД сгенерировать. Но знание этих "методанных" и понимание QBE как бы выходит за рамки обычного конечного пользователя. [quot sp] А возможность самому юзеру формировать представления информации .....[quot] Сегодня, таковая возможность реализуется в ОЛАП. Там все таки многомерные кубы про основные показатели для юзера: что делает построение запросов доступным для кажного - вращай себе кубы, делай срезы, не хочу. РМД, скорее заточена, под максимальную "легкость" на уровне расработчика, иначе бы было бы уже в массах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2014, 08:49 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
vadiminfo, Уже давным давно во многих продуктах юзеру дается возможность мастерить свои запросы - посмотрите для примера Микрософ ЦРМ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2014, 15:33 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
spvadiminfo, Уже давным давно во многих продуктах юзеру дается возможность мастерить свои запросы - посмотрите для примера Микрософ ЦРМ) К сожалению, нет под рукой. Это именно не система отчетов? В которой заранее созданно много разных представлений, а юзер только выбирает и накладывает фильтры? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2014, 15:56 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
vadiminfo, нет - это обычное рабочее место любого юзера - в нем можно используя мастер запросов уточнить критерии запроса по связанным сущностям, сохранить его и использовать при просмотре данной сущности и редактировать если надо изменить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2014, 20:09 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
spvadiminfo, нет - это обычное рабочее место любого юзера - в нем можно используя мастер запросов уточнить критерии запроса по связанным сущностям, сохранить его и использовать при просмотре данной сущности и редактировать если надо изменить Скорее всего, все таки надо, наверное, увидеть, чтобы понять разницу между "нет - это обычное рабочее место любого юзера" и "да - это обычное рабочее место любого юзера", т.е. разновидность старой доброй системы отчетов, обогащенной мастерами. Т.е. не совсем ясно на сколько "любого юзера" и на сколько отлично от QBE (не другой ли способ оного же). В Аксцессе QBE тоже обогащен мастерами. Тоже рабочее место, но наверное не "любого" юзера, а все же особенного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 08:40 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Ему надо хранить расположение оконцев, стрелочек и ключиков, а вы про sql, простихосподи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 10:15 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Кстати, в PMA оказывается есть такая шняга. Недавно заметил и понял откуда берутся такого рода снимки экранов. Умора. Пять минут растаскивал оконца, растащить не смог, а как там провести стрелочки вообще не понял. Еще в период программирования на десктопе Абсцесс просто заколебывал своим неутомимым стремлением подсунуть мне конструктор вместо окна с запросами. Но самая конечно мякотка это вопрос как запузырить в эти квадратики поле вроде: coalesce(`art`.`price_discounted`, ceil( `art`.`price_retail`*`art`.`retail_discount`/10)*10) as `price_discounted` ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 10:25 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
debloggerЕму надо хранить расположение оконцев, стрелочек и ключиков... Это, звучит, несколько не созвучно с темой топика и, возможнно, не так интересненько. А там кто знает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 11:12 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Ответ настолько очевиден что я и заподозрил неладное. spvadiminfo, мне нужна структура хранящая метаданные запроса по которым можно легко сгенерировать вью или сформировать динамический скуль. В MySql оно хранится в INFORMATION_SCHEMA главным образом. Оттудова и достаются данные для SHOW CREATE TABLE например. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 11:23 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
deblogger, пожалуйста, не придумывайте за меня разные бредни, и не прилично в присутсвии еще живого человека говорить в третьем лице - это обычно делают необразованные люди! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 20:00 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Боюсь готового решения вы не найдете, придется делать свое. У нас мы используем самописное хранение SQL в XML (вообще можно хранить хоть в чем, сам запрос в программе храниться в POJO классах, а там уже сериализовать уже можно во что угодно). Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. Самая основное как записываются поля. не четными идут название полей, четными название таблиц. Таким образом строятся join. '+' означает left join. Исходники к сожалению я дать не могу, но может сама идея вам пригодиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 20:08 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
olzhasСамая основное как записываются поля. не четными идут название полей, четными название таблиц. Таким образом строятся join. '+' означает left join. А вот это зря. Вы создали документ, чтобы хранить структуру. И в самих полях еще храните структуры, связанные с документом. И еще привязываетесь, даже не к очередностям, а к четностям/нечетностям. По феншую, это выносится в структуру документа, дабы не нарушать самого смысла XML. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 23:35 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
olzhas, такую тип хранения не удовлетворяет - я не могу валидировать ни поля ни сущности в запросе - они все в тексте и если я буду что-то менять в структуре данных - данный способ молча проглотит и выдаст ошибку при попытке выборки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2014, 19:18 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
R7, Не совсем понял что вы имеете в виду. XML хранит запрос. То что название поля имеет такой сложный вид?! так это адрес колонки, относительно текущей таблицы. sp, Валидация есть, в данном случая я просто показал как это хранится. При загрузке происходит валидация, по структуре БД, данные берутся из connection.getMetaData().getXXX(). Например Код: xml 1. , наличие таблицы проверяется connection.getMetaData().getTables() + проверка на доступ к этой таблице. Код: xml 1. через connection.getMetaData().getColumns(); Код: xml 1. Делаем fullColumnName.split("\\.") получаем массив сток, в которой по очереди идут название колонки по которой идет связь и название таблицы куда ссылаемся, последней строкой будет то поле которое должно быт в выборке. Опят таки правильность названия таблиц и колоном можно узнать через выше описанные методы. Зная название таблицы, его поля и название связанной таблицы, через connection.getMetaData().getExportedKeys() можем узнать на название поля в связанной таблице, что бы в дальней чем построить Join. так же тут проверяется что связь вообще есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 08:34 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
olzhas, Такое в xml структуру влезет? :) Код: sql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 08:50 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Гхостикolzhas, Такое в xml структуру влезет? :) Код: sql 1. 2. 3. 4. 5. 6. 7. (задумчиво)...я бы GROUP BY и UNION добавил для разнообразия ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 09:18 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Гхостик, нет не влезет, но оно и не нужно, мы не пытались сделать полную замену sql. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 09:25 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Тоже делаем подобный велосипед. Пользователь выбирает только колонки, и фильтры. На БД хранятся метаданные - из какой вьюхи колонку брать, как соединять, агрегировать итп. Сам запрос устроен в виде XML - похоже как у olzhas. Так проще его сериализовать и самое главное - десериализовать. Запрос выполняет вьюха на сервере строя по XML-запросу и метаданным SQL-запрос и выполняя его в динамике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 11:56 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Я так понимаю. что у автора стоит другая задача. Сейчас корректность запросов проверяется динамически, а он хочет забацать нечто типа статической проверки запросов по отношению к схеме данных. Точнее даже наоборот - схемы (которая может меняться) по отношению к существующим запросам. Поменяли таблицу - проверяем все связанные с нею запросы (если таковые есть), что, мол, имена присутствуют, типы совпадают. В этом смысле варианты с XML решения не дают, конечно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 12:14 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
olzhasR7, Не совсем понял что вы имеете в виду. XML хранит запрос. То что название поля имеет такой сложный вид?! так это адрес колонки, относительно текущей таблицы. Ничего такого не имел. Просто совет. Понятия "нормализация слабоструктурированных данных" нет. Наверное, потому что туда применима нормализация данных вообще. Вот у вас нарушена 1НФ. Вы разбираете XML, а потом еще раз парсите строки из полученных данных. Работает, ну и нормально. Я видел, где и в названия атрибутов запихивали инфу тип данных. А вот еслиб у вас было нечто вроде (схематично. пример вообще не правильный. тут джойн принадлежит columns, а не queryInfo): Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 1. Это было бы понятно стороннему разработчику сторонней программы. 2. Вы бы получали все нужные данные для построения запроса только разбором XML. 3. Как следствие из 2, в случае изменения схемы БД, такие XML легко апдейтятся. И если смотреть на структуру "нормализованного" XML, то понятно, куда ему расти и развиваться. Например, значением атрибута source может быть не таблица а линк на полноценный queryInfo (или сразу вложенный нод queryInfo) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 13:18 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
R7, Изначально в первом варианте мы хранили запрос в древовидной структуре, как вы и описали вот пример. Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Но отказались по нескольким причинам. 1. в древовидной структуре нельзя (без создания дополнительных атрибутов) задать порядок столбцов, в отличии от линейного где выбираемые столбцы идут по порядку. 2. Чисто визуально линейный вариант выглядит удобнее, одно поле описывается одной строчкой. читается легче. 3. в UI список, удобнее дерева. Долго объяснять почему, просто поверите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 13:54 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Мимо пробегал...Я так понимаю. что у автора стоит другая задача. Сейчас корректность запросов проверяется динамически, а он хочет забацать нечто типа статической проверки запросов по отношению к схеме данных. Точнее даже наоборот - схемы (которая может меняться) по отношению к существующим запросам. Поменяли таблицу - проверяем все связанные с нею запросы (если таковые есть), что, мол, имена присутствуют, типы совпадают. В этом смысле варианты с XML решения не дают, конечно. XML это просто способ хранения. В конечном итоге ХМЛ сериализуется(конечно не простым JAXB, чуть посложнее) в класс Query. В которых есть ссылки на классы QueryColumn, Table, Column, Reference и тд. Хотите переименовать таблиц или колонку, без проблем. меняем поле table.tablename и сериализуем Query, получаем xml c правильным названием таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 14:01 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
olzhas, Вангую. Вернетесь к прошлому варианту. ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 14:11 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
R7, и того мало будет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 14:33 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
Мимо пробегал...Я так понимаю. что у автора стоит другая задача. Сейчас корректность запросов проверяется динамически, а он хочет забацать нечто типа статической проверки запросов по отношению к схеме данных. Точнее даже наоборот - схемы (которая может меняться) по отношению к существующим запросам. Поменяли таблицу - проверяем все связанные с нею запросы (если таковые есть), что, мол, имена присутствуют, типы совпадают. В этом смысле варианты с XML решения не дают, конечно. +1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 19:15 |
|
||
|
Ищу структуру данных для хранения информации о sql-запросах
|
|||
|---|---|---|---|
|
#18+
spМимо пробегал....... +1 Я тем же самым занимаюсь. У меня парсится входное SQLвыражение, вытаскиваются все встреченные имена с их признаками и это всё запихивается в одну таблицу. Городить структуры типа "одна таблица для таблиц, другая - для атрибутов" мне показалось ненужным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2014, 02:29 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1540992]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
68ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
68ms |
get tp. blocked users: |
2ms |
| others: | 10ms |
| total: | 192ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...