Функции в mysql или php

Ответ 1

Я пытаюсь задуматься о базе данных как о месте, где можно сохранить материал, и поместить весь код абстракции в другое место. Выражения базы данных достаточно сложны уже без добавления к ним функций.

Кроме того, оптимизатор запросов будет работать над любыми выражениями с функциями, если вам когда-либо придется делать что-то вроде "SELECT.... WHERE MD5 (xxx) =..."

И функции базы данных не очень переносимы в целом.

Ответ 2

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

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

Вторая причина в том, что мне нравится, чтобы мой код SQL был как можно более переносимым. Я даже не хочу пытаться подсчитать разные варианты SQL, которые существуют, поэтому я пытаюсь сохранить функции (особенно нестандартные расширения) из моего кода SQL, за исключением таких вещей, как SUM или MIN/MAX.

Я предполагаю, что я говорю, SQL предназначен для хранения и извлечения данных, и его следует сохранить с этой целью. Используйте свой язык обслуживания для выполнения любых расчетов заранее и сохраните свой код SQL.

Ответ 3

Лично я стараюсь, чтобы база данных была простой (до минимума) с помощью Insert, Update, Delete без слишком большой функции, которая может использоваться в коде. Stored Proc - то же самое, содержит только задачу, которая очень близка к данным персистентности, а не к бизнес-логике.

Я бы поставил MD5 снаружи. Это позволит встретить эту "манипуляцию данными" за пределами области хранения базы данных.

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

Ответ 4

Используйте свою базу данных как средство сохранения целостности данных. И оставить бизнес-логику вне ее.

Если вы поместите бизнес-логику, любой из них в вашей базе данных, вы делаете ее более сложной для управления и обслуживания в будущем.

Ответ 5

Я думаю, что большую часть времени вы захотите оставить манипуляции с данными на веб-сервере, но если вы хотите обрабатывать базы данных в отношении таблиц, отношений и т.д., тогда перейдите к БД.

Я лично лоббирую свою компанию, чтобы обновить наш сервер MySQL до 5.0, чтобы я мог начать использовать процедуры (которые убивают пару сайтов, которые мы администрируем).

Ответ 6

Как и другие ответы, я предпочитаю хранить всю бизнес-логику в одном месте. А именно, мой язык приложения. (Более конкретно, в объектной модели, если она присутствует, но не весь код является OO.)

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