|
|
|
| приветсвую =) есть определенная таблица состоящая из полей ID MAINID CODE LEVEL TEXT
в которой находится огромное количество данных которое мне предстоит понять как выводится...
поидее главным полем является MAINID... поэтому get-запросом передается этот id (допустим 2) и по нему выводится часть данных... LEVEL отвечает за однородность данных и за то чтобы данные выводились структурой по уровням в древовидной форме... то есть поидее если mainid = 2 и его level = 1 то нам нада вывести данные этой записи и все записи у которых level = level +1 но вся фишка в том что таких level +1 огромное множество а характерных определенной записи от которой идет все движение не так многа (здесь поидее должны придти на помощь что нить тип того как mainid<$mainid)
вобщем так оч сложно объяснить... но если посмотреть на прикрепление там есть фрагмент таблицы и что то типа схемы чтобы показать от чего к чему мне стоит придти...
и вобщем вопросом всей этой писанины является то что я не могу понять зависимость ну и из за этого составить запрос чтобы выводились нужные данные в древовидной форме...
заранее огромное спасибо =) | |
|
|
|
|
|
|
|
для: eclipse
(26.04.2007 в 15:12)
| | Как насчет того, чтобы привести данные в менее безумном формате? Открывать чужой word-документ нет никакого желания.
В идеале привести SQL-дамп структуры и данных. В phpmyAdmin выводится в разделе export. | |
|
|
|
|
|
|
|
для: Trianon
(26.04.2007 в 15:23)
| | вот часть дампа... =)
если вдруг немного неясно что я имею ввиду древовидной формы то вот как небольшой результат и пример... что то вроде этого
Товарная номенклатура внешнеэкономической деятельности
РАЗДЕЛ I ЖИВЫЕ ЖИВОТНЫЕ; ПРОДУКТЫ ЖИВОТНОГО ПРОИСХОЖДЕНИЯ
01 Живые животные
0101 Лошади, ослы, мулы и лошаки живые:
010110 - чистопородные племенные животные:
010190 - прочие:
|
| |
|
|
|
|
|
|
|
для: eclipse
(26.04.2007 в 15:41)
| | Вычислить родительские ключи можно несложным самосоединением таблицы:
SELECT max( S.MAINID ) AS MID, T.MAINID AS TID
FROM tnvtree AS S
JOIN tnvtree AS T
ON S.MAINID < T.MAINID AND S.LEVEL +1 = T.LEVEL
GROUP BY TID
|
Остается добавить столбик parent_id и заполнить его:
UPDATE tnvtree AS var JOIN
(
SELECT max( S.MAINID ) AS MID, T.MAINID AS TID
FROM tnvtree AS S
JOIN tnvtree AS T
ON S.MAINID < T.MAINID AND S.LEVEL +1 = T.LEVEL
GROUP BY TID
) AS val ON var.MAINID = val.TID
SET var.parent_id = val.MID
|
| |
|
|
|
|
|
|
|
для: Trianon
(26.04.2007 в 16:09)
| | извините... а можно поподробнее немного объяснить... просто я знаю sql на самом простом уровне... раньше большего и не надо было просто.... | |
|
|
|
|
|
|
|
для: eclipse
(26.04.2007 в 16:11)
| | можно.
Но тогда нужно поподробнее спрашивать.
А то неясно про что отвечать. | |
|
|
|
|
|
|
|
для: Trianon
(26.04.2007 в 16:14)
| | слишком нагло наверное расспросить чуть ли не весь код... просто я в первый раз вижу такой синтаксис...
но огромное спасибо за помощь =) думаю разберусь... | |
|
|
|
|
|
|
|
для: eclipse
(26.04.2007 в 16:22)
| | >слишком нагло наверное расспросить чуть ли не весь код... просто я в первый раз вижу такой синтаксис...
А вот тут Вы заблуждаетесь. И про весь код можно ответить, если вопросы будет не один "что это всё значит?" а такие , которые будут прояснять действительно неясные места. "Что означает конструкция join? ", "как работает group by?" , "почему MAX() вычисляет разные значения а не одно?"
Потому что если Вы скажете, "я не знаю как работает SELECT вообще" - останется лишь отправить Вас к учебнику.
>но огромное спасибо за помощь =) думаю разберусь...
удачи. | |
|
|
|
|
|
|
|
для: Trianon
(26.04.2007 в 16:33)
| | не получается у меня все таки разобраться самому пока... поэтому если не затруднит то не могли бы Вы ответить на те вопросы которые Вы привели
>"Что означает конструкция join? ", "как работает group by?" , "почему MAX() вычисляет разные значения а не одно?"
как работает select update etc я конечно же знаю... единственное в первый раз вижу чтобы писалось S.MAINID и T.MAINID... про это тоже интересно узнать... | |
|
|
|
|
|
|
|
для: eclipse
(26.04.2007 в 16:41)
| | 1. конструкция tab1 JOIN tab2 ON условие - соединяет две таблицы в одну.
В результирующей таблице становится столько столбцов, сколько в исходных вместе взятых.
В результирующую таблицу попадают все сочетания строк из tab1 со строками из tab2, которые удовлетворяют написанному условию.
Обращаться к столбцам можно уточняя их именами образующих таблиц: tab1.field1 = tab2.field5
4. Конструкция table_name AS alias дает имени таблицы псевдоним, по которому к ней можно обращаться. Это полезно. когда в одном запросе одна таблица участвует несколько раз - к разным экземплярам можно обращаться по разным псевдонимам. Псевдонимами тоже можно уточнять имена столбцов.
2. GROUP BY работает совместно с так называемыми агрегатными функциями вроде MAX() COUNT() SUM() и т.д.
Если применить MAX() без GROUP BY, сервер вычислит единственное значение по всей совокупности строк запроса. При указании (GROUP BY поля группы) сервер сперва сгруппирует строки по различным значениям указанных в GROUP BY полей, а потом уже вычислит максимумы (или другие агрегатные функции) внутри групп, по одному на каждую группу. При этом в селекте можно писать поля группировки и ссылки на агрегатные функции - никакие другие поля писать нельзя.
3. Потому что указан GROUP BY. Все строки с одинаковым TID участвуют в вычислении своего собственного максимума поля S.MAINID независимо от строк с другим TID | |
|
|
|
|
|
|
|
для: Trianon
(26.04.2007 в 17:05)
| | огромное спасибо за исчерпывающий ответ =) небольшой запрос пополнил мои знания... =) | |
|
|
|
|
|
|
|
для: eclipse
(27.04.2007 в 06:19)
| | всё классна получилось на временном хостинге... а на хостинге где стоит сайт выдало ошибку
MySQL said:
#1104 - The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET SQL_MAX_JOIN_SIZE=# if the SELECT is okay
правда сделал дамп с временного хостинга и залил на постоянный... но все равно интересно в чем ошибка... | |
|
|
|
|
|
|
|
для: eclipse
(27.04.2007 в 09:04)
| | Вообще-то запрос, который я выложил, при достаточно больших таблицах - довольно ресурсоемкий. Для разового запроса, которым нужно поправить таблицу, это вполне приемлемо.
Таблица, возникающая при соединении, достаточно велика и в память не лезет.
Для исполнения запроса надо предварительно выполнить один из двух запросов, предложенных в диагностике, чтобы перестроить сервер на работу с крупными JOINами. | |
|
|
|