Принятый ответ Герберта Балагтаса хорошо работает, когда массив $ data мал. При больших массивах данных функция array_merge становится слишком медленной. Мой тестовый файл для создания массива $ data имеет 28 столбцов и составляет около 80 000 строк. Окончательный скрипт занял 41 место.
Использование array_push () для создания $ insert_values вместо array_merge () привело к 100-кратной скорости с временем выполнения 0,41 с.
Проблемная array_merge ():
$insert_values = array();
foreach($data as $d){
$question_marks[] = '(' . placeholders('?', sizeof($d)) . ')';
$insert_values = array_merge($insert_values, array_values($d));
}
Чтобы устранить необходимость в array_merge (), вместо этого вы можете построить следующие два массива:
//Note that these fields are empty, but the field count should match the fields in $datafields.
$data[] = array('','','','',... n );
//getting rid of array_merge()
array_push($insert_values, $value1, $value2, $value3 ... n );
Затем эти массивы можно использовать следующим образом :
function placeholders($text, $count=0, $separator=","){
$result = array();
if($count > 0){
for($x=0; $x<$count; $x++){
$result[] = $text;
}
}
return implode($separator, $result);
}
$pdo->beginTransaction();
foreach($data as $d){
$question_marks[] = '(' . placeholders('?', sizeof($d)) . ')';
}
$sql = "INSERT INTO table (" . implode(",", array_keys($datafield) ) . ") VALUES " . implode(',', $question_marks);
$stmt = $pdo->prepare ($sql);
try {
$stmt->execute($insert_values);
} catch (PDOException $e){
echo $e->getMessage();
}
$pdo->commit();
По моему опыту, издержки минимальны, при условии, что человек, пишущий запросы, знает то, что он делает, и примите обычные меры предосторожности, чтобы гарантировать, что сгенерированные запросы оптимальны, что необходимые индексы существуют и т.д. и т.д., Другими словами, влияние базы данных должно быть тем же; на стороне приложения существуют минимальные, но обычно незначительные издержки.
, Который сказал..., существует одно исключение к этому; если единый запрос генерирует несколько агрегатов, поставщик L2S переводит его в выполнение больших запросов с одним подзапросом на агрегат. Для большой таблицы это может оказать значительное влияние ввода-вывода, когда ввод-вывод дб, стоивший за запрос, растет величинами для каждого нового агрегата в запросе.
обходное решение для этого должно, конечно, переместить агрегаты в сохраненный proc или представление. У Matt Warren есть некоторый пример кода для альтернативного поставщика запроса, которые переводят такие запросы более эффективным способом.
Ресурсы:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx? FeedbackID=334211
http://blogs.msdn.com/mattwar/archive/2008/07/08/linq-building-an-iqueryable-provider-part-x.aspx
Спасибо Stu. Нижняя строка, кажется, что LINQ к SQL, вероятно, не имеет значительной производительности базы данных наверху с более новыми версиями, если Вы в состоянии использовать скомпилированный выбор, и более медленные функции обновления, вероятно, будут быстрее, если у Вас не будет ДЕЙСТВИТЕЛЬНО резкого эксперта, делающего большую часть кодирования.