|
|
|
Ищу структуру данных для хранения информации о 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?fid=32&msg=38545080&tid=1540992]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 153ms |

| 0 / 0 |

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