Хранимая процедура VS. F #

Question

Для большинства SP-обученных разработчиков нет выбора между Linq и Stored-Процедурами / Функциями.Это может быть правдой.

Однако в настоящее время есть дорожные развязки.Прежде чем тратить слишком много времени на синтаксис F #, я хотел бы получить больше информации о том, где находится сила (и противоположность) F #.

Как F # будет работать в этой теме (против SP)?

F # должен каким-то образом связываться с базой данных.Через Linq2Sql / Entity-app-layer или напрямую через AnyDbConnection.Ничего нового там нет.Но F # обладает способностью параллелизма и меньшими накладными расходами в своей работе ( Функциональное программирование с C # / F # ).Также F # имеет свою эффективность в качестве слоя для данных и машины.Очень похоже на силу C # быть слоем между человеком и машиной.

• Могу ли я по-прежнему позволить серверу БД обрабатывать запрос повторяющихся узлов или просто получать простые данные в F # и обрабатывать их там?Инкапсулировано красиво и плавно, как вызов метода объекта из C #?
• Будет ли хранимая процедура по-прежнему лучшим вариантом для сканирования 50 миллионов записей для поиска сирот или критериев, соответствующих 0,5% результата?
• Будет ли SP или функция все еще работатьлучше всего для такой простой задачи, как поиск следующего родительского узла?
• Будет ли SP лучше всего собирать миллион записей данных и возвращать вычисленные суммы и / или периоды?

Не будет?Неужели единая библиотека f # dll, полностью построенная по принципу единой ответственности, более полезна, чем хранимые процедуры, подключенные к серверу sql?Есть плюсы и минусы, конечно.Но что они?

Answer 1

Хранимые процедуры магически не супербыстрые.Зачастую они на самом деле довольно медленные.

Многие люди понизят этот ответ, предоставив неподтвержденную информацию о том, что однажды хранимая процедура в целом ускорила работу приложения.Однако все те примеры, для которых я на самом деле видел код, указывают на то, что они полностью переосмыслили какой-то плохой SQL, чтобы упаковать его как SP.Я утверждаю, что дисциплина переупаковки плохого SQL в процедуру помогла больше, чем сам SP.

Большинство ваших баллов не могут быть оценены без измеренного теста.

Я предлагаю вам сделатьследующее.

1. Запишите его на F #.

2. Измерьте его.

3. Если это слишкоммедленно для вашего производственного приложения, затем попробуйте некоторые хранимые процедуры, чтобы проверить, быстрее ли это.Если это достаточно быстро для вашего производственного приложения, то у вас есть ответ, F # сработал для вас.Для вашего приложения.Для ваших данных.Для вашей архитектуры.

Нет "общего" ответа.Хотя мои тесты для некоторых конкретных типов запросов показывают, что движок SP довольно медленный по сравнению с Java.F #, вероятно, будет быстрее, чем механизм SP.

Важно убедиться, что база данных - если она будет "чистыми" данными - уже оптимизирована так, чтобы запросы, подобные вашему "сканированию"50 миллионов записей для поиска детей-сирот или критерий, который соответствует 0,5% результата? "будет получать строки как можно быстрее.Это часто включает в себя настройку буферов и размеров массивов, а также других элементов соединения базы данных с F #.Обычно это означает, что вам нужно более прямое соединение, чтобы вы могли регулировать размеры.

Answer 2

Вы спрашиваете следующее:

Будет ли хранимая процедура по-прежнему лучшим вариантом для сканирования 50 миллионов записей для поиска сирот или критериев, соответствующих 0,5% результата?

Я понимаю, что ваш вопрос означает: «У меня есть эти данные на сервере sql.Должен ли я запросить его в SQL или в коде клиента (F # в этом случае).Такие запросы должны быть выполнены в SQL, если это вообще возможно.Если вы делаете это в F #, вы передаете эти 50 миллионов строк клиенту просто для выполнения агрегации / поиска.

Надеюсь, я правильно понял ваш вопрос.

Answer 3

Базы данных эффективны для определенных задач (например, когда они могут использовать индекс для поиска указанной строки), но, вероятно, не будут работать быстрее, чем F #, если вам нужно обработать все строки и обновить их (в базе данных) или вычислить некоторый новый результат, основанный на всех данных.

Как предлагает С. Лотт, лучший вариант - попробовать реализовать то, что вам нужно, в F #, и вы узнаете. Параллелизм может дать вам некоторые преимущества в производительности, особенно если вы выполняете сложные вычислительные вычисления. Тем не менее, вы все равно можете хранить данные в базах данных, загружать и обрабатывать их в F # (я полагаю, именно так F # использовался adCenter в Microsoft).

Возможно, наиболее важным примечанием является то, что базы данных дают вам различные гарантии согласованности данных - независимо от того, что произойдет, у вас все равно останется согласованное состояние. Осуществить это самостоятельно может быть сложно (например, при обновлении данных), но вы должны решить, нужно ли вам это или нет.

Answer 4

Как я понимаю, SP просто означает, что вы вызываете какой-то предварительно скомпилированный план выполнения, и вы можете вызывать его через API, а не отправлять строку на сервер. Эти два значения сохраняются в порядке миллисекунд, и далеко не за секунду. Для больших запросов эта разница незначительна. Они хороши для высокочастотной / пропускной способности (и, конечно, инкапсулируют сложную логику, но это, кажется, здесь не применимо).

Поскольку SP использует скомпилированный план, он действительно может быть медленнее, чем обычный запрос, поскольку он больше не проверяет статистику базовых данных (поскольку план выполнения уже скомпилирован.) Поскольку вы упоминаете условие, которое применяется к 0,5 % строк, это может быть важно.

В обсуждении SP против F # я бы перефразировал это как «на сервере» против «на клиенте». Если вы говорите о больших объемах данных (соответствует 50M строк), мой первый выбор всегда будет «поставить мельницу там, где есть дрова», это означает, что по возможности выполняйте на сервере. Только если есть какая-то очень сложная логика, вы можете рассмотреть F #, но я не думаю, что это применимо. Тогда я все же предпочел бы выполнить это на сервере, а не перетаскивать все эти строки по сети (возможно, медленно).

GJ