Форум dkLab и Denwer
Здесь общаются Web-разработчики.
Генеральный спонсор:
Хостинг «Джино»

sql_tables_mysql: возвращает имена таблиц, используемых в SQL запросе (MySQL диалект) (Rin)
Author Message
Rin
Участник форума



Joined: 01 Jun 2005
Posts: 515
Карма: 184
   поощрить/наказать

Location: Москва

PostPosted: Mon Dec 25, 2006 3:56 pm (написано за 1 минуту 39 секунд)
   Post subject: sql_tables_mysql: возвращает имена таблиц, используемых в SQL запросе (MySQL диалект)
Reply with quote

Возвращает имена таблиц, используемых в SQL запросе (MySQL диалект).
Имена таблиц могут использоваться в функции кеширования,
которая проверит изменение данных в таблицах запросом
SELECT MAX(modifed) FROM t1
UNION
SELECT MAX(modifed) FROM t2
...


sql_tables_mysql-1.0.4.rar
 Description:

Download
 Filename:  sql_tables_mysql-1.0.4.rar
 Filesize:  1.64 KB
 Downloaded:  652 Time(s)



Last edited by Rin on Tue Feb 19, 2008 4:46 pm; edited 2 times in total
Back to top
View user's profile Send private message Send e-mail
Константин Жинько [tIT]
Сотрудник «Лаборатории»



Joined: 12 Jun 2004
Posts: 2264
Карма: 106
   поощрить/наказать

Location: Москва

PostPosted: Mon Dec 25, 2006 4:30 pm (спустя 33 минуты; написано за 31 секунду)
   Post subject:
Reply with quote

Вас вдохновил спор на тему DbSimple? (-;
Back to top
View user's profile Send private message
Юрий Насретдинов
Модератор



Joined: 13 Mar 2003
Posts: 8642
Карма: 198
   поощрить/наказать

Location: 007 495

PostPosted: Mon Dec 25, 2006 7:13 pm (спустя 2 часа 43 минуты; написано за 10 секунд)
   Post subject:
Reply with quote

Константин Жинько [tIT]
В поиск!!! даже в мусор :) forum.dklab.ru/viewtopic.php?p=126323#126323
Back to top
View user's profile Send private message Send e-mail
Rin
Участник форума



Joined: 01 Jun 2005
Posts: 515
Карма: 184
   поощрить/наказать

Location: Москва

PostPosted: Tue Dec 26, 2006 11:23 am (спустя 16 часов 9 минут; написано за 15 минут 1 секунду)
   Post subject:
Reply with quote

Константин Жинько [tIT]

Честно говоря, я считаю кэширование запросов в DbSimple излишеством.
Большого увеличения производительности это не даст, еще нужно html страницу генерировать.
Потом, в MySQL-4.1.x уже есть встроенное кеширование.
Это дает некоторое увеличение производительности в скриптах, где вообще нет никакого кэширования.

Наибольший прирост производительности дает кэширование конечных, уже сгенерированных html страниц (отклик менее 0.02 сек.).
Необходимо иметь хороший и быстрый алгоритм проверки изменения данных в источниках, из которых генерируется страница.
БД является всего лишь одним из источников, наряду с файлами и $_REQUEST.

Меня вдохновила возможность отслеживания данных из источника БД в автоматическом режиме + спортивный интерес на грамматический разбор SQL запроса.
Back to top
View user's profile Send private message Send e-mail
Константин Жинько [tIT]
Сотрудник «Лаборатории»



Joined: 12 Jun 2004
Posts: 2264
Карма: 106
   поощрить/наказать

Location: Москва

PostPosted: Tue Dec 26, 2006 12:07 pm (спустя 44 минуты; написано за 16 минут 13 секунд)
   Post subject:
Reply with quote

Rin wrote:
Честно говоря, я считаю кэширование запросов в DbSimple излишеством.
Большого увеличения производительности это не даст, еще нужно html страницу генерировать.
Потом, в MySQL-4.1.x уже есть встроенное кеширование.
Ну опять Вы за старое! MySQL не единственная СУБД на свете! )))
Опять-таки Ваше решение немного завязано на MySQL. Я бы на Вашем месте переименовал тему (на своем месте я это сделать не могу - здесь моя модераторская власть не работает)))
К тому же на моем супер-гипер-мега-фантастическом, но синтаксически корректном запросе (forum.dklab.ru/viewtopic.php?p=126010#126010) она выдает неверный результат - таблицы ds в базе не существует - это всего лишь алиас для динамической переменной отношения.
Back to top
View user's profile Send private message
Rin
Участник форума



Joined: 01 Jun 2005
Posts: 515
Карма: 184
   поощрить/наказать

Location: Москва

PostPosted: Wed Dec 27, 2006 8:01 pm (спустя 1 день 7 часов 53 минуты; написано за 2 минуты 29 секунд)
   Post subject:
Reply with quote

Ладно, оставим MySQL в покое! :)
Ошибку с динамической таблицей исправлю и сделаю более независимым от MySQL.
Как я понимаю, нужно дать возможность указать backticks параметром функции? (``, [])
Back to top
View user's profile Send private message Send e-mail
Константин Жинько [tIT]
Сотрудник «Лаборатории»



Joined: 12 Jun 2004
Posts: 2264
Карма: 106
   поощрить/наказать

Location: Москва

PostPosted: Thu Dec 28, 2006 12:39 pm (спустя 16 часов 38 минут; написано за 1 минуту 24 секунды)
   Post subject:
Reply with quote

Rin wrote:
Как я понимаю, нужно дать возможность указать backticks параметром функции?
Это во-первых.
Во-вторых, если хотите отойти от MySQL, то:

1) в PostgreSQL:
Code (SQL): скопировать код в буфер обмена
SELECT *
FROM my
LIMIT 5 OFFSET 10
2) в Firebird:
Code (SQL): скопировать код в буфер обмена
SELECT FIRST 5 SKIP 10
FROM my
Back to top
View user's profile Send private message
Rin
Участник форума



Joined: 01 Jun 2005
Posts: 515
Карма: 184
   поощрить/наказать

Location: Москва

PostPosted: Thu Dec 28, 2006 4:35 pm (спустя 3 часа 56 минут; написано за 4 минуты 45 секунд)
   Post subject:
Reply with quote

Ладно, новый год скоро, я не стал заморачиваться с backticks и синтаксисом строковых выражений для совместимости различных БД.
Для MySQL функцию исправил, имя динамической переменной отношения не возвращается в результирующем массиве.
Теперь должно все корректно работать.
Синтаксис ограничения выборки, который вы привели примером выше, не играет роли для этой функции.
Back to top
View user's profile Send private message Send e-mail
Дмитрий Котеров
Администратор



Joined: 10 Mar 2003
Posts: 13665
Карма: 413
   поощрить/наказать


PostPosted: Tue Jan 09, 2007 2:48 pm (спустя 11 дней 22 часа 12 минут; написано за 3 минуты 33 секунды)
   Post subject:
Reply with quote

Для MySQL кэширование запросов библиотекой совершенно излишне, и это очевидно. Когда речь идет о кэшировании запросов, имеются в виду, конечно же, другие СУБД PostgreSQL, FireBird). А вот в них может быть уже все, что угодно: например, вызов долгих хранимок, который нужно кэшировать. Так что я предлагаю обсуждение заканчивать, т.к. оно бесплодно.

Если уж и делать автоопределение используемых таблиц, то через EXPLAIN-запросы (кэшируемые). Вроде как для всех СУБД там имеется информация о задействованных таблицах (если я только ничего не путаю). Но только все равно это - решение "на коленке", потому что необходимость наличия timestamp-столбца никто не отменял, а это уже завязка того же уровня, что и ручное перечисление имен таблиц.
Back to top
View user's profile Send private message Send e-mail
Dark-Demon
Участник форума
Banned


Joined: 04 Feb 2007
Posts: 45
Карма: -3
   поощрить/наказать

Location: spb

PostPosted: Sun Feb 04, 2007 6:20 am (спустя 25 дней 15 часов 31 минуту; написано за 7 минут 35 секунд)
   Post subject:
Reply with quote

Quote:
потому что необходимость наличия timestamp-столбца никто не отменял
я так понимаю у вас кэшировние на уровне таблиц, а не строк? тогда использование дополнительного поля - крайнее излишество. лучше создать отдельную таблицу, где хранить инфу о времени последних модификаций таблиц.
а где вы храните кэш? в файлах? в бд?
да и всё-равно кэшировать запросы к БД - не есть иеологически верно, ибо с результатом потом происходят каждый раз одни и те же преобразования. лучше кэшироваать на уровне выводимых блоках информации (в конце концов, можно и php-массивы кэшировать ;-) ). а это уже как минимум отдельная от dbSimple либа.
вывод: вырезаем кэширование бритвой оккама и реализуем отдельный универсальный класс для кэширования.

по сабжу: не вижу смысла выдирать имена таблиц из запроса. в подавляющем большинстве случаев они заранее известны программисту.
Back to top
View user's profile Send private message
Андрей Анатольич
Guest





Карма: 388
   поощрить/наказать


PostPosted: Fri Feb 09, 2007 7:02 pm (спустя 5 дней 12 часов 42 минуты; написано за 27 секунд)
   Post subject:
Reply with quote

Вот кстати, отличная статья на тему кэширования запросов в MySQL dev.mysql.com/tech-resources/articles/mysql-query-cache.html
Back to top
Андрей Анатольич
Guest





Карма: 388
   поощрить/наказать


PostPosted: Fri Feb 09, 2007 7:12 pm (спустя 9 минут; написано за 8 секунд)
   Post subject:
Reply with quote

Для MySQL.
Насколько я понял из вышеозначенной статьи, можно сделать так (прямо в веб приложении):

// Оключаем кэширование запросов в начале веб-приложения
$db->select("SET session query_cache_type=0");

Отключаем кэширование для того, чтобы не кэшировались запросы типа
SELECT * FROM table ORDER BY RAND()
У меня на сайте почему-то это кэшируется.


// Потом, если нужно кэшировать конкретный запрос, то пишем

$db->select("SET session query_cache_type=1"); // Включаем кэширование
$data = $db->select("SELECT * FROM table"); // Большой, медленный запрос
$db->select("SET session query_cache_type=0"); // Выключаем кэширование

Собственно вот.
Back to top
Дмитрий Котеров
Администратор



Joined: 10 Mar 2003
Posts: 13665
Карма: 413
   поощрить/наказать


PostPosted: Sat Feb 10, 2007 12:50 am (спустя 5 часов 38 минут; написано за 1 минуту 9 секунд)
   Post subject:
Reply with quote

Я не понимаю только, зачем все это.
То, что SELECT * FROM table ORDER BY RAND() кэшируется - это баг MySQL, можно попробовать обновиться (наверняка уже исправили).
Что касается DbSimple, то в ней кэширование запросов сделано для баз, ОТЛИЧНЫХ от MySQL. Для MySQL, очевидно, никакого внешнего кэширования не требуется, т.к. она и так прекрасно сама все кэширует.
Back to top
View user's profile Send private message Send e-mail
Rin
Участник форума



Joined: 01 Jun 2005
Posts: 515
Карма: 184
   поощрить/наказать

Location: Москва

PostPosted: Tue Feb 19, 2008 4:49 pm (спустя 1 год 9 дней 15 часов 59 минут; написано за 1 минуту 34 секунды)
   Post subject:
Reply with quote

К сожалению, кэширование в MySQL имеет много ограничений.
"Тяжелые" запросы, как правило, попадают под них и не кэшируются :(.
Back to top
View user's profile Send private message Send e-mail
uhamurad
Участник форума



Joined: 20 Feb 2008
Posts: 21
Карма: 1
   поощрить/наказать

Location: Махачкала

PostPosted: Mon Apr 28, 2008 12:55 pm (спустя 2 месяца 8 дней 20 часов 5 минут; написано за 2 минуты 8 секунд)
   Post subject:
Reply with quote

Здравствуйте!

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

Спасибо!
Back to top
View user's profile Send private message
Rin
Участник форума



Joined: 01 Jun 2005
Posts: 515
Карма: 184
   поощрить/наказать

Location: Москва

PostPosted: Mon Apr 28, 2008 4:22 pm (спустя 3 часа 27 минут; написано за 38 секунд)
   Post subject:
Reply with quote

uhamurad

Зачем вам это? Думаю, что это плохая идея.
Back to top
View user's profile Send private message Send e-mail
uhamurad
Участник форума



Joined: 20 Feb 2008
Posts: 21
Карма: 1
   поощрить/наказать

Location: Махачкала

PostPosted: Mon Apr 28, 2008 8:49 pm (спустя 4 часа 26 минут; написано за 7 минут 45 секунд)
   Post subject:
Reply with quote

Это необходимо при написании компонентов для одного движка (CMS). В этом движке для всех компонентов заводится общая база данных, а имена таблиц, пренадлежащих определенному компоненту, должны начинаться с префикса (допустим, com_content_). Нужно, чтоб sql-запросы, используемые при реализации компонентов, составлялись так, как будто этих префиксов и нет (т.е. чтобы разработчик не задумывался о реальной структуре БД и писал код так, как будто БД существует для него одного).

Просто не хочется заставлять каждый раз перед названием таблицы в запросе писать префикс, типа `{P}content` или `#__content` и т.п.
Back to top
View user's profile Send private message
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 269
   поощрить/наказать

Location: Питер

PostPosted: Tue Apr 29, 2008 8:02 am (спустя 11 часов 13 минут; написано за 1 минуту 27 секунд)
   Post subject:
Reply with quote

uhamurad wrote:
разработчик не задумывался о реальной структуре БД и писал код так, как будто БД существует для него одного
Вот это и порождает кучу проблем в будущем. =)
Разработчик обязан следовать стандартам API.
Back to top
View user's profile Send private message
uhamurad
Участник форума



Joined: 20 Feb 2008
Posts: 21
Карма: 1
   поощрить/наказать

Location: Махачкала

PostPosted: Tue Apr 29, 2008 7:58 pm (спустя 11 часов 55 минут; написано за 4 минуты 3 секунды)
   Post subject:
Reply with quote

В моей системе разработчик (компонента) при работе с БД должен использовать функции окружения, предоставляемые движком. Эти функции и производят подмену.

WingedFox, а какие могут возникнуть проблемы оттого, что таблица физически будет называться `com_content_categories` вместо `categories`? Или Вы имеете в виду возможное несовершенство алгоритма замены имен таблиц?
Back to top
View user's profile Send private message
Rin
Участник форума



Joined: 01 Jun 2005
Posts: 515
Карма: 184
   поощрить/наказать

Location: Москва

PostPosted: Tue Apr 29, 2008 9:18 pm (спустя 1 час 20 минут; написано за 3 минуты 9 секунд)
   Post subject:
Reply with quote

WingedFox прав.
Еще не следует забывать о скорости парсинга и надежности работы.
Собственно, ни того ни другого на приемлимом уровне сделать не возможно :)
Back to top
View user's profile Send private message Send e-mail
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 269
   поощрить/наказать

Location: Питер

PostPosted: Tue Apr 29, 2008 10:40 pm (спустя 1 час 21 минуту; написано за 1 минуту 17 секунд)
   Post subject:
Reply with quote

uhamurad
Проблемы будут в том случае, если делается что-то неявное. Например, неявно подменяются имена таблиц.
Порождает сие совершенно непредсказуемые и практически неотлаживаемые ошибки.
Но это уже -- оффтопик.
Back to top
View user's profile Send private message
uhamurad
Участник форума



Joined: 20 Feb 2008
Posts: 21
Карма: 1
   поощрить/наказать

Location: Махачкала

PostPosted: Wed Apr 30, 2008 1:01 pm (спустя 14 часов 21 минуту; написано за 1 секунду)
   Post subject:
Reply with quote

Rin, WingedFox

Зато появляется другая "надежность" - компонент никак не получит доступа к таблицам других компонентов и к системным таблицам.

А то, что используются префиксы от разработчиков скрываться не будет... просто это освобождает его от необходимости каждый раз писать {P} перед названиями таблиц (что он может иногда и забывать)
Back to top
View user's profile Send private message
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 269
   поощрить/наказать

Location: Питер

PostPosted: Wed Apr 30, 2008 1:09 pm (спустя 8 минут; написано за 1 минуту 51 секунду)
   Post subject:
Reply with quote

uhamurad
Как говорится "ROFLMAO".
Разработчик может ровно с тем же успехом упомянуть в запросе любую другую таблицу и она будет обработана.
В общем, делайте как хотите, но на подобную ересь нормальные люди время тратить не будут. =)
Back to top
View user's profile Send private message
uhamurad
Участник форума



Joined: 20 Feb 2008
Posts: 21
Карма: 1
   поощрить/наказать

Location: Махачкала

PostPosted: Wed Apr 30, 2008 1:38 pm (спустя 28 минут; написано за 1 минуту 59 секунд)
   Post subject:
Reply with quote

WingedFox, Вы видимо меня не так поняли... У одного компонента будет префикс `com_materials_`, у другого - `com_portfolio_` (соответственно для компонентов "Материалы" и "Портфолио").
Back to top
View user's profile Send private message
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 269
   поощрить/наказать

Location: Питер

PostPosted: Wed Apr 30, 2008 1:45 pm (спустя 7 минут; написано за 23 секунды)
   Post subject:
Reply with quote

uhamurad
А что будете делать, когда понадобится связать таблицы из разных компонентов?
Back to top
View user's profile Send private message
uhamurad
Участник форума



Joined: 20 Feb 2008
Posts: 21
Карма: 1
   поощрить/наказать

Location: Махачкала

PostPosted: Wed Apr 30, 2008 2:18 pm (спустя 33 минуты; написано за 5 минут 34 секунды)
   Post subject:
Reply with quote

WingedFox, взаимодействие между компонентами на уровне БД запрещено, это можно делать через специальные интернфийсы. Это один из принципов системы. Это решение принято ради того, чтобы не привязывать компонент с определенной структуре таблиц БД (т.е. если разработчик в новой версии своего компонента захочет изменить структуру таблиц БД, чтобы "связки" таблиц с таблицами других компонентов не ограничивали разработчика).

Согласен, очевидный минус в эффективности, за то плюс в гибкости...
Back to top
View user's profile Send private message
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 269
   поощрить/наказать

Location: Питер

PostPosted: Wed Apr 30, 2008 2:21 pm (спустя 2 минуты; написано за 35 секунд)
   Post subject:
Reply with quote

uhamurad
Это минус ко всему.
Обрубать JOIN - несусветная глупость, раз уж даётся прямой доступ к БД.
Back to top
View user's profile Send private message
uhamurad
Участник форума



Joined: 20 Feb 2008
Posts: 21
Карма: 1
   поощрить/наказать

Location: Махачкала

PostPosted: Wed Apr 30, 2008 3:56 pm (спустя 1 час 35 минут; написано за 6 минут 1 секунду)
   Post subject:
Reply with quote

WingedFox, согласен. Знаете, у меня небольшой опыт в разработке таких систем, и возможно то о чем вы говорите может стать большой проблемой, но я считаю, что заложенные принципы надо соблюдать. Как говориться, возможности прежде эффективности. Я думаю в крайнем случае для таких "JOIN" случаев можно что-нибудь придумать, но это уже будет как дополнительный механизм. Посмотрим что из этого получится, но в любом случае спасибо за помощь!Ну ладно уже, закончим этот "оффтопик"...

Ну так как думаете, сложно ли будет переделать функцию?
Back to top
View user's profile Send private message
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 269
   поощрить/наказать

Location: Питер

PostPosted: Wed Apr 30, 2008 4:01 pm (спустя 5 минут; написано за 58 секунд)
   Post subject:
Reply with quote

uhamurad
Прежде чем переделывать функцию, напишите требования к своей системе и спеку на неё.
Пока не забыли, почему отрублен JOIN.
uhamurad wrote:
Как говориться, возможности прежде эффективности.
Вот возможности-то тут и обрубаются... под корень.
Back to top
View user's profile Send private message
Rin
Участник форума



Joined: 01 Jun 2005
Posts: 515
Карма: 184
   поощрить/наказать

Location: Москва

PostPosted: Wed Apr 30, 2008 10:38 pm (спустя 6 часов 36 минут; написано за 9 минут 38 секунд)
   Post subject:
Reply with quote

uhamurad
>заложенные принципы надо соблюдать

А еще принципы могут меняться по мере появления новых требований к ПО :)
Большинство современных задач для их решения требуют написания SQL запросов с подзапросами и/или JOIN.
Причем выполняться запросы должны быстро. Если страница грузится дольше секунды, у посетителя возникает раздражение (а у клиента тем более). Что точно не стоит делать -- ограничивать свободу в написании SQL запросов.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic All times are GMT + 3 Hours
Page 1 of 1    Email to a Friend.
You cannot post new topics in this forum. You cannot reply to topics in this forum. You cannot edit your posts in this forum. You cannot delete your posts in this forum. You cannot vote in polls in this forum. You cannot attach files in this forum. You can download files in this forum.
XML