Я не думаю, что Zend_Db поддерживает вставку нескольких строк.
Но если у вас всего две строки или немного больше, вы можете просто использовать цикл.
foreach ($data as $row)
{
$db->insert('table', $row)
}
Билл Карвин, бывший разработчик Zend Framework, написал
это некоторое время назад на Nabble:
Наборы строк в основном представляют собой объект коллекции, поэтому я бы добавил в этот класс методы, позволяющие добавлять строки в набор. Итак, вы должны уметь это делать:
// creates a rowset collection with zero rows
$rowset = $table->createRowset();
// creates one row with unset values
$row = $table->createRow();
// adds one row to the rowset
$rowset->addRow($row);
// iterates over the set of rows, calling save() on each row
$rowset->save();
Нет смысла передавать целое число в createRowset () для создания N пустых строк. Вам просто нужно будет перебирать их, чтобы в любом случае заполнить их значениями. Таким образом, вы также можете написать цикл для создания и заполнения отдельных строк данными приложения, а затем добавить их в коллекцию.
$rowset = $table->createRowset();
foreach ($appData as $tuple)
{
$row = $table->createRow($tuple);
$rowset->addRow($row);
}
$rowset->save();
Имеет смысл разрешить передачу массива массивов в createRowset (), поскольку это согласовывалось бы с использованием передачи кортежа в createRow ().
$rowset = $table->createRowset($appData); // pass array of tuples
Это будет выполнять тот же цикл, что и в предыдущем примере выше (за исключением save () в конце), создавая новый набор новых строк, готовый к save () d.
В SQL есть два способа повысить эффективность вставки данных:
Используйте один оператор INSERT с несколькими строками:
ВСТАВИТЬ В t (col1, col2, col3) ЗНАЧЕНИЯ (1, 2, 3), (4, 5, 6), (7, 8, 9);
Подготовьте оператор INSERT и выполните его несколько раз:
ПОДГОТОВИТЬ ВСТАВИТЬ В t (col1, col2, col3) VALUES (?,?,?); ВЫПОЛНИТЬ 1, 2, 3 ВЫПОЛНИТЬ 4, 5, 6 ВЫПОЛНИТЬ 7, 8, 9
Однако поддержка любого из этих улучшений усложнила бы классы Row и Rowset. Это связано с внутренним способом, которым текущий класс Zend_Db_Table_Row различает строку, которую нужно вставить или обновить, когда вы вызываете save (). Это различие инкапсулировано объектом Row, поэтому Rowset не знает, являются ли отдельные строки новыми строками или измененными копиями существующих строк. Поэтому, чтобы класс Rowset предлагал многострочный метод save (), который использует более эффективный SQL, необходимо полностью реорганизовать управление грязными данными. Более простое решение состоит в том, чтобы набор строк перебирал свои строки, вызывая save () для каждой из них. Это лучше для инкапсуляции объектно-ориентированного программирования, хотя не помогает оптимизировать SQL для вставки набора строк.
В любом случае очень редко массовая загрузка большого количества строк данных в типичном веб-запросе, когда существует наибольшая потребность в эффективном SQL. Разница в эффективности для небольшого количества строк невелика, поэтому это будет заметным улучшением только в том случае, если вы загружаете огромное количество строк массово. В этом случае вам все равно не следует использовать INSERT, вы должны использовать оператор MySQL LOAD DATA или аналогичную функцию, если вы используете другой бренд RDBMS. INSERT обычно не самый эффективный вариант для загрузки большого количества данных.
Что касается возврата автоматически сгенерированных ключей, я бы не стал беспокоиться. Обратите внимание, что если вы используете простой SQL (например, в mysql CLI) и вставляете несколько строк в один оператор INSERT, вы можете получить только последнее сгенерированное значение идентификатора, а не значения идентификатора для всех вставленных строк. Это поведение SQL; это верно для любого языка или любой структуры.
INSERT INTO t (col1, col2, col3) VALUES (1, 2, 3), (4, 5, 6), (7, 8, 9);
SELECT LAST_INSERT_ID(); -- returns only the id for the third tuple
Если вам нужен идентификатор для каждой строки, вы должны написать цикл и вставлять строки по одной, получая сгенерированный идентификатор после каждой вставленной строки.
person
markus
schedule
03.05.2009