SQL по сравнению с КОДОМ, Где баланс?

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

В нашей группе существует несколько случаев.

Обработка, которая может быть удовлетворена ВСТАВЛЕНИЕМ/ВЫБИРАНИЕМ

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

Повреждение Управления, обрабатывающее

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

Комплекс, Обрабатывающий

, программа создает выбор и выполняет его в контексте сервера. Набор результатов высосан назад к программе, строке строкой, где код интенсивная обработка происходит. Результат переходит к файлу или UPSERT назад в базу данных.

Производительность, Очень важная

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

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

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

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

Если выполнение его в SQL делает его более управляемым, сделайте это в SQL. Если выполнение его в коде делает его более управляемым, сделайте это в коде.

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

исключение - это: ВЫБЕРИТЕ col1, col2, таблица

col3 FROM, которая презентация: col1, col2, col3, col1/col2, col1/col3...

, Если я получаю все операнды в уравнении, я сделаю это в коде, в противном случае я сделаю это как часть запроса (выберите col1, col2, col1/col4...)

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

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

Все это "управление говорит", сказал, существуют некоторые основы, которые другие детализировали здесь, что я отзовусь эхом также:

• Отсутствие хорошего дизайна DB не может быть преодолено прохладная сложность в коде
• , Целостность данных является заданием базы данных
• , Решают сложные проблемы с процессуальным кодексом - нет ничего как чтение хорошо прокомментированного, код структуры.
• Создание отчетов от объектов области может быть чрезвычайно трудным, и набор навыков для того, чтобы написать отчеты обычно совпадает с большим опытом DB, не DDD.

Я использую SQL для запросов (декларативный), а Python для Процедуры (пошаговые операции).

Мы используем.NET 3.5 и LINQ к SQL - таким образом, мы - 100%-й код и никакой рукописный SQL вообще. Это - счастье!

Вот часть торговли offs, я рассмотрел бы:

• Набор по сравнению с отдельным манипулированием данными
• Большой по сравнению с небольшими объемами данных
• Секрет по сравнению с несекретными битами (открытый код)
• , Единственный по сравнению с несколькими целями платформы дб
• Возможно снова использованный код библиотеки или проект, конкретный
• SQL по сравнению с наборами навыков разработчика кода

... Я сообщу, думаю ли я о чем-либо еще.

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

Вся бизнес-логика должна быть сделана в рамках приложения. Можно запустить с SQL-сервера, но если изменение политики к Oracle. Вы просто перемещаете свои данные в Oracle и никакую потребность переписать любые коды.

Или некоторые приложения, должен поддерживать несколько дб, таким образом, Вы просто сделанный все коды в приложении. Когда у Вас есть проблемы, Вы просто устраняете проблемы только в приложении. Никакая потребность устранить проблемы в нескольких дб.

, Чтобы сделать это, все коды CRUD должны быть сгенерированы в рамках приложения. Это означает, что Вы нуждаетесь в хорошей платформе ORM (Linq, В спящем режиме) сделать задание.

Мои правила для того, когда использовать sql:

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

Держат Вашу логику вместе.

Думают о других разработчиках, которые приедут позади Вас. Запишите это в месте, это будет самым ясным.

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

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

у Нас есть Хранимая процедура для ОБНОВЛЕНИЯ. Это имеет параметр для, Должен существовать, не Должен существовать или не заботятся. Таким образом, если оператор использует СОЗДАТЬ процесс затем, запись должна быть новой; при использовании ИЗМЕНИТЬ процесса затем должна существовать учетная запись; при выполнении своего рода импорта, возможно, Вы хотите UpSert, в этом случае Вы не заботитесь.

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

Наша процедура обновления имеет параметры для каждого поля в таблице, значении по умолчанию параметров к ПУСТОМУ УКАЗАТЕЛЮ - кроме полей PK, которые должны быть обеспечены :)

, поле пустой строки будет поэтому предоставлено процедуре, и поля, которые не находятся на форме, не будут, и принимать значение по умолчанию к ПУСТОМУ УКАЗАТЕЛЮ. Не разрешено передать поле формы как ПУСТОЙ УКАЗАТЕЛЬ - все поля, которые были на форме, должен передать значение.

Для существующих записей, быть обновленным, мы рассматриваем ПУСТОЙ УКАЗАТЕЛЬ как "никакое изменение" и значение как порождение изменения. Однако мы не позволяем устройство хранения данных пустой строки, таким образом передавание параметра пустой строки заставляет поле в той записи быть измененным на ПУСТОЙ УКАЗАТЕЛЬ. (Особенно относящийся к типам даты, например, поскольку только допустимые даты могут быть сохранены, не пустые строки; и пустую строку для числа, вероятно, рассматривали бы как Нуль, если бы мы не применяли это правило)

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

Дополнительно мы позволяем Процедуре Обновления возвращать Код ошибки Проверки. В общей проверке формы поля выполняется приложением - во-первых использование JavaScript в Клиенте для осуществления дат, как являющихся допустимым, и так далее; во-вторых, приложение может применить то же (для безопасности) и дополнительные проверки. И наконец процедура базы данных может выполнить дальнейшие проверки - например, проверить, что Объект Порядка имеет соответствующую запись Заголовка заказа; пока это также осуществляется ограничением Внешнего ключа, нам не нравится иметь необходимость поймать (и интерпретировать) ошибка базы данных, которая заканчивается, таким образом, Процедура Обновления проверяет и возвращает код ошибки / сообщение, которое полезно для приложения (и соответствует сообщению, сохраняемому в Ошибочной Таблице, которая может быть отображена к Оператору, таким образом, они знают то, чем проблема была). Ограничение Внешнего ключа все еще на месте как ловец помехи.

Мы также механическое устройство генерируют Получать/Читать процедуру. Это возвращает все поля для одной строки. Параметр к процедуре является всеми полями PK. Это может использоваться формами CRUD для получения любых существующих данных. Мы используем это, а не конкретную процедуру по каждой форме, в знании, что она получает все столбцы, и некоторые из них не могут требоваться на определенной форме. Это - только одна строка, получают, и вероятность - то, что все поля будут представлены на форме обслуживания CRUD. Однако на основе 80:20 ri; правило мы более осмотрительны на формах для записей, которые имеют Столбцы текста, которые не находятся на форме - ясно, получая много K данных, которые не находятся на форме, не хорошо. Для остатка мы чувствуем, что непротиворечивость программирования и наличия относительно немного исключений, уменьшает ошибки, и снижение расходов перевешивает любые дополнительные полученные данные.

Этот подход также означает, что, поскольку схема базы данных изменяется, Процедуры являются подъемом с изменениями и обнаружат проблемы, которые это теперь вызывает с существующими формами. Например, если столбец будет переименован, то форма сразу перестанет работать - путем попытки назвать процедуру с параметром, который больше не действителен, или при помощи столбца, который больше не получается. Мы можем изолировать для этого в случае необходимости для назад совместимости - позволяют процедуре Обновления иметь дополнительный параметр с настоящим именем и ОБЪЕДИНЯТЬ это с параметром, представляющим новое название столбца и иметь Получать/Читать столбцы дубликата возврата в наборе результатов и с Новыми и со Старыми названиями.

Так же для Удаляют. Процедура механически сгенерирована, берет PK в качестве параметра и имеет способность возвратить сообщение Проверки (например, при попытке удалить Заголовок заказа, если это все еще имеет дочерние записи Объекта Порядка).

Все наши таблицы имеют поля для Создателя, Создают дату, Updater, дату Обновления и также EditNo - который увеличен каждый раз, когда запись сохраняется. Значение EditNo, дан Форме (в Скрытом Поле ввода) и таким образом передан или Обновлению или Процессу удаления. Это должно соответствовать значению существовать записи, иначе запись была изменена другим оператором, и более позднее обновление отклоняется (снова, процедуры Обновления предоставляют полезное сообщение оператору - включая то, кем другой updater был, и в какое время).

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

Это имеет все столбцы в основной записи плюс Действие - Обновление, или Удалите - и Контрольная Дата. Записи вставляются в Архив Обновлением/Удалением, Включают основную таблицу.

Мы также механически генерировали, Находят процедуры. Они имеют параметры, которые соответствуют полям в таблице, но могут быть для Запуска/Конечных точек (например, диапазон дат порядка), Точное совпадение, или "содержит" соответствие - такое как "Имя как XXXX". Они возвращают только определенные поля, которые на самом деле используются дисплеем, и механически сгенерированная процедура имеет подходящий оператор Where с помощью определенных параметров. На практике эти процедуры изменяются вручную, чтобы быть рукой, оптимизированной и т.д., но полезны, сначала подавая заявку для обеспечения многообещающего начала для пользовательского запроса данных.

Я сделал CRUD, программируя как консультант для 10 + годы в деловом мире. Я могу сказать Вам, что поместил столько же бизнес-логики в sprocs & представления, как я могу (и имеет смысл). Требования имеют тенденцию изменяться каждый раз, когда удары ветров и логика наличия в базе данных помогают измениться, и (с достойными комментариями) это сам документирование. Плюс sprocs делают для хорошей безопасности и для легкого повторного использования кода. В бизнесе sprocs приложение.

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

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

, Но, серверный код, в форме SQL-операторов, важен для соответствующей производительности. Присоединение, фильтруя и сортируя данные почти всегда принадлежит SQL, потому что база данных сделает это быстрее и легче, чем можно сделать на стороне клиента. Как показывает опыт, если я - написание кода, которое использует курсоры SQL, чтобы отфильтровать или отсортировать recordsets, я, вероятно, делаю что-то не так и должен переместить ту логику в SQL, где это будет быстрее, легче записать, и легче понять.

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

Это - меньше SQL по сравнению с вопросом о Коде и больше Клиента по сравнению с вопросом о Сервере. Вся эта мысль о Клиенте/сервере состоит в том, чтобы позволить серверу предоставить услугу клиентам централизованным способом. На практике это означает:

• , Если сервер может сделать это быстро затем, делают это на сервере
• , Если сервер может возвратиться, маленький результат затем делают это на сервере
• , Если можно скрыться, сложность от клиента затем делают это на сервере

, Многие включенные проблемы найдены в других областях проектирования, таких как Объектно-ориентированное проектирование. Услуги предоставления класса другим классам должны инкапсулировать функциональность и только выставить то, что необходимо ее клиентам. То же идет для SQL-сервера. При размышлении о SQL-сервере как о простой информационно-поисковой системе затем, Вы не пользуетесь надлежащим премуществом.

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

Что касается того, где точно разграничить..., нет никакого волшебного ответа. Реальный ответ - то, что схема базы данных + хранимые процедуры + представления определяют API, и хороший дизайн API не тривиален, но это стоит стычки. Используйте принципы, такие как сокрытие информации, инкапсуляция, сцепление и все те другие вещи, которые Вы используете в остальной части Вашего программирования и дизайнерской работы. Они являются соответствующими здесь.

Которые делают Вы имеете:

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

ИЛИ

• Великие кодеры, которые освоили язык и платформы, раньше разрабатывали приложение.

, Если ответ на вышеупомянутое является разработчиками DB, Ваша сильная сторона, затем делают работу в DB. Действительно хороший парень DB может обеспечить функциональность, таким образом, Ваш код может быть, падают замертво простые. Могли бы быть несколько более распространений в прямом и обратном направлениях (и это может быть уничтожителем в некоторых ситуациях), но производительность может быть очень хорошей. Большая проблема вокруг нет многих действительно талантливых людей DB.

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

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

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

база данных А не является местом для выполнения логики даты или обработки строк. Это не место, чтобы вычислить балансы или генерировать рассылки. Эти проблемы лучше обращены с другими инструментами (такими как код).

Мое решение о коде по сравнению с sql обычно зависит, на котором кажется самым легким/самым быстрым для реализации. После того как это там, я иду дальше. Позже, если кажется, что это должно быть перемещено, это перемещено. < пожатие плеч > я пытаюсь не потеть он слишком много вначале, все же.

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

1. Получают доступ к базе данных как несколько раз как возможной.

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

3. сценарий ответственен за управление данными, если индекс не существует, который помогает базе данных.

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

5. Никогда не помещает запрос в цикл. Всегда существует способ привести к тому же результату в одном запросе (иначе соединение).

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

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

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

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

, Например, фильтрующие данные определенным полем должны быть до базы данных. Агрегация общих количеств для дисплея на отчете должна быть сделана в базе данных. Незначительная связанная с данными логика (например, триггеры, которые осуществляют целостность данных) должна быть сделана в обоих (не стреляйте в меня для того комментария!) для проверки приложение является защищенным.

Фактическая бизнес-логика, такая как применение скидки, если общее количество порядка составляет более чем 500$, должна быть сделана в коде и иметь окончательное значение, только сохраненное в базе данных. Если сумма скидки варьируется на основе клиентского типа, однако, то сумма скидки должна быть сохранена в базе данных, но не логике, которая делает вычисление.

Что-либо, что касается целостности данных, должно быть сделано в базе данных. Причина этого состоит в том, что данные могут быть затронуты mulitple источниками не только пользовательский интерфейс. Таким образом, базы данных должны сохранить ключевые отношения, ограничения на данные, которые позволяются в поле, значения по умолчанию и т.д. Триггеры, должен, если ограничения слишком сложны для регулярного ограничения. Типы данных должны быть тщательно продуманы и подача до некоторой степени как ограничения. Если данные предназначаются, чтобы использоваться в математике calulations, некоторый тип числового типа данных должен использоваться (не плавание или реальный), это, данные являются датой, всегда используйте тип данных datetime для prevnt не даты от того, чтобы быть сохраненным. Если данные являются числовыми, но не предназначенными для математических вычислений (SSN, например), хранилище это в строковом типе данных, но помещают ограничение на него, чтобы удостовериться, что все сохраненные значения являются числами.

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

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