phpMyAdmin 2.7

вычислениями в запросе ? никогда бы недодумался, х - это переменная с id нужной группы, которая если где и вычисляется, то в коде программы, про == объяснил уже, что очепятался.

ну, впринципе, если жмёт, можно обойтись и тесктовым полем значений разделенных например | которые будут преобразовываться в массив одним вызовом функции(отожрет не больше, какого-нить ORM)

DbVisualizer умеет значительно меньше, чем phpMyAdmin. На фиг на фиг.

> Надо выводить количество сообщений в каждой "ветке" и подветке дерева и БЫСТРО обновлять их динамически при добавлении сообщений в любое место дерева.

у меня помимо parent_id на родителя имеется еще start_id на начало дерева. в результате брюки просто и элегантно... (с)

:)

> а вот кто может подсказать элегантное решение такой задачи. Есть несколько "деревьев" сообщений. Надо выводить количество сообщений в каждой "ветке" и подветке дерева и БЫСТРО обновлять их динамически при добавлении сообщений в любое место дерева. Рекурсивный обход дерева каждый раз слишком тяжел.

Даю ключевые слова: modified preorder traversal.

Еще две хорошие статьи вываливаются на... пралльна! mysql hierarchical tree. В первой же пятерке. Одна из onlamp.com, вторая из dev.mysql.com.

Гугль вас любит, друзья мои!

> в результате брюки просто и элегантно... (с)

покрываются дырами всевозможных форм и размеров. Ибо предусмотреть все нюансы при такой избыточности простому человеку трудно. Хотя бы потому, что не нужно нафиг.

тот подход не решит проблему.
Есть дерево, каждый элемент узла имеет дополнительные аттрибуты ( местоположение, тип продукта).
Задача: Надо быстро, без пересчета каждый раз, вывести число под-узлов (счетчик) для каждого parent узла С УЧЕТОМ выбранного в данный момент аттрибута или нескольких аттрибутов. Разумеется это число будет меняться при разных комбинациях выбранных аттрибутов. Ничего лучшего, чем создание специальной таблицы для хранения таких "счетчиков" для каждой комбинации аттрибутов я так и не смог придумать.

> покрываются дырами всевозможных форм и размеров

например? у меня работает нормально и удобно.

Дык, так и делаю! Думаешь, у меня таблица как в тех примерах? Нифига. В запросах она еще соединяется с минимум 4 табличками. И -- честно скажу -- это много лучше всяческих костылей, которые в девичестве тоже были перепробованы. Ты попробуй сначала, все же там простая арифметика, это много легче рекурсии.

А у меня дерево всегда отсортировано по текстовому ключику, где закодирован путь в этом самом дереве. Добавление новых узлов и вставка целых веток - тривиально, выборка любой подветки - одним запросом.

В контексте мускуля текстовые ключики are pain in the arse, вообще-то. :-(

а умеет ли сабж хранить историю того, что вытворялось?

> а умеет ли сабж хранить историю того, что вытворялось?

см. логи индейца :)))

$cfg['Servers'][$i]['history'] string Since release 2.5.0 you can store your SQL history, which means all queries you entered manually into the phpMyAdmin interface. If you don't want to use a table- based history, you can use the JavaScript-based history. Using that, all your history items are deleted when closing the window.

Using $cfg['QueryHistoryMax'] you can specify an amount of history items you want to have on hold. On every login, this list gets cut to the maximum amount.

The query history is only available if JavaScript is enabled in your browser.

To allow the usage of this functionality: set up pmadb and the linked-tables infrastructure put the table name in $cfg['Servers'][$i]['history']

>не, имхо такой инструмент нужен когда есть необходимость разобраться в монструозных таблицах.

Да, это - тоже.

>но я в мускуле редко видел БД размером больше 20-30 таблиц (если не счиать клинических случаев типа phpnuke)

20-30 таблиц сейчас в очень многих проектах.

>если неправ - поправь. Лучше с примерами =))

Я свои не буду называть, но из крупных - mediawiki, invisionPB, punBB, вообще, куча продвинутых форумов, tiki, l2j.... десятки, если не сотни проектов :D

>почему мне для форума достаточно 5 таблиц

И как он будет жить на, скажем, хотя бы 500 тыс. сообщений с кучей внутренней логики? :)

Они могут быть и числовыми. Алгоритм тот же.