SQL vs CODE, Где баланс?

Ответ 1

Мои приоритеты:

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

• Свести к минимуму сложность SQL. Даже если мы меньше посещаем базу данных, это не означает создание слишком сложного SQL-запроса, который не работает и делает слишком много. Запрос по-прежнему необходимо поддерживать, и если два простых запроса сохранят головную боль при разработке и поддержании одного мега-запроса, то вместо использования базы данных следует использовать дополнительный код.

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

Ответ 6

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

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

Фактическая бизнес-логика, такая как применение скидки, если общая сумма заказа превышает 500 долларов США, должна быть выполнена в коде и иметь окончательное значение, которое хранится только в базе данных. Однако если размер скидки зависит от типа клиента, то размер скидки должен храниться в базе данных, но не в той логике, которая выполняет расчет.

Ответ 7

• Доступ к базе данных можно в кратчайшие сроки.

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

• script отвечает за управление данными, если не существует индекса, который упрощает работу с базой данных.

• База данных должна существовать без script. Работы Cron хороши, но база данных должна выживать, если script не выполняется в определенное время.

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

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

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

Ответ 8

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

Ответ 9

Что у вас есть:

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

ИЛИ

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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

Ответ 12

Единственный разумный ответ на этот вопрос - это зависит.

Ответ 13

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

Ответ 17

Вот некоторые из компромиссов, которые я бы рассмотрел:

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

... Я дам вам знать, если я подумаю о чем-нибудь еще.

Ответ 18

Мои правила использования sql:

Не делайте вызов базы данных при переходе через набор записей.

Держите свою логику вместе.

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

Ответ 19

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

У нас есть хранимая процедура для UPDATE. У него есть параметр Must Must, не существует или не заботится. Поэтому, если оператор использует процесс CREATE, запись должна быть новой; если используется процесс MODIFY, то учетная запись должна существовать; если вы делаете какой-то импорт, возможно, вам нужен UpSert, и в этом случае вам все равно.

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

В нашей процедуре обновления есть параметры для каждого поля в таблице, параметры по умолчанию - NULL - кроме полей PK, которые должны быть предоставлены:)

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

Для существующих записей, обновляемых, мы рассматриваем NULL как "без изменений" и значение, вызывающее изменение. Однако мы не разрешаем хранить пустую строку, поэтому передача параметра пустой строки приводит к изменению поля в этой записи в NULL. (Особенно актуально для типов Date, например, поскольку могут храниться только допустимые даты, а не пустые строки, а пустая строка для числа, вероятно, будет обрабатываться как Zero, если мы не применяем это правило)

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

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

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

Этот подход также означает, что по мере изменения схемы базы данных процедуры Процедуры вступают в действие с изменениями и будут выявлять проблемы, которые теперь возникают с существующими формами. Например, если столбец переименован, форма немедленно завершится неудачей - попробуйте вызвать процедуру с более недействительным параметром или с помощью столбца, который больше не извлекается. Мы можем изолировать для этого, когда это необходимо для обратной совместимости - разрешить процедуре обновления иметь дополнительный параметр с исходным именем и COALESCE с параметром, представляющим новое имя столбца, и иметь дубликаты столбцов Get/Read в наборе результатов с обоими Новые и старые имена.

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

Все наши таблицы имеют поля для Creator, Create date, Updater, Дата обновления, а также EditNo - который увеличивается при каждом сохранении записи. Значение EditNo присваивается форме (в поле скрытого ввода) и передается, таким образом, в процедуру "Обновление" или "Удалить". Он должен соответствовать существующему значению записи, иначе запись была изменена другим оператором, а последующее обновление отклонено (опять же, процедуры обновления предоставляют полезное сообщение оператору - включая тех, кто был другим обновлением, и в какое время).

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

Это все столбцы в основной записи, а также действие - обновление или удаление - и дата аудита. Записи вставляются в архив путем обновления/удаления триггера в главной таблице.

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

Ответ 20

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

Вся бизнес-логика должна выполняться в приложении. Вы можете начать с Sql Server, но если политика изменится на Oracle. Вы просто переносите свои данные в Oracle, и не нужно переписывать какие-либо коды.

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

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

Ответ 21

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

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

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

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

Ответ 22

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

Исключением является следующее: SELECT col1, col2, col3 FROM table

Презентация: col1, col2, col3, col1/col2, col1/col3,...

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

Ответ 23

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

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

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

Ответ 24

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

Обработка, которая может быть выполнена с помощью INSERT/SELECT

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

Обработка прерывания

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

Комплексная обработка

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

Критическая производительность

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

Ответ 25

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

Ответ 26

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

Ответ 27

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