Сколько из приложения “ум” должны находиться в базе данных? [закрытый]

Мне нравится не допускать логику в базу данных. Я склонен избегать хранимых процедур и триггеров. Я действительно, тем не менее, всегда использую надлежащие типы данных, ключи, indicies и ограничения. Путем я вижу, что случается так, что база данных является базой данных, и приложение является приложением. База данных должна сохранить Ваши данные сохраненными правильно и эффективно тогда как приложение должно владеть логикой. Возможно, я никогда не был в ситуации, где хранимая процедура или триггер были необходимы; и таким образом никогда не склонный использовать их для решения проблемы. Но мне, давая логике дом на базе данных кажется "грязным" мне; я управлял бы всем из самого приложения.

В конечном счете база данных и как Вы соединяетесь с ним, является Вашей "персистентностью API" - сколько находится в базе данных и сколько находится в приложении, специализировано. Но важный аспект - то, что граница API ответственна за создание или потребление корректных данных.

Лично я предпочитаю, чтобы тонкий слой доступа в приложении и sprocs/PKs/FKs в базе данных осуществили транзакционную правильность и включили управление версиями API. Это также позволяет другим приложениям изменять базу данных, не нарушая модель данных.

И если я вижу, что другой идиот использует *ВЫБОР * ОТ вздора*, я собираюсь сойти с ума с Узи... :-)

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

"База данных должна сохранить Ваши данные сохраненными правильно и эффективно тогда как приложение должно владеть логикой" - Nelson LaQeut в другом ответе.

Это, кажется, затруднение проблемы: та вся "логика" принадлежит приложению а не базе данных. Но что предназначено "логикой"? Существуют различные виды "логики", некоторые из которых принадлежат приложения и некоторых, я сказал бы, лучше помещенный в базу данных.

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

Лагерь приложения видит, что база данных является "просто" местом, чтобы хранить данные, которые "принадлежат" их приложению. Лагерь базы данных (который является, где я сижу) видит приложение как "просто" одно (возможно, в настоящее время единственное) пользователь данных, которые "принадлежат" базе данных - или скорее который принадлежит бизнесу и управляется для бизнеса базой данных (DBMS = система управления базами данных).

Если вся Ваша логика данных будет занята в Вашем приложении, что происходит, когда приложение должно быть переписано в последней модной парадигме (или Вы думаете, что J2EE, например, является последним то когда-либо будет)? Как Tom Kyte часто говорит, это - все о данных.

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

Для резюме в этом ответе, который, вероятно, получит downvoted: SQL является IE6 мира языков базы данных. Это нарушает многие правила реляционной модели - другими словами, это немного похоже на калькулятор, который выполняет умножение неправильно и не имеет минус оператор. SQL не достаточно завершен, чтобы быть действительным решением. Это никогда не разрабатывалось вне стадии опытного образца и никогда не предназначалось, чтобы использоваться в промышленных настройках. Но затем это наивно использовалось оракулом, который оказался "приложением-приманкой", SQL стал промышленным стандартом вместо своих технически превосходящих конкурентов, и остальное - история. Синтаксис SQL базируется вокруг ряда инструментов обработки табличных данных командной строки и КОБОЛа. Полный ошибок, несоответствий и путаницы собственные версии и функции, которые не имеют основания в математике или логике, результатах в ситуации, где действительно неясно, что идет где.

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

Если бы история теряла значение логическим и организованным способом, ответ на Ваш вопрос был бы прост: Просто следуйте правилам реляционной модели, и все разрешится. К сожалению, правила реляционной модели не соответствуют чисто текущей обрезке основанного на SQL DBMS, так некоторая игра прикладного уровня или триггеры, или независимо от того, что другой глупый патч, к сожалению, необходим, и это заканчивает тем, что было делом субъективного вкуса, а не обоснованным аргументом, какой глупый взлом Вы используете.

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

Хотя я лично полагаю, что База данных должна иметь достаточно ума для защиты себя, некоторые люди, которые не понимают, что Базы данных не являются немыми сервисами, думайте, и весьма правильно, обратите внимание, что данные и логика должны быть разделены. Теперь во многих случаях разделение данных и логики является мощным инструментом, однако большинство баз данных уже предоставляет нам серьезные реализации атомарности, дублирования, обработки, проверки, и т.д... И много раз это - то, где это принадлежит, однако начиная с качества этих сервисов и их API отличается среди поставщиков, многие прикладные программисты чувствовали себя подобно, который стоит попытаться реализовать этот вид материала на прикладном уровне, постараться не связывать себя определенным слоем базы данных.

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

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

Я думаю, что те "разработчики", которые создали базы данных без индексов или с единственным столбцом VARCHAR(2000), являются просто художественными крупными фирмами, которые предпринимают их первую попытку во ввод дорогостоящего мира IT. Никто, кто имеет даже немного образования IT, не делает этот вид структур базы данных.

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

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

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

У меня есть простая философия.

• Если это - потребность сохранить базу данных безопасной и в последовательном состоянии, удостоверьтесь, что сделали это в базе данных

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

По существу я пытаюсь рассматривать базу данных как псевдо объект. Набор методов, которые я могу назвать, и т.д., но я не хочу, чтобы приложение заботилось о детали внутреннего хранения данных.

Используйте ограничения в базе данных, но для любой сложной логики я поместил бы это в уровень доступа к данным или использовал бы один из инструментов Relational Mapping (ORM) стандартного объекта, таких как Hibernate/NHibernate.

Существует распространенное мнение, что это будет влиять на производительность; на основе представления, что хранимые процедуры предварительно компилируются, но 'необработанные' запросы должны быть скомпилированы на каждом вызове. Однако я работаю главным образом в SQL Server 2005/2008, и это очень эффективно при обработке 'необработанных' параметризированных запросов, кэшируя скомпилированный путь запроса для будущих вызовов к базе данных. Это означает, что там под SQL Server нет по существу никакого различия между производительностью хранимых процедур к параметризованным SQL-запросам.

Единственный недостаток при потере хранимых процедур - то, если Вы очень детализированы со своими правами доступа базы данных, и чтобы осуществить безопасность на уровне входа в систему базы данных.