Propel, relacja "n do m", niska wydajność Opcje

[joebezucha]

Witam,

Pracuje wlaśnie nad projektem z wykorzystaniem frameworka Symfony i pojawił sie pierwszy problem. Problemem jest wydajność Propel-a.

Fragment opisu schematu bazy danych:

[SQL] pobierz, plaintext 
CREATE TABLE `answer`
(
	`id` INTEGER  NOT NULL AUTO_INCREMENT,
	`question_id` INTEGER  NOT NULL,
	`no` INTEGER  NOT NULL,
	`body` TEXT  NOT NULL,
	`scale` INTEGER,
	`grade` INTEGER,
	PRIMARY KEY (`id`),
	INDEX `FI_answer_1` (`question_id`),
	CONSTRAINT `FK_answer_1`
		FOREIGN KEY (`question_id`)
		REFERENCES `question` (`id`)
		ON DELETE CASCADE
)Type=InnoDB;
 
CREATE TABLE `test`
(
	`id` INTEGER  NOT NULL AUTO_INCREMENT,
	`status` INTEGER  NOT NULL,
	`test_type` INTEGER  NOT NULL,
	`lname` VARCHAR(40)  NOT NULL,
	`fname` VARCHAR(24)  NOT NULL,
	`birthdate` DATE  NOT NULL,
	`sex` CHAR  NOT NULL,
	`school_type` INTEGER  NOT NULL,
	`user_id` INTEGER  NOT NULL,
	`password` VARCHAR(20),
	`created_at` DATETIME,
	`timestart` DATETIME,
	`timefinish` DATETIME,
	`ip` VARCHAR(15),
	PRIMARY KEY (`id`),
	INDEX `FI_test_1` (`user_id`),
	CONSTRAINT `FK_test_1`
		FOREIGN KEY (`user_id`)
		REFERENCES `user` (`id`)
		ON DELETE CASCADE
)Type=InnoDB;
 
CREATE TABLE `test_answer`
(
	`test_id` INTEGER  NOT NULL,
	`answer_id` INTEGER  NOT NULL,
	PRIMARY KEY (`test_id`,`answer_id`),
	INDEX `FI_ta_1` (`answer_id`),
	CONSTRAINT `FK_ta_1`
		FOREIGN KEY (`answer_id`)
		REFERENCES `answer` (`id`)
		ON DELETE CASCADE,
	CONSTRAINT `FK_ta_2`
		FOREIGN KEY (`test_id`)
		REFERENCES `test` (`id`)
		ON DELETE CASCADE
)Type=InnoDB;
[SQL] pobierz, plaintext 

Jak widać są tu 3 tabele test, asnwer, i tabela test_answer która odpowida za relacje "n do m"

W skrypcie PHP mam:

[PHP] pobierz, plaintext 
<?php
$this->test = TestPeer::retrieveByPk($this->getRequestParameter('id')); // 1*
$c = new Criteria();
$c->setLimit(10);
$test_answers = $this->test->getTestAnswersJoinAnswer($c);   // 2*
foreach ($test_answers as $test_answer){
  $answer = $test_answer->getAnswer();
}
?>
[PHP] pobierz, plaintext 

No i w tym momencie pojawił się problem z wydajością PROPELa. Czas tworzenia kolekcji $test_answers rośnie po exponencie;) przy limicie ustawionym na 200 skrypt zostaje zakończony w wyniku przekroczenia limitu czasu(60sekund). No a wszystkich odpowiedzi mam do pobrania 214.

W narzędziu WebDebug (część frameworka Symfony) widze, że wykonywane są tylko dwa zapytania do bazy:
1* pobranie testu
2* pobranie danych z tabel test_answer złączonej z answer

Czyli nie ma problemu z zapętlaniem zapytań do bazy danych.
Zresztą robie wszytsko zgodnie z instrukcją propel.phpdb.org/trac/wiki/Users/Documentation/1.2/ManyToManyRelationships

Czy Propel jest aż tak mało wydajny?(IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif)

Potrzebuję pełnych danych odpowiedzi na pytania testowe do przeliczenia wyników końcowych. Mogę oczywiście obejść Propela, skorzystac bezposrednio z Creola i operować na tablicach zamiast na obiektach. No ale zastanawia mnie ta bardzo niska wydajność.

Jakieś pomysły?(IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Ten post edytował joebezucha 2.07.2007, 15:19:31

[splatch]

Przyczyną na 90% będzie jedna z metod hydrate, która jest zaimplementowana w sposób nie do końca optymalny. Jakiś czas temu opublikowałem notę z poprawionym generatorem, który tworzy wydajniejszy kod, z racji na zastosowanie identity map.