Простота кода, дело привычки. Я считаю это простой архитектурой. Потому что в коде приложения будет только вызов процедуры.
Хотя ниже по ветке я _наконец-то_ увидел аргументы, в пользу не разрешать прямое подключение к серверу БД, если речь про веб. Видимо, в таком случае, бэкэнд должен вызывать хранимые процедуры перекладывая параметры один-в-один.
Вы, кажется, не совсем понимаете, что такое база данных. Это далеко не только хранилище, это ещё и хранимые процедуры, функции, триггеры. Которые заменяют backend написанный на PHP, и которым до данных гораздо ближе.
И вместо того, чтобы дёргать из десктопа за ручки API, написанного на PHP, в котором всё равно написаны SQL команды, я буду дёргать за те же ручки, написанные сразу на SQL.
Для добавления книги позовём процедуру добавления, что-то типа
EXECUTE Books_add @AuthorID=823, @BookTitle='Улитка на склоне';
А всё, что происходит помимо собственно добавления книги, например поле «книг всего» у автора, напишу в триггере для таблицы Books
CREATE TRIGGER tr_Books_insert
ON Books
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
UPDATE Authors SET
BooksTotal = COALESCE(BooksTotal,0) + (SELECT COUNT(a.AuthorID) FROM inserted a WHERE a.AuthorID = Authors.AuthorID)
WHERE Authors.AuthorID IN (SELECT a.AuthorID FROM inserted a)
С одной стороны да, с другой стороны, при достаточном опыте, уже хватает ума в такую жёсткую логику класть только то, что не имеет исключений.
p. s. Клуб анонимных любителей залезть в данные напрямую :-)
Я не говорю делать вычисления на клиенте, я говорю делать дополнительную прослойку на серверной стороне которая будет отделять клиентскую часть от базы данных. В ней и писать все вычисления.
Представьте, что такой частью является комплекс хранимых процедур, функций, триггеров. И скажите пожалуйста, что это за прокладка, с которой могут работать клиенты под разные платформы.
Это не совсем хорошая практика исправлять что-либо подключаясь напрямую к базе данных, для избежания каких-либо проблем используют такие вещи как «seed» к примеру, и с помощью этого инструментария и вносят изменения в БД.
Это отвратительная практика. Но мне очень спокойно, что при любом исходе я не буду разгребать отрывочные сведения по всем таблицам. Почему-то первичный ключ использовать можно, а триггер, который поддерживает мою логику нельзя.
Почему сразу веб-приложение? Пусть это будет много клиентских приложений, на нескольких платформах, в том числе и веб.
Откровенно неудобно писать одну и ту же логику на разных языках, с возможностью сделать ошибку в столько раз более вероятно, сколько языков используется.
В моём понимании, бизнес-логика, это нечто, что соблюдается очень жёстко. Следовательно, оно должно быть на уровне базы данных. То есть никто, даже случайно, не должен иметь возможность сделать данные противоречивыми.
Примитивный пример такой логики: при заполнении ВШГ в товарной номенклатуре, напишем триггер, который будет вычислять объём товара, и количество штук этого товара в кубе, а вычисленные поля класть сюда же, в номенклатуру. Вопрос, зачем это тянуть наружу и вычислять там? А если клиенты написаны под несколько платформ, на каждой эти вычисления писать? А если кто-то полез руками напрямую в таблицу исправлять ВШГ?
Меня, как абонента, это интересовать не должно. Я попросил оператора, не отдавать мне данные в роуминге. И дальше, как мне кажется, возможны два пути:
1. Оператор не отдаёт данные, потому что я в роуминге
2. Оператор отдаёт данные, потому что я в домашней сети
Если мне одной рукой отдают данные, а другой считают, что я за пределами дома, это какое-то лукавство.
Ехал я как-то из Москвы в Питер на Сапсане. С МегаФоном в качестве оператора. Умный такой, выключил роуминг данных, и, пока едем по московской области, на карту смотрю. Закончилось московская область, а интернет работает, вот и тверская закончилась, а он всё работает. Приехали в Питер, а карты по-прежнему пробки рисуют и вообще всё хорошо со скоростью.
А на следующий день у меня 800р. списали за роуминг данных. Да, за выключенный роуминг данных. То есть вышка абонентскому устройству говорит «ты в домашней сети», а сама всё правильно считает, как надо. И в колл-центре говорят – так и должно быть.
Я оценивал так: общее благосостояние человечества оценивается в 70 трлн. долларов. Предположим, что биткойн будет единственной валютой на планете (что конечно не так), тогда стоимость одной монеты должна быть около 3.3 млн. долларов.
Дальше можно делать различные предположения. Например:
10% накоплений человечества будет храниться в биткоине получаем оценку в 300 тыс. долларов за монету
1% – 30 тыс. долларов за монету.
Продолжая вашу категоричную мысль:… а писать одинаковую логику на нескольких языках – добро.
Положим n – количество портов вашего приложения. Тогда в случае изменения логики, менять придётся не одну хранимую процедуру/триггер/constraint, а n исходных текстов. Имея процент ошибок, при написании текста программ, например, 0.5% от написанного, вы этот процент, опять же, увеличиваете в n раз.
не парьтесь, и покупайте проектор. у меня белый потолок, прозрачные шторы с засветкой с улицы и да, потеря контраста (Epson EH-TW3200), но 160" дюймов изображения вот уже пять лет не вызывают никакого желания смотреть кино на телевизоре. стена, кстати, тоже, обычная белая краска.
Там же «курс молодого бойца», а не опытного ;-)
Кстати, я стараюсь не допускать идентичности NULL и 0 (NULL и ''). Так удобнее, чтобы пусто было пусто, а 0 может что-то значить. В WHERE, соответственно пишу FieldValue IS NULL. А при заполнении полей сначала привожу переменные _variable:=NULLIF(_variable,'') или в триггере причёсываю значения полей.
По аналогии с SQL, если вы откроете доступ к БД, то злоумышленник может сделать SQL запрос с кучей join которые тупо повесят ваш сервер БД (вам же это не хочется, правда ?).
именно поэтому удобно использовать хранимые процедуры, к которым доступ открыт, а к таблицам и прямыми запросами к ним закрыт. в процедуре об этом злоумышленнике подумали заранее.
Выглядит примерно так:
Хотя ниже по ветке я _наконец-то_ увидел аргументы, в пользу не разрешать прямое подключение к серверу БД, если речь про веб. Видимо, в таком случае, бэкэнд должен вызывать хранимые процедуры перекладывая параметры один-в-один.
И вместо того, чтобы дёргать из десктопа за ручки API, написанного на PHP, в котором всё равно написаны SQL команды, я буду дёргать за те же ручки, написанные сразу на SQL.
Для добавления книги позовём процедуру добавления, что-то типа
А всё, что происходит помимо собственно добавления книги, например поле «книг всего» у автора, напишу в триггере для таблицы Books
p. s. Клуб анонимных любителей залезть в данные напрямую :-)
Представьте, что такой частью является комплекс хранимых процедур, функций, триггеров. И скажите пожалуйста, что это за прокладка, с которой могут работать клиенты под разные платформы.
Это отвратительная практика. Но мне очень спокойно, что при любом исходе я не буду разгребать отрывочные сведения по всем таблицам. Почему-то первичный ключ использовать можно, а триггер, который поддерживает мою логику нельзя.
Откровенно неудобно писать одну и ту же логику на разных языках, с возможностью сделать ошибку в столько раз более вероятно, сколько языков используется.
Примитивный пример такой логики: при заполнении ВШГ в товарной номенклатуре, напишем триггер, который будет вычислять объём товара, и количество штук этого товара в кубе, а вычисленные поля класть сюда же, в номенклатуру. Вопрос, зачем это тянуть наружу и вычислять там? А если клиенты написаны под несколько платформ, на каждой эти вычисления писать? А если кто-то полез руками напрямую в таблицу исправлять ВШГ?
1. Оператор не отдаёт данные, потому что я в роуминге
2. Оператор отдаёт данные, потому что я в домашней сети
Если мне одной рукой отдают данные, а другой считают, что я за пределами дома, это какое-то лукавство.
А на следующий день у меня 800р. списали за роуминг данных. Да, за выключенный роуминг данных. То есть вышка абонентскому устройству говорит «ты в домашней сети», а сама всё правильно считает, как надо. И в колл-центре говорят – так и должно быть.
Если криптобиржи не регулируются, почему в отношении mt. gox ведётся расследование?
оффтоп. надеюсь люди на промо картинках снимают фотографии, а не вертикальное видео.
посмотрите вживую, как снимает айфон 6 плюс, там уже была аппаратная стабилизация. в более поздних и подавно.
Я оценивал так: общее благосостояние человечества оценивается в 70 трлн. долларов. Предположим, что биткойн будет единственной валютой на планете (что конечно не так), тогда стоимость одной монеты должна быть около 3.3 млн. долларов.
Дальше можно делать различные предположения. Например:
10% накоплений человечества будет храниться в биткоине получаем оценку в 300 тыс. долларов за монету
1% – 30 тыс. долларов за монету.
Положим n – количество портов вашего приложения. Тогда в случае изменения логики, менять придётся не одну хранимую процедуру/триггер/constraint, а n исходных текстов. Имея процент ошибок, при написании текста программ, например, 0.5% от написанного, вы этот процент, опять же, увеличиваете в n раз.
не парьтесь, и покупайте проектор. у меня белый потолок, прозрачные шторы с засветкой с улицы и да, потеря контраста (Epson EH-TW3200), но 160" дюймов изображения вот уже пять лет не вызывают никакого желания смотреть кино на телевизоре. стена, кстати, тоже, обычная белая краска.
Кстати, я стараюсь не допускать идентичности NULL и 0 (NULL и ''). Так удобнее, чтобы пусто было пусто, а 0 может что-то значить. В WHERE, соответственно пишу FieldValue IS NULL. А при заполнении полей сначала привожу переменные _variable:=NULLIF(_variable,'') или в триггере причёсываю значения полей.
на
именно поэтому удобно использовать хранимые процедуры, к которым доступ открыт, а к таблицам и прямыми запросами к ним закрыт. в процедуре об этом злоумышленнике подумали заранее.
вот сайт производителя кольца, а вот тут обсуждение на 4pda