Сколько приложений "smarts" должно находиться в базе данных?

Ответ 1

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

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

Существует также несколько действующих технических причин:

• Процедурные расширения SQL (например, T-SQL), используемые для разработки хранимых процессов, традиционно не имеют определяемых пользователем типов данных, отладки, переносимости и взаимодействия с внешними системами - все качества, полезные для разработки надежного крупномасштабного программного обеспечения. (И неуклюжий синтаксис не помогает.)
• Контроль версий программного обеспечения (например, svn) хорошо работает для управления даже очень большими кодовыми базами, но управление изменениями схемы БД является более сложной проблемой и менее хорошо поддерживается. Каждый серьезный магазин использует контроль версий для своей прикладной кодовой базы, но у многих до сих пор нет строгой системы управления своими базами данных; следовательно, хранимые procs могут легко попасть в неверсированную "черную дыру", что делает кодеры правильно нервными.

Мое личное мнение состоит в том, что чем ближе основная бизнес-логика к данным, тем лучше, особенно если более одного агента обращаются к БД (или могут делать в будущем). Это неудачный артефакт истории, что T-SQL и его ilk были слабыми языками, что привело к возникновению идеи о том, что "данные и логика должны быть разделены". Мой идеальный мир - это тот, в котором каждое бизнес-правило инкапсулировано в принудительном принудительном доступе к базе данных, и все несоответствия не срабатывают быстро.

Ответ 2

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

И если я вижу другого придурка, использующего * SELECT * FROM blah *, я собираюсь сходить с ума...: -)

Ответ 5

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

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

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

Ответ 10

Я думаю, что те "разработчики", которые создали базы данных без индексов или с одним столбцом VARCHAR (2000), являются просто специалистами в области искусства, которые делают первую попытку войти в дорогостоящий мир ИТ. Никто из тех, кто хоть немного занимается ИТ-образованием, создает такие структуры баз данных.

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

Ответ 11

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

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

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

Ответ 12

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

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

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

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

Ответ 13

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

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