QTreeView и база данных

[crocus]

Перечитал все, что в гугеле нарыл, них..ра не врублюсь!
Обычная табличка -- ID, parent_ID, level, нужно представить данные в виде дерева.
Не догоняю главного -- что нужно скормить QStandartItemModel (каким должен быть запрос), чтобы начать строить tree.

[lit-uriy]

Если у тебя Представление должно отображать данные из БД то QStandartItemModel не лучший выбор, лучше взять QSqlQueryModel, но по умолчанию она только для чтения, если еще и писать в БД нужно, то прийдется от нее наследника сделать.

[ритт]

Код:

	QString sSql = QString("SELECT id, name FROM elements WHERE parent_id IS NULL OR parent_id=0 ORDER BY name ASC");
	QSqlQuery parentsQuery;
	if(!parentsQuery.exec(sSql))
		return;

	while(parentsQuery.next())
	{
		int parentId = parentsQuery.value(0).toInt();
		QString parentName = parentsQuery.value(1).toString();

		QTreeWidgetItem* parentItem = new QTreeWidgetItem(someTreeWidget, QStringList(parentName));
		parentItem->setData(0, Qt::UserRole + 1, parentId);
		someTreeWidget->addTopLevelItem(parentItem); // вероятно, можно удалить, т.к. в теории QTreeWidgetItem(someTreeWidget, ...) сделает ноду топовой
		{
			sSql = QString("SELECT id, name FROM elements WHERE parent_id=%1 ORDER BY name ASC").arg(parentId);
			QSqlQuery childrenQuery;
			if(childrenQuery.exec(sSql))
			{
				while(childrenQuery.next())
				{
					int childId = childrenQuery.value(0).toInt();
					QString childName = childrenQuery.value(1).toString();

					QTreeWidgetItem* childItem = new QTreeWidgetItem(parentItem, QStringList(childName));
					childItem->setData(0, Qt::UserRole + 1, childId);
				}
			}
		}
	}

т.к. данных у тебя предполагается много, лучше запросы заменить на кверимодель

это, соответственно, для таблички вида

CREATE TABLE  `elements` (
  `id` int(11) NOT NULL auto_increment,
  `parent_id` int(11) NOT NULL default '0',
  `name` varchar(255) NOT NULL,
  PRIMARY KEY  (`ID`),
  KEY `ix_element_1` (`parent_id`),
);

но я ещё раз советую разбить таблицу на две: ид=>данные и ид=>родитель...а код выше использовать как базовый пример для построения сложной модели )

[Alex03]

..........
но я ещё раз советую разбить таблицу на две: ид=>данные и ид=>родитель...а код выше использовать как базовый пример для построения сложной модели )

Константин в посте crocus-а не было ни слова про мастер-деталь (или 2-х уровневость). А в дереве может быть много уровней - табличек не напасёшься...
Кстати в Вашем примере запросы по всей видимости выполняются в разных транзакциях, что не есть гут.

crocus. Если данных не много и надо их все выгрести на клиента, то можно одним циклом на подобие того что привёл Константин.

[pastor]

Подобные темы уже были. Юзаем поиск.

http://prog.org.ru/forum/index.php/topic,4659.0.html

[ритт]

> в посте crocus-а не было ни слова про 2-х уровневость...
Алекс03, я знаю о чём говорю

[ритт]

> А в дереве может быть много уровней - табличек не напасёшься...
хватит двух

[Alex03]

> А в дереве может быть много уровней - табличек не напасёшься...
хватит двух

С тем же успехом можно сказать что хватит одной таблицы.

[crocus]

Всем спасибо, разбираюсь..
Поиск рулит. Видимо глаз замылился.

[Вячеслав]

но я ещё раз советую разбить таблицу на две: ид=>данные и ид=>родитель...а код выше использовать как базовый пример для построения сложной модели )

а можно pro-аргументы за такое чудо ?
contra - 1) лишние индексы (и pk и fk)
2) лишние join'ы при выборке данных
3) в некоторых случаях много _мелких_ записей может серьезно замедлить сервер (mysql и fb меньше  слоник)
Ы ?

[ритт]

> mysql и fb меньше  слоник
ну ты и выражаешься поди-разбери теперь что это должно означать

крокусу нужна категоризация элементов с родительско-дочерней зависимостью
сейчас у него всё в одной таблице и строки при необходимости дублируются, если родителей/детей больше одного

[White Owl]

крокусу нужна категоризация элементов с родительско-дочерней зависимостью
сейчас у него всё в одной таблице и строки при необходимости дублируются, если родителей/детей больше одного

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

[Sergeich]

 Если родителей может быть больше одного, то это уже не дерево, а граф  И как его отображать вообще хер поймешь

[Вячеслав]

> mysql и fb меньше  слоник
ну ты и выражаешься поди-разбери теперь что это должно означать

крокусу нужна категоризация элементов с родительско-дочерней зависимостью
сейчас у него всё в одной таблице и строки при необходимости дублируются, если родителей/детей больше одного

Попиши акты после разборок со смежниками на тему кто дурак и что теперь делать - еще не так будешь выражаться
Имелось ввиду (сам наблюдал) что птиц (и intrbase) и mySql при 17-18млн очень мелких записей - (там было 3 поля дата,код датчика,значение) начинали дико тормозимть при выборке по дате.... Для птица это в теории можно было бы объясниить сборкой мусора - но  mySql не версионник , так-что непонятно .... да, птиц был 2.0x какой-то 2.1 тогда еще небыло .... народ попытался уползти на слонника(postgress) но там грабли начались с 50млн с падением в кору(вроде уже пофикисли ,но опять-таки щаз не смотрели ж) Теперь маленькая версия этой проги живет на Линтере\Sybase ASA большая  на "кластерном дятле" (Оракле)......
А для дерева (не графа) для баз этож вроде классика id,parent_id,(данные )+ => строим отношение один-ко многим (один родитель много детей) ......

[Tonal]

2 Вячеслав
Можешь привести структуру таблички, пример данных и тормозящие запросы для птица?
Или ссылку на обсуждение этого момента?
Можно в личку, чтоб не захламлять форум.