Здравствуйте, scf, Вы писали:
scf>По-хорошему где-то должен быть слой изоляции структуры БД от остальной системы.
Да, это с очевидностью следует из DIP (принципа инверсии зависимости, говорящий, что нетривиальные зависимости должны ссылаться только на абстрактные интерфейсы): высокоуровневый компонент (реализующий бизнес-логику) не должен зависеть от низкоуровневого (хранилища данных), зависимость должна быть обратной (например, от этого самого изолирующего слоя).
А если попытаться заглянуть в будущее, то дисков не будет, их заменит RAM. "The Database Is a Detail" (Роберт Мартин). Приложению нужны не диски, а RAM. Приложению нужны не таблицы и не KV-хранилища, а данные, организованные в нормальные программные структуры — массивы, очереди, стеки, деревья и т.п. Существование баз данных — временный преходящий этап, который закончится с нынешней эпохой дефицита RAM и вымиранием дисков (как до того вымерли ленты). Закладывать бизнес-логику внутрь базы данных недальновидно ещё и по этой причине.
Здравствуйте, amironov79, Вы писали:
A>Какая пропасть? Логика в базе это именно "ужас-ужас", которым стоит заниматься только в случае крайней необходимости. Базе -- данные, приложению -- логику!!!))
Ну, вы же почему-то доверяете базе обрабатывать логику джойнов? Или вы поклонник NoSQL?
Почему же вы не хотите доверить базе что-то чуть более сложное?
A>Конечно, нужен баланс. Но в любом случае на сервере приложений больше простора для написания логики, начиная от выразительности языка, заканчивая набором библиотек.
Ещё раз подчеркну: абстрактных соображений вроде "больше простора" при принятии архитектурных решений лучше избегать.
Единственный правильный способ — это для каждого конкретного случая сравнивать конкретные характеристики.
Потому что вот предлагаемый вами подход как раз и приводит к неожиданным решениям типа "да я щас подниму результат в джаву и пробегусь по нему регекспом для отбора", которые потом тормозят в продакшне.
А ведь технически ничто не мешает скомпилировать регекс в байткод, и запихать его внутрь СУБД. Где он будет исполняться со скоростью мысли, и сэкономит 90% трафика между СУБД и сервером приложений.
Заодно это позитивно скажется на времени удержания локов (или на шансах нарваться на конфликт при оптимистике).
При этом всю рутинную работу по проверке соответствия версии регекса, которая нужна клиенту, и версии регекса, лежащей в базе, можно возложить на тупую неутомимую машину, а не на рассеянные кожаные мешки.
Но данное решение даже в голову не приходит тем, кто думает мантрами типа "логика в базе — это ужас-ужас".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.
По-хорошему где-то должен быть слой изоляции структуры БД от остальной системы. Единая точка входа для чтения и записи в таблицу, полезно при рефакторинге и оптимизации структуры БД, аудита, разграничения прав и т.п. Лично я предпочитаю микросервис, но слой хранимых процедур тоже приемлемый вариант. Главное, стараться не добавлять туда бизнес-логику.
Здравствуйте, Sinclair, Вы писали:
C>>Ну так и пользовательский код потом может просто по списку совпадающих ID загрузить таблицу. Если смотреть новомодный GraphQL — там это вообще удобно делается. S>Я вам уже на это заранее ответил: Попытка сделать аналогичный финт в апп.сервере обладает всеми недостатками client side join. S>То есть мы говорим о том, что вместо отбора 10% полных записей внутри СУБД, вы предлагаете втащить 100% пар ID-UserAddress в аппсервер, затем сделать фильтрацию, и запихать 10% ID в СУБД, чтобы извлечь из неё 10% полных записей.
Нет. Сначала применяем условия, которые не зависят от регэкспа, потом достаём выбираем пары ID-UserAddress, затем на стороне клиента фильтруем.
Всё ровно как в случае с ХП.
S>Вам уже видно, почему это будет медленнее, чем предлагаемая альтернатива?
Не видно.
C>>А вот это вообще лучше не использовать, из соображений сохранения вменяемости. S>Да что вы! А что это за соображения — можно озвучить?
Использование видов и всяческих вычисляемых колонок — сушит моск и калечит архитектуру.
C>>В принципе, я ещё могу понять использование каких-то очень абстрактных функций в БД, типа regexp match. Это скорее восполнение недостатка самой БД (девелоперы не додумались добавить), но я люто против чего-либо, что связано с бизнес-логикой. Т.е. "ZipMatches" — это уже крайне плохо. S>Аргументы?
Перекладывание на БД логики. По идее, её там вообще не должно быть.
Даже SQL, по сути, является ошибкой индустрии из-за того, что позволяет часть логики переносить в запросы. Крайне кривой язык, который не приспособлен нормально ни для оффлайновой аналитики, ни для онлайн-запросов.
Здравствуйте, amironov79, Вы писали: A>А какая функция сложная? Генерация изображений, документов, анализ данных за продолжительный период?
Два основных класса логики, которые не стоит тащить внутрь СУБД: CPU-bound вычисления и Network-bound обмен с внешним миром.
То есть, скажем, отправлять email изнутри СУБД — плохая идея. Или, скажем, делать фильтрацию изображений. A>И какой будет этот round-trip, если сервера рядом стоят? Где-то есть бенчмарки?
Минимальное время, которое нужно, чтобы сделать select 1 из MS SQL — 10ms. Сколько бар-кодов можно сгенерировать за 10мс? A>Гуглам с майкрософтами можно, а другим нельзя?
Именно так.
A>Эээ, какое отношение sql имеет к хранимкам базы? Тем более sql, сгенерированный linq2db.
Ок, продолжаем ликбез. Хранимки бывают двух типов в зависимости от использованного языка: это либо процедурный диалект SQL, либо какой-то язык общего назначения.
Я сейчас говорю о первых.
Linq2db — это пример того, как можно использовать язык высокого уровня для порождения SQL. Это помогает обходить синтаксические ограничения SQL по структурированию кода.
К примеру, на SQL крайне тяжело выразить функцию, которая "к любому датасету с int id добавь join с табличкой accessRights", а на linq2db это делается на раз-два:
public static IQueryable<T> CheckAccess<T>(this IQueryable<T> data, int userId) where T:IIdentifyable<int> => from d in data join ar in accessRights on d.ID equals ar.ObjectID select d where ar.UserID == userId;
Очевидно, что данный подход можно распространить за пределы DML, и получить способ для порождения более сложного SQL кода из кода на Java или C#.
A>Хранимки на языках общего назначения, уже, как бы сказать, не совсем хранимки. В каком контексте будет выполнятся код на "неродном" языке? Насколько я понимаю, для базы эта процедура будет выглядеть как внешний клиент, и на переключении контекста можно много потерять (хотя возможно какие-то оптимизации этого дела и есть).
Нет, для базы эта процедура НЕ будет выглядеть как внешний клиент. И переключение контекста бесконечно дешевле обмена данными с апп.сервером на другой машине.
A>При этом набор языков все-равно ограничен, идет привязка к версии рантайма, который идет с данной версией субд, чтобы настроить разрешения, часто надо идти на поклон к админам. В общем, так себе возможность, но на безрыбье сойдет.
Ну, если так рассуждать, то надо сразу вешаться: в эксплуатации для любого чиха надо идти на поклон к админам. А выбирать версию рантайма не даёт ведущий архитектор — ссылается на какие-то непонятные данные опроса клиентов. A>А что мандельброт и блокчейн это уже не бизнес логика?
Ну, мне, конечно, сложно себе представить бизнес на основе мандельброта; но я вначале поста дал пояснения по поводу того, как выбирать, какую логику имеет смысл тащить в СУБД, а какую — нет. A>Техника расширить канал между сервером приложений и сервером субд тоже есть.
Ох-хо-хо. Хотел бы я иметь возможность по щелчку пальцев получать между апп.сервером и СУБД такие каналы, как между SSD и памятью на локальной машине. A>Я все-равно не понял какую проблему вы решали.
Вижу. Всё же сделайте усилие — перечитайте. Если что-то непонятно — спрашивайте.
A>Компиляция реегулярок тоже не имеет отношения к процедурам в базе. На клиенте базы будет все тоже самое.
Я не понимаю, что вы называете "всё то же самое". С точки зрения кода, который пишется прикладным программистом — да, будет всё то же самое. where zipCodeRegex.IsMatch(userAddress).
Вот только исполняться будет всё совсем по другому: вместо подъёма миллиона строк в память апп.сервера и последующего выполнения client-side filter, всё отработает на стороне СУБД. Уменьшаем сетевой трафик на 90%, примерно вдвое сокращаем время удержания транзакции.
Примерно то же самое, только ещё более заметно, работает для классических хранимок вроде "провести резервирование товара по заказу", которые бегают по складам и ищут оптимальный способ раскидать строчки заказа по партиям товара.
Потому что вытаскивание этого в апп.сервер требует N+1 запросов; это очень долго с точки зрения СУБД. Транзакция, которая могла бы закончиться через 400 миллисекунд, занимает десяток секунд.
Всё это время удерживаются блокировки, мешая параллельным транзакциям завершиться — имеем эффект домино. Люди привыкают считать времена отклика в минуту "нормальными".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, amironov79, Вы писали:
A>Ключевое слово "бывает". Получается, что логика на базе это оптимизация, которой как известно не стоит заниматься преждевременно.
Между "не стоит заниматься преждевременно" и "это же ужас-ужас" лежит целая пропасть.
Есть много нюансов при взаимодействии СУБД и сервера приложений, от которых зависит правильный баланс.
На одном конце спектра мы имеем client-side joins и projections с предикатами отбора, на другом — адский код внутри СУБД.
Есть соображения производительности решения, при которых минимизация объема данных, перекачиваемых между слоями, играет принципиальную роль, и есть соображения производительности разработчиков и службы эксплуатации.
Для которых принципиальную роль играет синхронизация версий между логикой в приложении и в СУБД.
И есть много разных способов эти нюансы учитывать — от написания сложной логики на T-SQL/PL-SQL и до импорта Java/.Net кода в СУБД, или кросс-компиляции управляемого кода в SQL. Где-то в промежутке сидит linq, который позволяет писать логику на шарпе, а исполнять в СУБД.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Kswapd, Вы писали:
K>"The Database Is a Detail" (Роберт Мартин).
Это настолько детская ошибка, что мне удивительно как то, что Мартин от нее до сих пор громко не отказался, как и то, что ее регулярно транслируют.
Я тут еще накидаю:
Presentation Layer Is a Detail.
Network Protocol Is a Detail.
Programming Language Is a Detail.
По факту же, попытка полностью абстрагироваться от деталей реализации хранилища заметно дороже, чем переписывание системы на другое хранилище при необходимости. Абстрагироваться стоит только там, где это не вредит качеству кода и не рушит производительность.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Что же в этом хорошего?
Ничего хорошего. Ты только не волнуйся.
ЭФ>База данных — самое немасштабируемое место в системе.
Не используй базы данных.
Здравствуйте, Sinclair, Вы писали:
C>>Нет. Сначала применяем условия, которые не зависят от регэкспа, потом достаём выбираем пары ID-UserAddress, затем на стороне клиента фильтруем. S>Ну, вот в предположении о том, что регекс отбирает только 10% записей, вы на ровном месте удесятеряете трафик между СУБД и апп-сервером. Зачем?
Чтобы не было "регэкспа" в БД.
C>>Всё ровно как в случае с ХП. S>Нет. В случае с нормальной реализацией, в апп сервер сразу уезжает в 10 раз меньше данных, чем предлагаете вы.
Да. В обоих случаях "регэксп" будет обрабатывать ровно одинаковый объём.
C>>Использование видов и всяческих вычисляемых колонок — сушит моск и калечит архитектуру. S>Точно — в трёхзвенку рано.
Нет, это как раз результат работы с недо-трехзвенкой, в которой логика размазана тонким слоем.
C>>Перекладывание на БД логики. По идее, её там вообще не должно быть. S>Это странная идея. Ну, то есть идеи-то могут быть любыми, но разработка — она же для людей и преследуемых людьми практических целей, а не для идей. Поэтому "идеи" обсуждать смысла нет.
Это не странная идея совершенно. Более того, по факту это сейчас то, что происходит в индустрии — она уходит от SQL и логики в БД в сторону использования БД как тупого хранилища, с которым легко работать из языков более высокого уровня.
C>>Даже SQL, по сути, является ошибкой индустрии из-за того, что позволяет часть логики переносить в запросы. Крайне кривой язык, который не приспособлен нормально ни для оффлайновой аналитики, ни для онлайн-запросов. S>Нет, всё-таки шутите. А я уж испугался )
Не шучу. SQL — это уродство хуже PHP.
Здравствуйте, Cyberax, Вы писали: C>Нет. Сначала применяем условия, которые не зависят от регэкспа, потом достаём выбираем пары ID-UserAddress, затем на стороне клиента фильтруем.
Ну, вот в предположении о том, что регекс отбирает только 10% записей, вы на ровном месте удесятеряете трафик между СУБД и апп-сервером. Зачем? C>Всё ровно как в случае с ХП.
Нет. В случае с нормальной реализацией, в апп сервер сразу уезжает в 10 раз меньше данных, чем предлагаете вы. S>>Вам уже видно, почему это будет медленнее, чем предлагаемая альтернатива? C>Не видно.
Либо вы шутите, либо вам пока рано в трёхзвенку.
S>>Да что вы! А что это за соображения — можно озвучить? C>Использование видов и всяческих вычисляемых колонок — сушит моск и калечит архитектуру.
Точно — в трёхзвенку рано.
C>Перекладывание на БД логики. По идее, её там вообще не должно быть.
Это странная идея. Ну, то есть идеи-то могут быть любыми, но разработка — она же для людей и преследуемых людьми практических целей, а не для идей. Поэтому "идеи" обсуждать смысла нет.
C>Даже SQL, по сути, является ошибкой индустрии из-за того, что позволяет часть логики переносить в запросы. Крайне кривой язык, который не приспособлен нормально ни для оффлайновой аналитики, ни для онлайн-запросов.
Нет, всё-таки шутите. А я уж испугался )
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sharov, Вы писали: S>Таких мест всего два и, вероятно, развитием и поддержкой будут заниматься разные люди. Или нет. В любом случае криминала немного.
По факту — три.
Ограничения вроде (check constraint), NOT NULL, Foreign Key живут в БД, в апп.сервере, и на клиенте (JS).
В идеале всё это должно описываться в одном месте, а исполняться — там, где оптимально. Например, везде.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, amironov79, Вы писали:
A>Да, я имею в виду именно использование. Какой смысл программисту, решающему бизнес-задачу, лезть в исходники linq2db? Только если что-то пойдет не так. Также программисты на plsql/tsql в потроха субд не лезут.
Ну, меня, если честно, мало волнуют "программисты на pl/sql". Я регулярно слышу рассказы о том, как узкий специалист в одной версии одного языка утопчет насмерть полноценного разработчика приложений, но всё жду, когда же это случится на моих глазах.
Меня интересуют разработчики приложений — то есть способа удовлетворить требования заказчика (а не соответствовать какому-то узкому профилю в резюме, типа "программирую всё что угодно, если оно на ангуляре").
И инструменты тоже интересуют с той же точки зрения — насколько они пригодны для решения реальных задач, и насколько легко их подпилить при решении задач, выходящих за рамки коробочной реализации.
С этой точки зрения микрософтовский EF — отстой: он написан не в ту сторону, решает не те задачи; те, которые решает — решает плохо; которые не решает — решить не помогает.
linq2db написан гораздо более компетентно. A>Кстати, а linq2db или dapper можно подключить к базе?
Что значит "подключить к базе"?
A>Каким образом? Вы заставляете пользователя покупать sql server, а у него уже может быть есть корпоративный сервер с oracle, или он не прочь на postgres посидеть, или ему для дома вообще sqlite достаточно.
Для случаев "дома sqlite" разговор о логике в базе вообще лишён смысла.
А для реальных случаев с существенной нагрузкой покупка SQL сервера — только часть решения. Если решение X потребует лицензирования четырёх железок с Oracle, а решение Y — лицензирования одной железки с MS SQL, то заказчик запросто слюнями наплюёт на то, что у него "уже есть корпоративный сервер с oracle".
И наоборот.
И вообще, я наблюдал случаи, когда клиент говорит "ок, да ставьте уже что вам удобно" и переезжает с винды/mssql на линукс/постгрес потому, что его не устраивает ждать апдейтов вдвое дольше, чем всем остальным.
Ожидание получается не из каких-то особенных свойств MS SQL, а из того, что 90% partner base сидит на линуксах, и, естественно, для них апдейты выпускаются в первую очередь.
А начиналось-то всё как раз из ваших соображений: не заставлять же партнёра предоставлять окружение по нашему выбору; давайте мы лучше прогнёмся под него.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
A>>Доверяю, потому что в моем понимании джойны, выбороки и проекции это не совсем уровень бизнес-логики, это уровень доступа к данным. S>Ну, и где же граница?
Как всегда определяется исходя из конкретных обстоятельств. Запросом к базе максимально фильтруем данные, в приложении раскладываем их по полочкам (коллекциям) и спокойно с ними работаем. Надо сгенерировать штрих-код, подключаем библиотеку, генерируем, сохраняем обратно в базу. Надо передать данные по проприетарному протоколу, берем у производителя библиотеку, подключаем, передаем. Как это сделать на бд я тоже представляю, но будет это выглядеть как набор костылей.
A>>Но мы же не про sql говорим, а про процедурные расширения. В чем преимущества plsql/tsql перед java/c# как инструмента для обсчета и преобразования, когда данные уже выбраны из таблиц? S>В локальности.
Единственный плюс. Но если рассматривать архитектуру всей системы в целом, его даже не стоит принимать во внимание.
A>>Какие же они абстрактные? Как языки plsql и tsql (на фоне java и c#), мягко говоря, полная ерунда. Библиотек нормальных нет, коллекций нормальных нет, сахара минимум. Вообще странно, что их называют языками для обработки данных. S>Ну и что?
Как что? Элементарных вещей в этих языках нет, бери любую возможность из современного языка, и не найдешь ее. Про коллекции я уже говорил, еще нет пространств имен (привет, библиотеки), нет подобия linq to objects (хотя казалось бы, данные же обрабатывем), нет кортежей (и это языки расширения в рсубд), нет вывода типов, нет рефлексии, а следовательно нет и мапперов. Да ничего там нет, кроме временных таблиц, и в результате все проблемы выглядят как гвозди.
A>>И зачем себя ограничивать в архитектурных решениях? Если возникнет задача, которую не решить процедурными языками базы из-за отсутствия нужных библиотек, то что делать? Сказать, что не можем? Писать внешний сервис? S>Как раз я предлагаю не ограничивать. Это вы хотите ограничиться логикой в app server. A>>А если расчеты начнут нагружать процессор на сервере базы, как будете масштабировать решение? S>В зависимости от конкретной задачи. Тут универсальными мантрами не отделаешься.
Вы уж определитесь: "стоит избегать" или "не ограничиваете". Вот есть у вас какой-либо расчет на plsql/tsql. Условно, при закрытии месяца база у вас ложится, потому что этот расчет очень любит процессор. Как будете выходить из положения?
S>>>Заодно это позитивно скажется на времени удержания локов (или на шансах нарваться на конфликт при оптимистике). A>>Каким образом? За счет скорости выполнения? А она точно будет существенно больше? Например, относительно использования dapper или linq2db. S>За счёт того, что канал между памятью и диском в сервере БД существенно шире, чем канал между апп.сервером и сервером БД. S>При хорошей селективности предиката в апп.сервер поедет в сотню раз меньше данных, и СУБД сможет завершить транзакцию раньше.
Ну, как бы, не факт. Канал между сервером приложений и сервером субд может быть и быстрее канала между сервером субд и хранилищем данных. Все зависит от конкретных решений.
S>>>При этом всю рутинную работу по проверке соответствия версии регекса, которая нужна клиенту, и версии регекса, лежащей в базе, можно возложить на тупую неутомимую машину, а не на рассеянные кожаные мешки. A>>Здесь вообще не понял про что речь. Статическая компиляция регулярки? S>Конечно. Вы же знали, что регулярку можно скомпилировать, а не интерпретировать?
Так еще со времен перла. А при чем здесь версия регулярки на базе и на клиенте? Что такое вообще версия регулярного выражения?
A>>Бизнес-логика заканчивается на регулярных выражениях? Хорошо живете. S>Я намеренно привожу простой пример. Нет смысла обсуждать сложные вещи в бизнес-логике, пока вы не поймёте технические основы.
А вы приведите сложный. Вы же библиотеку регулярных выражений не на plsql/tsql писали, эта возможность вам любезно предоставлена самим движком субд. Кстати, если бы не было регулярок в движке, как бы выходили из положения?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.
Там хорошего ровно одно. Эти процедуры размещены близко к данным, выполняются на той же машине, что и данные. За счет чего для какой то логики не нужно гонять данные по сети. И потенциально для некоторых случаев это позволяет добиться гораздо большей скорости.
A>То есть писать код в базе изначально -- это неправильно? Так про это и топик.
Все зависит от того какой BL? У меня было несколько ETL приложений для обработки большого объема данных. Веб-морда отправляла в REST API инфу о фильтрах, REST API обращался в бд,
а бд уже сама вычисляла все агрегаты, правила обработки данных, разграничение прав.
А к чему это я все? А... Вот к чему: нет понятия — правильно/неправильно, есть понятие — уместно данное решение/неуместно.
Вот какой инструмент правильный: молоток или отвертка? Ни один из этих инструментов не является правильным.
Здравствуйте, Sinclair, Вы писали:
S>Эмм, я сам, конечно, к ДевоПсам не отношусь, но обычная практика очень простая: вместе с системой идёт инструкция по развёртыванию. И если в ней сказано "надо дать Global Admin права аккаунту х", то админ идёт и выдаёт. S>Ну, кроме редких случаев, когда админ приходит к авторам системы с жалобой на то, что deployment guide противоречит их локальным правилам безопасности. Тогда вырабатывается консенсус — правятся либо правила, либо гайд. Либо код приложения подпиливается так, чтобы не требовать невозможного. Но это — прямо самое-самое редкое.
Я это все понимаю. Я к тому, что зачем выбирать технологию, у которой будет, скажем так, неодназначный deployment, если есть более простые решения?
S>Поэтому, как бы смешно это ни звучало, но будет именно так: если CIO предложил всем сотрудникам поставить "фонарик", а CEO это решение утвердил, то всё — требует читать СМС, значит выдадим пермиссию.
Так это и есть использование административного ресурса при внедрении. Обычный специалист на себя такую ответственность брать не будет.
Здравствуйте, amironov79, Вы писали:
A>Здравствуйте, okon, Вы писали:
O>>Бывает что перекачка данных из СУБД в сервис и обратно становится узким горлышком для производительности, особенно если они живут на разных машинах. O>>Гораздо быстрее получается выполнить всю логику в самой БД.
A>Ключевое слово "бывает". Получается, что логика на базе это оптимизация, которой как известно не стоит заниматься преждевременно. Когда у тебя есть отдельный сервер приложений, никто тебе не мешает здесь и сейчас написать процедуру в бд и использовать ее.
Получается что в итоге часть логики в сервере приложений, а часть в базе и нужно поддерживать оба варианта.
Хорошо когда логика находится в одном месте, а не размазана по разным системам.
Зависит от ситуации, иногда выгоднее всю логику держать в базе, т.к. требуется меньше специалистов чтобы поддерживать все это.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
K>Но, кажется, вы не совсем поняли мою мысль (точнее, пересказанную мысль Роберта Мартина из его книги "Clean Architecture"). Дело в том, что само существование RDBMS вытекает из несовершенства устройства компьютеров. Внутреннее устройство RDBMS "заточено" под конкретный тип конструкций с магнитными головками и вращающимися дисками. Быстродействующая оперативная память ограничена небольшими объёмами, к тому же энергозависима, теряет данные после выключения. Поэтому нужно где-то сохранять данные, а после включения загружать их (часть их) снова в RAM для продолжения работы. Но так будет не всегда. Представим себе компьютер с быстрой энергонезависимой памятью гигантского, практически неограниченного объёма. Зачем тогда программам будет что-то куда-то сохранять?
Мартин в коме последние годы? in-memory storage в оракле уже лет пять реализован. причем "хранение" в памяти переделано на колончатое.
K>Да, это с очевидностью следует из DIP (принципа инверсии зависимости, говорящий, что нетривиальные зависимости должны ссылаться только на абстрактные интерфейсы): высокоуровневый компонент (реализующий бизнес-логику) не должен зависеть от низкоуровневого (хранилища данных), зависимость должна быть обратной (например, от этого самого изолирующего слоя).
K>А если попытаться заглянуть в будущее, то дисков не будет, их заменит RAM. "The Database Is a Detail" (Роберт Мартин). Приложению нужны не диски, а RAM. Приложению нужны не таблицы и не KV-хранилища, а данные, организованные в нормальные программные структуры — массивы, очереди, стеки, деревья и т.п. Существование баз данных — временный преходящий этап, который закончится с нынешней эпохой дефицита RAM и вымиранием дисков (как до того вымерли ленты). Закладывать бизнес-логику внутрь базы данных недальновидно ещё и по этой причине.
ерунда. как рсубд уже 2-3 раза в своей истории доказали что никому не нужно хранить вермишель из кривых структур языка, т.к. вермишель лишь в студенческих задачках гладко работает, а в реальных условиях не масштабируется и требует диких трудозатрат и костылей. в 80х и 90х наступали объектные субд, позволявшие хранить вермишель объекты в субд, потом были их подварианты с xml базами. когда объектные субд не взлетели начали натягивать ормы на реляционную модель. и это оказалось не работает, и ормы вышли из моды.
вот и сейчас похоже история делает еще один круг. на острие прогресса — бигдате популярен spark framework. все основные концепции рсубд туда перекочевали — логика выполняется там где хранятся данные, вместо табличек датафреймы, практически всегда плоские таблички. синтаксис работы с датафрейм по сути sql, с select, sum, join, так же как в рсубд датафрейм скорее декларативная конструкция, которую на ходу оптимизатор превращает в реальный план доступа к данным.
Здравствуйте, Kswapd, Вы писали:
K>В этом будущем гипотетическом компьютере программа обновляется прямо в RAM, без влияния на данные. Если нужно преобразовать данные, они копируются "рядом" (памяти хватит на всё!), а старая версия, если не нужна — удаляется. И всё без участия дисков.
Ну вот когда этот гипотетический компьютер перестанет быть гипотетическим, тогда и поговорим...
А пока будем говорить о реалиях.
Здравствуйте, Kswapd, Вы писали: K>Но, кажется, вы не совсем поняли мою мысль (точнее, пересказанную мысль Роберта Мартина из его книги "Clean Architecture"). Дело в том, что само существование RDBMS вытекает из несовершенства устройства компьютеров. Внутреннее устройство RDBMS "заточено" под конкретный тип конструкций с магнитными головками и вращающимися дисками. Быстродействующая оперативная память ограничена небольшими объёмами, к тому же энергозависима, теряет данные после выключения. Поэтому нужно где-то сохранять данные, а после включения загружать их (часть их) снова в RAM для продолжения работы. Но так будет не всегда. Представим себе компьютер с быстрой энергонезависимой памятью гигантского, практически неограниченного объёма. Зачем тогда программам будет что-то куда-то сохранять?
Тогда программам потребуется Software Transactional Memory. Потому что даже если пренебречь тем, что программа вынуждена время от времени выключаться — штатно или нештатно — нам всё ещё нужно обеспечивать свойства типа атомарности и изоляции транзакций.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Lepsik, Вы писали:
ЭФ>>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.
L>Неофитов всегда колбасит от новых идеалогий.
L>Прекрасно все в реляционных базах масштабируется.
A>Здравствуйте, white_znake, Вы писали:
_>>Партицирование, шардирование вполне себе повышают масштабируемость бд. Другое дело, что масштабировать бд — это сложная задача.
A>Это все про хранение данных, чем СУБД и должна заниматься. Вопрос же про код, то есть про сервер приложений, зачем его совать в СУБД?
в субд есть киллер фичи, которые бывает перевешивают все. например интеграция данных и кода, если DDL изменило типы колонок — база может пометить весь завязанный на эти типы код как инвалид и избавить от множества приключений. сервер приложений же получит эксепшен в рантайме, когда много чего уже и откатить то не выйдет.
плюс скорость, серьезная логика зачастую требует прокачивать в сервер приложений лишние петабайты.
Здравствуйте, Gt_, Вы писали:
C>>ORM и статические языки смотрят в недоумении. Gt_>ормы валидируют структуру лишь при старте, если приложение стартануло — все. глупый орм оторванный от данных ничерта не знает о происходящем после старта в субд.
Если у вас приложения обновляются без всякого процесса прямо методом "херак, херак — и в продакшн", то это никакая РСУБД не спасёт.
Здравствуйте, Sinclair, Вы писали:
S>Ну, вы же почему-то доверяете базе обрабатывать логику джойнов? Или вы поклонник NoSQL? S>Почему же вы не хотите доверить базе что-то чуть более сложное?
Доверяю, потому что в моем понимании джойны, выбороки и проекции это не совсем уровень бизнес-логики, это уровень доступа к данным. Но мы же не про sql говорим, а про процедурные расширения. В чем преимущества plsql/tsql перед java/c# как инструмента для обсчета и преобразования, когда данные уже выбраны из таблиц?
S>Ещё раз подчеркну: абстрактных соображений вроде "больше простора" при принятии архитектурных решений лучше избегать. S>Единственный правильный способ — это для каждого конкретного случая сравнивать конкретные характеристики.
Какие же они абстрактные? Как языки plsql и tsql (на фоне java и c#), мягко говоря, полная ерунда. Библиотек нормальных нет, коллекций нормальных нет, сахара минимум. Вообще странно, что их называют языками для обработки данных.
И зачем себя ограничивать в архитектурных решениях? Если возникнет задача, которую не решить процедурными языками базы из-за отсутствия нужных библиотек, то что делать? Сказать, что не можем? Писать внешний сервис?
А если расчеты начнут нагружать процессор на сервере базы, как будете масштабировать решение?
S>Потому что вот предлагаемый вами подход как раз и приводит к неожиданным решениям типа "да я щас подниму результат в джаву и пробегусь по нему регекспом для отбора", которые потом тормозят в продакшне.
S>А ведь технически ничто не мешает скомпилировать регекс в байткод, и запихать его внутрь СУБД. Где он будет исполняться со скоростью мысли, и сэкономит 90% трафика между СУБД и сервером приложений. S>Заодно это позитивно скажется на времени удержания локов (или на шансах нарваться на конфликт при оптимистике).
Каким образом? За счет скорости выполнения? А она точно будет существенно больше? Например, относительно использования dapper или linq2db.
S>При этом всю рутинную работу по проверке соответствия версии регекса, которая нужна клиенту, и версии регекса, лежащей в базе, можно возложить на тупую неутомимую машину, а не на рассеянные кожаные мешки.
Здесь вообще не понял про что речь. Статическая компиляция регулярки?
S>Но данное решение даже в голову не приходит тем, кто думает мантрами типа "логика в базе — это ужас-ужас".
Бизнес-логика заканчивается на регулярных выражениях? Хорошо живете.
C>>>А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать. Gt_>>не надо передавать, не надо делать копию объекта в памяти. не надо потом тратить на GC. C>И это реально ускорит приложение? Не верю. В большинстве случаев, скорее всего, окажется выгоднее кэшировать данные на клиенте и запускать поиск там локально вместо того, чтобы лезть в БД.
кеш уже есть в субд. делать копию этого же кеша что бы там что-то запускать быстрее не будет.
C>Типичный пример — строка с автокомплитом, чтобы можно было по "ка ма 12" показывать вариант "ул. Карла Маркса, д. 123" из базы клиентов.
угу. а потом ныть что примитивный сайт кушает 1.5GB и что бы просто побровсить нужна машина минимум с 8Gb рам и SSD.
C>Ну и, вообще-то, регэкспы уже есть в виде встроенных функций чуть менее, чем во всех нормальных РСУБД. Какие ещё варианты для функций есть?
задачи бывают разные, как выше заметили важен баланс, а не тупое следование одной концепции. иначе нам скоро и 8Gb уже не хватит что бы побровсить.
C>>>И это реально ускорит приложение? Не верю. В большинстве случаев, скорее всего, окажется выгоднее кэшировать данные на клиенте и запускать поиск там локально вместо того, чтобы лезть в БД. Gt_>>кеш уже есть в субд. делать копию этого же кеша что бы там что-то запускать быстрее не будет. C>Будет.
Здравствуйте, amironov79, Вы писали:
A>Это опять-таки все про выборку данных. Никто и ничто не мешает мне подергать туже view с сервера приложений. Вопрос же про то, что вы будете делать, когда ваша процедура упрется в процессор?
Чтобы процедура упёрлась в процессор, надо на ней писать то, что требует процессора. И что же, кто-то подобный код на pl/sql пишет?
Здравствуйте, Sinclair, Вы писали:
A>>И какой будет этот round-trip, если сервера рядом стоят? Где-то есть бенчмарки? S>Минимальное время, которое нужно, чтобы сделать select 1 из MS SQL — 10ms. Сколько бар-кодов можно сгенерировать за 10мс?
Чисто для корректировки: У меня получалось от менее 1 мс, до 5 мс. В среднем 3.
Здравствуйте, Sinclair, Вы писали:
A>>Вопрос так не стоит. Вопрос следующий: как не открыть дыру с помощью хранимок? S>В MS SQL хранимка исполняется под правами того пользователя, под которым авторизовано соединение к базе. Т.е. эскалировать привилегии не получится — не дураки писали. S>Не знаю, как оно там в Оракле и DB2, но не думаю, что принципиально хуже.
Как это реализуется? Я не вижу в системе пользователей, которые есть в базе.
Здравствуйте, Gt_, Вы писали:
Gt_>рсубд уже 2-3 раза в своей истории доказали что никому не нужно хранить вермишель из кривых структур языка
Я понял, что вы хотите сказать, и не возражаю. Да, классическая реляционная модель много раз доказала, что ничего лучше для сохранения данных пока не существует.
Но, кажется, вы не совсем поняли мою мысль (точнее, пересказанную мысль Роберта Мартина из его книги "Clean Architecture"). Дело в том, что само существование RDBMS вытекает из несовершенства устройства компьютеров. Внутреннее устройство RDBMS "заточено" под конкретный тип конструкций с магнитными головками и вращающимися дисками. Быстродействующая оперативная память ограничена небольшими объёмами, к тому же энергозависима, теряет данные после выключения. Поэтому нужно где-то сохранять данные, а после включения загружать их (часть их) снова в RAM для продолжения работы. Но так будет не всегда. Представим себе компьютер с быстрой энергонезависимой памятью гигантского, практически неограниченного объёма. Зачем тогда программам будет что-то куда-то сохранять?
K>Но, кажется, вы не совсем поняли мою мысль (точнее, пересказанную мысль Роберта Мартина из его книги "Clean Architecture"). Дело в том, что само существование RDBMS вытекает из несовершенства устройства компьютеров. Внутреннее устройство RDBMS "заточено" под конкретный тип конструкций с магнитными головками и вращающимися дисками. Быстродействующая оперативная память ограничена небольшими объёмами, к тому же энергозависима, теряет данные после выключения. Поэтому нужно где-то сохранять данные, а после включения загружать их (часть их) снова в RAM для продолжения работы. Но так будет не всегда. Представим себе компьютер с быстрой энергонезависимой памятью гигантского, практически неограниченного объёма. Зачем тогда программам будет что-то куда-то сохранять?
Для того, чтобы это можно было извлечь. Данные живут дольше, чем код, поэтому отдельное приложение, предназначенное для хранения данных, никуда не уйдет. Ну и вторая причина — чтобы можно было обновлять программу без потери данных
scf>Для того, чтобы это можно было извлечь. Данные живут дольше, чем код, поэтому отдельное приложение, предназначенное для хранения данных, никуда не уйдет. Ну и вторая причина — чтобы можно было обновлять программу без потери данных.
В этом будущем гипотетическом компьютере программа обновляется прямо в RAM, без влияния на данные. Если нужно преобразовать данные, они копируются "рядом" (памяти хватит на всё!), а старая версия, если не нужна — удаляется. И всё без участия дисков.
Здравствуйте, Kswapd, Вы писали:
K>А если попытаться заглянуть в будущее, то дисков не будет, их заменит RAM. "The Database Is a Detail" (Роберт Мартин). Приложению нужны не диски, а RAM. Приложению нужны не таблицы и не KV-хранилища, а данные, организованные в нормальные программные структуры — массивы, очереди, стеки, деревья и т.п. Существование баз данных — временный преходящий этап, который закончится с нынешней эпохой дефицита RAM и вымиранием дисков (как до того вымерли ленты). Закладывать бизнес-логику внутрь базы данных недальновидно ещё и по этой причине.
Блин, где я это слышал??? Нет, ну говорил же кто-то... или не говорил... или делал??? Черт, вспомнил... Ну, у меня для тебя плохие новости — это DB2, оно уже сдохло.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, Gt_, Вы писали:
Gt_>вот и сейчас похоже история делает еще один круг. на острие прогресса — бигдате популярен spark framework. все основные концепции рсубд туда перекочевали — логика выполняется там где хранятся данные, вместо табличек датафреймы, практически всегда плоские таблички. синтаксис работы с датафрейм по сути sql, с select, sum, join, так же как в рсубд датафрейм скорее декларативная конструкция, которую на ходу оптимизатор превращает в реальный план доступа к данным.
Вот это сейчас всерьез было, сравнивать рсубд со спарком, в котором хорошим тоном является денормализация данных?
Gt_>>вот и сейчас похоже история делает еще один круг. на острие прогресса — бигдате популярен spark framework. все основные концепции рсубд туда перекочевали — логика выполняется там где хранятся данные, вместо табличек датафреймы, практически всегда плоские таблички. синтаксис работы с датафрейм по сути sql, с select, sum, join, так же как в рсубд датафрейм скорее декларативная конструкция, которую на ходу оптимизатор превращает в реальный план доступа к данным.
SO_>Вот это сейчас всерьез было, сравнивать рсубд со спарком, в котором хорошим тоном является денормализация данных?
я работаю со спарком и не вижу там такого тона. спарк используется восновном в обработке больших данных, соответственно позаимствовал у рсуб и подходы к обработке данных в рсубд хранилище — поменьше джоинов, побольше денормализации.
однако в стриминге и мелких инмемори датасетах спарка за джоин никто не наругает.
ЭФ>>Что же в этом хорошего? База данных — самое немасштабируемое место в системе. E>Там хорошего ровно одно. Эти процедуры размещены близко к данным, выполняются на той же машине, что и данные. За счет чего для какой то логики не нужно гонять данные по сети. И потенциально для некоторых случаев это позволяет добиться гораздо большей скорости.
все таки плюсиков там много больше. например в оракле данные не просто близко, они интегрированы в логику. там есть понятие валидной процедуры/package, если package валидный, значит у него почти нет шансов завалиться в рантайме, код обращается к существующим таблицам, тип колонок именно тот что ожидает код и т.п. в джаве же запросто можно в рантайме получить что угодно, т.к. логика отдельно, данные отдельно.
Здравствуйте, Gt_, Вы писали:
Gt_>все таки плюсиков там много больше. например в оракле данные не просто близко, они интегрированы в логику. там есть понятие валидной процедуры/package, если package валидный, значит у него почти нет шансов завалиться в рантайме, код обращается к существующим таблицам, тип колонок именно тот что ожидает код и т.п. в джаве же запросто можно в рантайме получить что угодно, т.к. логика отдельно, данные отдельно.
Так на статической проверке таблиц плюсы plsql и заканчиваются. Для других языков эту проверку можно получить средствами IDE или через тесты.
Gt_>>все таки плюсиков там много больше. например в оракле данные не просто близко, они интегрированы в логику. там есть понятие валидной процедуры/package, если package валидный, значит у него почти нет шансов завалиться в рантайме, код обращается к существующим таблицам, тип колонок именно тот что ожидает код и т.п. в джаве же запросто можно в рантайме получить что угодно, т.к. логика отдельно, данные отдельно.
A>Так на статической проверке таблиц плюсы plsql и заканчиваются. Для других языков эту проверку можно получить средствами IDE или через тесты.
статическую проверку обеспечивает орм, который не приветствуется в высоконагруженных проектах. да и вообще мода на орм отошла. мне кажется spring boot по дефолту даже драйвер jdbc подгружает лениво, гарантирую сюрприз в рантайме.
подсветка синтаксиса в dev среде это конечно круто, но как там карта ляжет с накатом sql скриптов в проде и что там намерджили в релиз вопрос на миллион. потому в джаве так остро стоит вопрос с CI, тестированием. это целое искусство, тогда как pl/sql прилепленный к данным в этом плане дубовей и надежней.
плюсики там еще есть, но прогресс там остановился лет 10 назад.
Здравствуйте, Gt_, Вы писали:
Gt_>статическую проверку обеспечивает орм, который не приветствуется в высоконагруженных проектах. да и вообще мода на орм отошла. мне кажется spring boot по дефолту даже драйвер jdbc подгружает лениво, гарантирую сюрприз в рантайме. Gt_>подсветка синтаксиса в dev среде это конечно круто, но как там карта ляжет с накатом sql скриптов в проде и что там намерджили в релиз вопрос на миллион. потому в джаве так остро стоит вопрос с CI, тестированием. это целое искусство, тогда как pl/sql прилепленный к данным в этом плане дубовей и надежней. Gt_>плюсики там еще есть, но прогресс там остановился лет 10 назад.
Как язык он по-моему с момента появление не развивается. Что толку с этой надежности, если в языке нет ни нормальных коллекций, ни удобных конструций для работы с данными, ни элементарных библиотек. Да и надежность эта без тестов мнимая, если изменения в проде не накатятся, то конкретно plsql ничем не поможет. По скорости тоже, если брать не орм, а raw sql или библиотеки типа dapper, то в большинстве случаев просадка в производительности в работе с таблицами будет не критична, зато появится возможность данные из этих таблиц обработать, используя вес арсенал .net или java.
A>Как язык он по-моему с момента появление не развивается. Что толку с этой надежности, если в языке нет ни нормальных коллекций, ни удобных конструций для работы с данными, ни элементарных библиотек. Да и надежность эта без тестов мнимая, если изменения в проде не накатятся, то конкретно plsql ничем не поможет. По скорости тоже, если брать не орм, а raw sql или библиотеки типа dapper, то в большинстве случаев просадка в производительности в работе с таблицами будет не критична, зато появится возможность данные из этих таблиц обработать, используя вес арсенал .net или java.
толк в том что оракл наката sql скриптов сразу и на сервере покажет, что и где теперь развалилось в коде. и самое главное то оракл не позволит запустить инвалидный пакадж в принципе. жава же пойдет исполнять и вылетит где-то на пол пути, когда уже так просто много чего не отвернуть. особливо это отвернуть весело на хадупах, где все построено на работе с файликами, которые в принципе не имеют понятия транзакции.
и конструкции в оракле вполне с умом и расчетом на джуниор девелопера, тогда как в жава люди и после 7 лет опыта явно не врубаются что цикл, в цикле, запускает цикл нифига не удобство конструкций, даже если эти циклы подсластили синтаксисом stream api. тесты в докере на 3 строки, тянут данные в "нормальные коллекции" (тм) и "удобно" долбят их в циклах, а потом на кластере это все вываливается по памяти. ведь yarn дает лишь пару гигов на процесс и все эти удобства вылезают боком генерируя убытки.
Здравствуйте, Gt_, Вы писали:
Gt_>и конструкции в оракле вполне с умом и расчетом на джуниор девелопера, тогда как в жава люди и после 7 лет опыта явно не врубаются что цикл, в цикле, запускает цикл нифига не удобство конструкций, даже если эти циклы подсластили синтаксисом stream api. тесты в докере на 3 строки, тянут данные в "нормальные коллекции" (тм) и "удобно" долбят их в циклах, а потом на кластере это все вываливается по памяти. ведь yarn дает лишь пару гигов на процесс и все эти удобства вылезают боком генерируя убытки.
Я мало что понял, но если после 7 лет работы у человека проблема с пониманием циклов, то plsql уже точно не поможет.
Здравствуйте, white_znake, Вы писали:
_>Партицирование, шардирование вполне себе повышают масштабируемость бд. Другое дело, что масштабировать бд — это сложная задача.
Это все про хранение данных, чем СУБД и должна заниматься. Вопрос же про код, то есть про сервер приложений, зачем его совать в СУБД?
Здравствуйте, amironov79, Вы писали:
A>Здравствуйте, white_znake, Вы писали:
_>>Партицирование, шардирование вполне себе повышают масштабируемость бд. Другое дело, что масштабировать бд — это сложная задача.
A>Это все про хранение данных, чем СУБД и должна заниматься. Вопрос же про код, то есть про сервер приложений, зачем его совать в СУБД?
Бывает что перекачка данных из СУБД в сервис и обратно становится узким горлышком для производительности, особенно если они живут на разных машинах.
Гораздо быстрее получается выполнить всю логику в самой БД.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Бывает что перекачка данных из СУБД в сервис и обратно становится узким горлышком для производительности, особенно если они живут на разных машинах. O>Гораздо быстрее получается выполнить всю логику в самой БД.
Ключевое слово "бывает". Получается, что логика на базе это оптимизация, которой как известно не стоит заниматься преждевременно. Когда у тебя есть отдельный сервер приложений, никто тебе не мешает здесь и сейчас написать процедуру в бд и использовать ее.
Здравствуйте, Gt_, Вы писали:
Gt_>в субд есть киллер фичи, которые бывает перевешивают все. например интеграция данных и кода, если DDL изменило типы колонок — база может пометить весь завязанный на эти типы код как инвалид и избавить от множества приключений. сервер приложений же получит эксепшен в рантайме, когда много чего уже и откатить то не выйдет. Gt_>плюс скорость, серьезная логика зачастую требует прокачивать в сервер приложений лишние петабайты.
Петабайты, рсубд, изменение ddl... Мне кажется, что-то здесь лишнее.)
Хочу добавить, что даже если обработка информации точечная, то, клиент постоянно платит за раунд-трип. При обработке чего-то действительно похожего на логику, вполне легко вылезет 20-50 селектов на всякие проверки. Батчить на клиенте... проще уже процедуру написать (имхо).
Здравствуйте, Sinclair, Вы писали:
S>Между "не стоит заниматься преждевременно" и "это же ужас-ужас" лежит целая пропасть.
Какая пропасть? Логика в базе это именно "ужас-ужас", которым стоит заниматься только в случае крайней необходимости. Базе -- данные, приложению -- логику!!!))
S>Есть много нюансов при взаимодействии СУБД и сервера приложений, от которых зависит правильный баланс. S>На одном конце спектра мы имеем client-side joins и projections с предикатами отбора, на другом — адский код внутри СУБД. S>Есть соображения производительности решения, при которых минимизация объема данных, перекачиваемых между слоями, играет принципиальную роль, и есть соображения производительности разработчиков и службы эксплуатации. S>Для которых принципиальную роль играет синхронизация версий между логикой в приложении и в СУБД.
S>И есть много разных способов эти нюансы учитывать — от написания сложной логики на T-SQL/PL-SQL и до импорта Java/.Net кода в СУБД, или кросс-компиляции управляемого кода в SQL. Где-то в промежутке сидит linq, который позволяет писать логику на шарпе, а исполнять в СУБД.
Конечно, нужен баланс. Но в любом случае на сервере приложений больше простора для написания логики, начиная от выразительности языка, заканчивая набором библиотек.
Здравствуйте, okon, Вы писали:
A>>Ключевое слово "бывает". Получается, что логика на базе это оптимизация, которой как известно не стоит заниматься преждевременно. Когда у тебя есть отдельный сервер приложений, никто тебе не мешает здесь и сейчас написать процедуру в бд и использовать ее.
O>Получается что в итоге часть логики в сервере приложений, а часть в базе и нужно поддерживать оба варианта. O>Хорошо когда логика находится в одном месте, а не размазана по разным системам. O>Зависит от ситуации, иногда выгоднее всю логику держать в базе, т.к. требуется меньше специалистов чтобы поддерживать все это.
Когда требуется меньше специалистов -- это тоже оптимизация.
Здравствуйте, Gt_, Вы писали:
Gt_>ерунда. как рсубд уже 2-3 раза в своей истории доказали что никому не нужно хранить вермишель из кривых структур языка, т.к. вермишель лишь в студенческих задачках гладко работает, а в реальных условиях не масштабируется и требует диких трудозатрат и костылей.
На этой "вермишели", фактически, написан весь современный Интернет. От Амазона до Гугла.
Здравствуйте, Sinclair, Вы писали:
S>Тогда программам потребуется Software Transactional Memory. Потому что даже если пренебречь тем, что программа вынуждена время от времени выключаться — штатно или нештатно — нам всё ещё нужно обеспечивать свойства типа атомарности и изоляции транзакций.
Не обязательно нужно. Можно обходиться eventual consistency и периодическими reconciler'ами.
Здравствуйте, Gt_, Вы писали:
Gt_>в субд есть киллер фичи, которые бывает перевешивают все. например интеграция данных и кода, если DDL изменило типы колонок — база может пометить весь завязанный на эти типы код как инвалид и избавить от множества приключений. сервер приложений же получит эксепшен в рантайме, когда много чего уже и откатить то не выйдет.
ORM и статические языки смотрят в недоумении.
Здравствуйте, Serginio1, Вы писали:
S>Ну вот нужно тебе использовать функции которых нет в SQL. Тут либо все тащить на клиента, либо писать хранимые процедуры например для регекспов
А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Serginio1, Вы писали:
S>>Ну вот нужно тебе использовать функции которых нет в SQL. Тут либо все тащить на клиента, либо писать хранимые процедуры например для регекспов C>А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать.
не надо передавать, не надо делать копию объекта в памяти. не надо потом тратить на GC.
Gt_>>в субд есть киллер фичи, которые бывает перевешивают все. например интеграция данных и кода, если DDL изменило типы колонок — база может пометить весь завязанный на эти типы код как инвалид и избавить от множества приключений. сервер приложений же получит эксепшен в рантайме, когда много чего уже и откатить то не выйдет. C>ORM и статические языки смотрят в недоумении.
ормы валидируют структуру лишь при старте, если приложение стартануло — все. глупый орм оторванный от данных ничерта не знает о происходящем после старта в субд.
ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.
А что плохого?
По-твоему скольки процентам БД когда-либо потребуется масштабирование? Эта цифра больше пяти?
Здравствуйте, Gt_, Вы писали:
C>>А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать. Gt_>не надо передавать, не надо делать копию объекта в памяти. не надо потом тратить на GC.
И это реально ускорит приложение? Не верю. В большинстве случаев, скорее всего, окажется выгоднее кэшировать данные на клиенте и запускать поиск там локально вместо того, чтобы лезть в БД.
Типичный пример — строка с автокомплитом, чтобы можно было по "ка ма 12" показывать вариант "ул. Карла Маркса, д. 123" из базы клиентов.
Ну и, вообще-то, регэкспы уже есть в виде встроенных функций чуть менее, чем во всех нормальных РСУБД. Какие ещё варианты для функций есть?
C>>>ORM и статические языки смотрят в недоумении. Gt_>>ормы валидируют структуру лишь при старте, если приложение стартануло — все. глупый орм оторванный от данных ничерта не знает о происходящем после старта в субд. C>Если у вас приложения обновляются без всякого процесса прямо методом "херак, херак — и в продакшн", то это никакая РСУБД не спасёт.
спасает. у рсубд данные и код полностью интегрированны. в оракле не важно кто накатил ddl, поломанный pl/sql код будет отслежен. и это киллер фича.
снаружи субд же решение лишь в ручную на уровне "процесса". я конечно рад что вы это решаете кустарными "процессами", но бывают задачи где нужна полноценная интеграция кода и даных.
Здравствуйте, Gt_, Вы писали:
Gt_> C>Если у вас приложения обновляются без всякого процесса прямо методом "херак, херак — и в продакшн", то это никакая РСУБД не спасёт. Gt_> спасает. у рсубд данные и код полностью интегрированны. в оракле не важно кто накатил ddl, поломанный pl/sql код будет отслежен. и это киллер фича.
Ну поломалась хранимка. И? Приложу отвалится в самый неподходящий момент.
А ОРМ таки попытается туда что-то записать. И если изменения заключались только в создании колонки, то в большинстве случаев это ничему не повредит.
ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.
Не согласен. А для кого придумали шардирование, микросервисы, репликацию (если уж совсем край)?
Неее, ну если тебе дадут реляционную базу и скажут: "Масштабируй," а вся логика приложения завязана на нее и распилить монолит времени нет, то да (ну, там был у тебя бложек на вордпресс, а завтра тебе нужно из него сделать фейсбук). Но, вообще, у Яндекса вся почта на Postgres работает, если чё.
Здравствуйте, Masterspline, Вы писали:
M>Не согласен. А для кого придумали шардирование, микросервисы, репликацию (если уж совсем край)?
А какое это отношение имеет к реализации бизнес логики в хранимым процедурам?
M>Неее, ну если тебе дадут реляционную базу и скажут: "Масштабируй," а вся логика приложения завязана на нее и распилить монолит времени нет, то да (ну, там был у тебя бложек на вордпресс, а завтра тебе нужно из него сделать фейсбук). Но, вообще, у Яндекса вся почта на Postgres работает, если чё.
У яндекса почта на хранимых процедурах? Они же пишут, что у них бэкенд на плюсах, и что это им позволило достаточно безболезненно перейти с оракла на постгрес.
Здравствуйте, amironov79, Вы писали:
A>Доверяю, потому что в моем понимании джойны, выбороки и проекции это не совсем уровень бизнес-логики, это уровень доступа к данным.
Ну, и где же граница?
A>Но мы же не про sql говорим, а про процедурные расширения. В чем преимущества plsql/tsql перед java/c# как инструмента для обсчета и преобразования, когда данные уже выбраны из таблиц?
В локальности.
A>Какие же они абстрактные? Как языки plsql и tsql (на фоне java и c#), мягко говоря, полная ерунда. Библиотек нормальных нет, коллекций нормальных нет, сахара минимум. Вообще странно, что их называют языками для обработки данных.
Ну и что? A>И зачем себя ограничивать в архитектурных решениях? Если возникнет задача, которую не решить процедурными языками базы из-за отсутствия нужных библиотек, то что делать? Сказать, что не можем? Писать внешний сервис?
Как раз я предлагаю не ограничивать. Это вы хотите ограничиться логикой в app server. A>А если расчеты начнут нагружать процессор на сервере базы, как будете масштабировать решение?
В зависимости от конкретной задачи. Тут универсальными мантрами не отделаешься.
S>>А ведь технически ничто не мешает скомпилировать регекс в байткод, и запихать его внутрь СУБД. Где он будет исполняться со скоростью мысли, и сэкономит 90% трафика между СУБД и сервером приложений. S>>Заодно это позитивно скажется на времени удержания локов (или на шансах нарваться на конфликт при оптимистике). A>Каким образом? За счет скорости выполнения? А она точно будет существенно больше? Например, относительно использования dapper или linq2db.
За счёт того, что канал между памятью и диском в сервере БД существенно шире, чем канал между апп.сервером и сервером БД.
При хорошей селективности предиката в апп.сервер поедет в сотню раз меньше данных, и СУБД сможет завершить транзакцию раньше. S>>При этом всю рутинную работу по проверке соответствия версии регекса, которая нужна клиенту, и версии регекса, лежащей в базе, можно возложить на тупую неутомимую машину, а не на рассеянные кожаные мешки. A>Здесь вообще не понял про что речь. Статическая компиляция регулярки?
Конечно. Вы же знали, что регулярку можно скомпилировать, а не интерпретировать? A>Бизнес-логика заканчивается на регулярных выражениях? Хорошо живете.
Я намеренно привожу простой пример. Нет смысла обсуждать сложные вещи в бизнес-логике, пока вы не поймёте технические основы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>За счёт того, что канал между памятью и диском в сервере БД существенно шире, чем канал между апп.сервером и сервером БД. S>При хорошей селективности предиката в апп.сервер поедет в сотню раз меньше данных, и СУБД сможет завершить транзакцию раньше.
Тут надо штаны или крестик. Хранимые процедуры в существующих РСУБД, фактически, не оптимизируются никак. Они просто применяются как фильтр к выбранным строкам.
Если у нас процедура должна обработать 100500 тонн данных, то это будет уже не OLTP. А если не OLTP, то стоит ли корёжить архитектуру ради того, чтобы квартальный отчёт будет составляться 10 минут вместо 20? Если же не нужно передавать 100500 тонн данных, то какие проблемы их закинуть на клиента?
Здравствуйте, Gt_, Вы писали:
C>>И это реально ускорит приложение? Не верю. В большинстве случаев, скорее всего, окажется выгоднее кэшировать данные на клиенте и запускать поиск там локально вместо того, чтобы лезть в БД. Gt_>кеш уже есть в субд. делать копию этого же кеша что бы там что-то запускать быстрее не будет.
Будет.
C>>Типичный пример — строка с автокомплитом, чтобы можно было по "ка ма 12" показывать вариант "ул. Карла Маркса, д. 123" из базы клиентов. Gt_>угу. а потом ныть что примитивный сайт кушает 1.5GB и что бы просто побровсить нужна машина минимум с 8Gb рам и SSD.
SSD-то зачем? Кэш в памяти. Если при этом приложение будет работать быстрее, чем глаз замечает задержку, то пользователям будет совсем пофиг сколько там терабайт памяти серверу нужно.
C>>Ну и, вообще-то, регэкспы уже есть в виде встроенных функций чуть менее, чем во всех нормальных РСУБД. Какие ещё варианты для функций есть? Gt_>задачи бывают разные, как выше заметили важен баланс, а не тупое следование одной концепции. иначе нам скоро и 8Gb уже не хватит что бы побровсить.
Причём тут браузер вообще?
Gt_>> C>Если у вас приложения обновляются без всякого процесса прямо методом "херак, херак — и в продакшн", то это никакая РСУБД не спасёт. Gt_>> спасает. у рсубд данные и код полностью интегрированны. в оракле не важно кто накатил ddl, поломанный pl/sql код будет отслежен. и это киллер фича.
DC>Ну поломалась хранимка. И? Приложу отвалится в самый неподходящий момент. DC>А ОРМ таки попытается туда что-то записать. И если изменения заключались только в создании колонки, то в большинстве случаев это ничему не повредит.
угу. в большинстве случаев прокатит. но мне кажется этот душок индии все же не отменит киллер фичу интеграции данных и кода pl/sql.
M>>Не согласен. А для кого придумали шардирование, микросервисы, репликацию (если уж совсем край)?
A>А какое это отношение имеет к реализации бизнес логики в хранимым процедурам?
Ты бы цитировал все целиком и без этого дурацкого "Здравствуйте....", тогда было бы понятно. Я отвечал на то, что база — самая плохо масштабируемая часть. Если таблицу с пользователями вынести в одну базу, а таблицу с сообщениями шардировать на 100, то вполне может получаться масштабирование. При этом хранимые процедуры тоже масштабируются.
M>>Неее, ну если тебе дадут реляционную базу и скажут: "Масштабируй," а вся логика приложения завязана на нее и распилить монолит времени нет, то да (ну, там был у тебя бложек на вордпресс, а завтра тебе нужно из него сделать фейсбук). Но, вообще, у Яндекса вся почта на Postgres работает, если чё.
A>У яндекса почта на хранимых процедурах? Они же пишут, что у них бэкенд на плюсах, и что это им позволило достаточно безболезненно перейти с оракла на постгрес.
Понятия не имею, есть ли у них хранимые процедуры, но это сильно оффтопик, потому что не про масштабирование. Смысл в том, что не факт, что масштабировать вообще нужно. Яндексу для почты хватило одного сервера Postgres, а проект довольно крупный (возможно несколько для репликации, но база целиком помещается на одном сервере, насколько я понял).
Здравствуйте, Gt_, Вы писали:
Gt_>угу. в большинстве случаев прокатит. но мне кажется этот душок индии все же не отменит киллер фичу интеграции данных и кода pl/sql.
С учетом наличия в оракле library cache так себе фича.
Здравствуйте, Masterspline, Вы писали:
M>Ты бы цитировал все целиком и без этого дурацкого "Здравствуйте....", тогда было бы понятно. Я отвечал на то, что база — самая плохо масштабируемая часть. Если таблицу с пользователями вынести в одну базу, а таблицу с сообщениями шардировать на 100, то вполне может получаться масштабирование. При этом хранимые процедуры тоже масштабируются.
То есть весь rsdn знает, что "M" это всегда "Masterspline". Да ты крут!!!
По теме: как масштабируются хранимые процедуры? Где на это можно посмотреть хотя бы одним глазком?
A>>У яндекса почта на хранимых процедурах? Они же пишут, что у них бэкенд на плюсах, и что это им позволило достаточно безболезненно перейти с оракла на постгрес.
M>Понятия не имею, есть ли у них хранимые процедуры, но это сильно оффтопик, потому что не про масштабирование. Смысл в том, что не факт, что масштабировать вообще нужно. Яндексу для почты хватило одного сервера Postgres, а проект довольно крупный (возможно несколько для репликации, но база целиком помещается на одном сервере, насколько я понял).
Здравствуйте, amironov79, Вы писали:
A>По теме: как масштабируются хранимые процедуры? Где на это можно посмотреть хотя бы одним глазком?
(достаёт сову и глобус)
Например хранимка может работать с updatable view, а тот в свою очередь работает с секционированной таблицей, раскиданной по разным шардам на куче sql-серверов.
Здравствуйте, Слава, Вы писали:
С>(достаёт сову и глобус)
С>Например хранимка может работать с updatable view, а тот в свою очередь работает с секционированной таблицей, раскиданной по разным шардам на куче sql-серверов.
С>В тред призывается Sinclair.
Это опять-таки все про выборку данных. Никто и ничто не мешает мне подергать туже view с сервера приложений. Вопрос же про то, что вы будете делать, когда ваша процедура упрется в процессор?
Здравствуйте, Слава, Вы писали:
С>Чтобы процедура упёрлась в процессор, надо на ней писать то, что требует процессора. И что же, кто-то подобный код на pl/sql пишет?
Мы же про бизнес-логику в базе разговариваем? Где же ее еще писать, если сервера приложений нет? А если сервер приложений есть, то зачем тогда писать что-либо на plsql?
Здравствуйте, Gt_, Вы писали:
Gt_> DC>Ну поломалась хранимка. И? Приложу отвалится в самый неподходящий момент. Gt_> DC>А ОРМ таки попытается туда что-то записать. И если изменения заключались только в создании колонки, то в большинстве случаев это ничему не повредит. Gt_> угу. в большинстве случаев прокатит. но мне кажется этот душок индии все же не отменит киллер фичу интеграции данных и кода pl/sql.
Здравствуйте, amironov79, Вы писали:
С>>Чтобы процедура упёрлась в процессор, надо на ней писать то, что требует процессора. И что же, кто-то подобный код на pl/sql пишет?
A>Мы же про бизнес-логику в базе разговариваем? Где же ее еще писать, если сервера приложений нет? А если сервер приложений есть, то зачем тогда писать что-либо на plsql?
Скажите пожалуйста, что у вас такая за бизнес-логика, которая требует лютого количества процессора? Составление и коррекция плана перевозок на 100500 автомобилей?
Здравствуйте, Слава, Вы писали:
С>Скажите пожалуйста, что у вас такая за бизнес-логика, которая требует лютого количества процессора? Составление и коррекция плана перевозок на 100500 автомобилей?
Да любая задача, которая выходит за рамки перекладывания данных из одной таблички в другую. И почему лютого? Вполне обычного. Напомните, как там сервера субд лицензируются? По ядрам или по сокетам?
Gt_>>угу. в большинстве случаев прокатит. но мне кажется этот душок индии все же не отменит киллер фичу интеграции данных и кода pl/sql.
A>С учетом наличия в оракле library cache так себе фича.
ты бредишь. учитывая что смена статуса выбрасывает процедуры из library cache.
Здравствуйте, Gt_, Вы писали:
A>>С учетом наличия в оракле library cache так себе фича.
Gt_>ты бредишь. учитывая что смена статуса выбрасывает процедуры из library cache.
Ага, выбрасывает прямо в тот момент, когда твоя процедура твои петабайты лопатит.
Gt_>> DC>Ну поломалась хранимка. И? Приложу отвалится в самый неподходящий момент. Gt_>> DC>А ОРМ таки попытается туда что-то записать. И если изменения заключались только в создании колонки, то в большинстве случаев это ничему не повредит. Gt_>> угу. в большинстве случаев прокатит. но мне кажется этот душок индии все же не отменит киллер фичу интеграции данных и кода pl/sql.
DC>Которая рушит приложение всё и сразу?
все или ничего — киллер фича. странно, что такой примитив нужно разжовывать.
Здравствуйте, Gt_, Вы писали:
Gt_>угу. в большинстве случаев прокатит. но мне кажется этот душок индии все же не отменит киллер фичу интеграции данных и кода pl/sql.
Душок Индии — это как раз "интеграция" PL/SQL.
Здравствуйте, Слава, Вы писали:
С> Скажите пожалуйста, что у вас такая за бизнес-логика, которая требует лютого количества процессора? Составление и коррекция плана перевозок на 100500 автомобилей?
Скажите, а что это у вас за бизнес такой, что не требует количества процессора? Купи-продай на 2 продажи в год?
Здравствуйте, amironov79, Вы писали:
A>Как всегда определяется исходя из конкретных обстоятельств. Запросом к базе максимально фильтруем данные, в приложении раскладываем их по полочкам (коллекциям) и спокойно с ними работаем. Надо сгенерировать штрих-код, подключаем библиотеку, генерируем, сохраняем обратно в базу.
Отличный пример. То есть мы делаем round-trip между базой и апп сервером только ради того, чтобы вычислить несложную функцию. Не уверен, что это — архитектурно лучший вариант.
A>Надо передать данные по проприетарному протоколу, берем у производителя библиотеку, подключаем, передаем. Как это сделать на бд я тоже представляю, но будет это выглядеть как набор костылей.
Конечно. Не дело СУБД заниматься передачей данных по проприетарным протоколам. Тем более, что это может вносить непредсказуемые задержки во времена исполнения транзакций.
A>Единственный плюс. Но если рассматривать архитектуру всей системы в целом, его даже не стоит принимать во внимание.
Конечно. Отсюда и растут современные заниженные ожидания: железо с начала 2000х ускорилось на порядки, а ентерпрайз системы как прожёвывали заказы по 30 секунд, так и прожёвывают.
Потом оказывается, что общей производительности не хватает, и мы выбиваем бюджет на миграции в NoSQL, который лучше шардится и вообще позволяет делать на 250 машинах то, что при толковом проектировании можно было сделать на одной.
A>Как что? Элементарных вещей в этих языках нет, бери любую возможность из современного языка, и не найдешь ее. Про коллекции я уже говорил, еще нет пространств имен (привет, библиотеки), нет подобия linq to objects (хотя казалось бы, данные же обрабатывем), нет кортежей (и это языки расширения в рсубд), нет вывода типов, нет рефлексии, а следовательно нет и мапперов. Да ничего там нет, кроме временных таблиц, и в результате все проблемы выглядят как гвозди.
А кто вас заставляет писать на T-SQL? Во-первых, мы можем генерировать SQL, решая проблему структуризации кода. Тот же linq2db и есть пример такого генератора, который умеет порождать высокоэффективный SQL удобным для программиста способом. Во-вторых, все современные РСУБД позволяют писать код хранимок на широком наборе языков общего назначения.
A>Вы уж определитесь: "стоит избегать" или "не ограничиваете". Вот есть у вас какой-либо расчет на plsql/tsql. Условно, при закрытии месяца база у вас ложится, потому что этот расчет очень любит процессор. Как будете выходить из положения?
Из моего личного опыта — обычно день-два, потраченных на улучшение "расчёта" окупаются сторицей. То, что там "ложилось", начинает исполняться за 10 секунд. Потому что "ложащийся" расчёт написан на SQL неэффективным образом — множество курсоров, временных таблиц, и прочей наркомании.
"Вытащить" расчёт из базы как правило помогает мало — просто потому, что его производительность упирается в дисковый обмен. (Обычно никто даже не пытается внести в базу вычислительно-интенсивные вещи, типа мандельброта или блокчейна).
Если хранимка прожёвывает гигабайт дисковых данных за полчаса, то не получится её ускорить, заставив сервер приложений тащить этот гигабайт к себе в память.
A>Ну, как бы, не факт. Канал между сервером приложений и сервером субд может быть и быстрее канала между сервером субд и хранилищем данных. Все зависит от конкретных решений.
В таком случае у нас есть простой способ: починить канал между сервером и хранилищем. Техника делать быстрые каналы у нас есть.
A>Так еще со времен перла. А при чем здесь версия регулярки на базе и на клиенте? Что такое вообще версия регулярного выражения?
Смотрите: вот у меня в запросе использовалась регулярка типа "\(d{3,6}\)". Потом требования поменялись, и стала нужна регулярка типа "\(d{2,11}\)".
Обычно именно такие сценарии пугают в случае наличия логики в сервере — потому что в апп-сервере регулярка уже новая, а в базе осталась старая.
Это и есть "версия регулярки".
Так вот — ничто мне не мешает внутри моего кода сервера приложений вставить что-то типа
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(@SpecificRegex) AND type = 'FS', N'FT')
BEGIN
... -- код по заталкиванию кода функции MyRegex23423521212 в базуEND
Теперь можно писать
select * from mytable where dbo.MyRegex23423521212(data)
В имя функции входит hash от regex string, поэтому мы защищены от конфликтов между разными версиями кода, ожидающими разных регекспов.
Всё это, естественно, спрятано под капот, и в прикладном коде мы пишем запрос на linq2db.
A>>>Бизнес-логика заканчивается на регулярных выражениях? Хорошо живете. S>>Я намеренно привожу простой пример. Нет смысла обсуждать сложные вещи в бизнес-логике, пока вы не поймёте технические основы.
A>А вы приведите сложный. Вы же библиотеку регулярных выражений не на plsql/tsql писали, эта возможность вам любезно предоставлена самим движком субд. Кстати, если бы не было регулярок в движке, как бы выходили из положения?
Вот я вам на пальцах объяснил, как добавить поддержку регулярок в СУБД, где их из коробки нету (например, MS SQL).
Более того — мы потенциально можем строить специализированную версию функции для каждого регулярного выражения, и у нас не будет компиляции строки на каждое обращение к кортежу (как было бы при втаскивании в СУБД единственной функции Regex(string data, string pattern)
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, amironov79, Вы писали:
A>Здравствуйте, Слава, Вы писали:
С>>Чтобы процедура упёрлась в процессор, надо на ней писать то, что требует процессора. И что же, кто-то подобный код на pl/sql пишет?
A>Мы же про бизнес-логику в базе разговариваем? Где же ее еще писать, если сервера приложений нет? А если сервер приложений есть, то зачем тогда писать что-либо на plsql?
Конечно же сервер приложений есть. Мы просто выбираем границу между логикой на стороне СУБД и на стороне апп-сервера оптимальным для каждого запроса способом.
Писать на Pl-sql можно как раз для того, чтобы улучшить throughput.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Serginio1, Вы писали:
S>>Ну вот нужно тебе использовать функции которых нет в SQL. Тут либо все тащить на клиента, либо писать хранимые процедуры например для регекспов C>А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать.
Ну вот представь объемы данных для передчи на клиента.
Ты на трафике сдохнешь.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.
Универсальных решений вообще-то нет.
Процедуры могут реализовывать высокоуровневую логику хранения данных. Обновилось поле в какой-то таблице — пересчитать ещё 40+ полей в других. И это вообще-то главная фишка реляционных СУБД, если "целостность" данных не нужна можно взять тот-же elastic, без процедур и с прекрасным масштабированием.
Или когда с базой работает несколько разных приложений, написанных на разных языках. Можно дублировать общий код во всех них, можно запилить ещё одно, абстрагирующее базу данных, а можно вынести общий код доступа к данным в хранимые процедуры.
Или когда сервис работает с небольшим кусочком здоровой и сложно базы данных с тысячами таблиц и полей — проще завернуть взаимодействие в набор простых хранимых процедур, чем на каждый чих лопатить документацию и разбираться какие поля и где запрос должен менять, а какие ни-ни.
Ну и тезис о немасштабируемости все же не совсем корректен. В реляционных СУБД плохо масштабируется один единственный тип операций — согласованные изменения данных. Насчет остального, можно вспомнить к примеру ранний Skype — с хранением данных рассыпанным по тысячам серверов PostgreSQL или Stackoverflow с их экземпляром SQL Server-а.
Поэтому, кидаться переписывать всё на хранимые процедуры, разумеется не стоит. Но в некоторых задачах, это хорошо работающий инструмент. Причем, чем развесистей и сложней база, тем больше шансов, что от хранимок будет польза.
Здравствуйте, Serginio1, Вы писали:
C>>А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать. S> Ну вот представь объемы данных для передчи на клиента. S>Ты на трафике сдохнешь.
Если его супермного, то проблемы будут и у хранимок.
Здравствуйте, Sinclair, Вы писали:
S>Отличный пример. То есть мы делаем round-trip между базой и апп сервером только ради того, чтобы вычислить несложную функцию. Не уверен, что это — архитектурно лучший вариант.
А какая функция сложная? Генерация изображений, документов, анализ данных за продолжительный период? И какой будет этот round-trip, если сервера рядом стоят? Где-то есть бенчмарки?
S>Потом оказывается, что общей производительности не хватает, и мы выбиваем бюджет на миграции в NoSQL, который лучше шардится и вообще позволяет делать на 250 машинах то, что при толковом проектировании можно было сделать на одной.
Гуглам с майкрософтами можно, а другим нельзя?
S>А кто вас заставляет писать на T-SQL? Во-первых, мы можем генерировать SQL, решая проблему структуризации кода. Тот же linq2db и есть пример такого генератора, который умеет порождать высокоэффективный SQL удобным для программиста способом. Во-вторых, все современные РСУБД позволяют писать код хранимок на широком наборе языков общего назначения.
Эээ, какое отношение sql имеет к хранимкам базы? Тем более sql, сгенерированный linq2db.
Хранимки на языках общего назначения, уже, как бы сказать, не совсем хранимки. В каком контексте будет выполнятся код на "неродном" языке? Насколько я понимаю, для базы эта процедура будет выглядеть как внешний клиент, и на переключении контекста можно много потерять (хотя возможно какие-то оптимизации этого дела и есть). При этом набор языков все-равно ограничен, идет привязка к версии рантайма, который идет с данной версией субд, чтобы настроить разрешения, часто надо идти на поклон к админам. В общем, так себе возможность, но на безрыбье сойдет.
S>"Вытащить" расчёт из базы как правило помогает мало — просто потому, что его производительность упирается в дисковый обмен. (Обычно никто даже не пытается внести в базу вычислительно-интенсивные вещи, типа мандельброта или блокчейна).
А что мандельброт и блокчейн это уже не бизнес логика?
A>>Ну, как бы, не факт. Канал между сервером приложений и сервером субд может быть и быстрее канала между сервером субд и хранилищем данных. Все зависит от конкретных решений. S>В таком случае у нас есть простой способ: починить канал между сервером и хранилищем. Техника делать быстрые каналы у нас есть.
Техника расширить канал между сервером приложений и сервером субд тоже есть.
A>>А вы приведите сложный. Вы же библиотеку регулярных выражений не на plsql/tsql писали, эта возможность вам любезно предоставлена самим движком субд. Кстати, если бы не было регулярок в движке, как бы выходили из положения? S>Вот я вам на пальцах объяснил, как добавить поддержку регулярок в СУБД, где их из коробки нету (например, MS SQL).
Я все-равно не понял какую проблему вы решали.
S>Более того — мы потенциально можем строить специализированную версию функции для каждого регулярного выражения, и у нас не будет компиляции строки на каждое обращение к кортежу (как было бы при втаскивании в СУБД единственной функции Regex(string data, string pattern)
Компиляция реегулярок тоже не имеет отношения к процедурам в базе. На клиенте базы будет все тоже самое.
Здравствуйте, Sinclair, Вы писали:
A>>Мы же про бизнес-логику в базе разговариваем? Где же ее еще писать, если сервера приложений нет? А если сервер приложений есть, то зачем тогда писать что-либо на plsql? S>Конечно же сервер приложений есть. Мы просто выбираем границу между логикой на стороне СУБД и на стороне апп-сервера оптимальным для каждого запроса способом. S>Писать на Pl-sql можно как раз для того, чтобы улучшить throughput.
Так с чего и начали разговор: пишем на plsql только для оптимизации.
Здравствуйте, Cyberax, Вы писали: S>>Ну вот нужно тебе использовать функции которых нет в SQL. Тут либо все тащить на клиента, либо писать хранимые процедуры например для регекспов C>А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать.
Ну, во-первых, "линейный поиск" СУБД всё ещё может сделать быстрее, чем апп сервер.
Потому, что при where IsZipCodeMatch(userAddress) можно делать "линейный поиск" по индексу, в котором есть только userAddress, что положительно сказывается на объёме дискового IO. А уже потом делать bookmark lookup, чтобы подтянуть остальные данные для дальнейшей фильтрации или отдачи клиенту. То есть переход от full table scan к index scan — это уже хорошо.
Попытка сделать аналогичный финт в апп.сервере обладает всеми недостатками client side join.
Во-вторых, наличие "хранимки для регекспа" внутри базы позволяет мне делать вычисляемые колонки или индексированные/материализованные view. Что, в свою очередь, переводит запрос из index scan в index seek.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Два основных класса логики, которые не стоит тащить внутрь СУБД: CPU-bound вычисления и Network-bound обмен с внешним миром. S>То есть, скажем, отправлять email изнутри СУБД — плохая идея. Или, скажем, делать фильтрацию изображений.
С этим полностью согласен. Тогда о чем спор? Только о границе ответственности между субд и сервером приложений? Тут однозначного ответа нет, каждый выбтрает эту границу, исходя из своего опыта и возможностей.
Здравствуйте, amironov79, Вы писали:
A>С этим полностью согласен. Тогда о чем спор? Только о границе ответственности между субд и сервером приложений? Тут однозначного ответа нет, каждый выбтрает эту границу, исходя из своего опыта и возможностей.
Совершенно верно. Но, ещё раз: это совсем не то же самое, что просто "процедуры в БД — это же ужас-ужас!"
Нельзя сводить всю вот эту вот сложность к этой фразе. Разве что "свой опыт и возможности" равны нулю — но и то, это скорее повод расширять опыт и исследовать возможности, а не просто говорить "я не понимаю, как делать логику в БД, поэтому не буду её делать".
От этого — один шаг до "я не понимаю реляционки, запилим всё на mongo DB".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Совершенно верно. Но, ещё раз: это совсем не то же самое, что просто "процедуры в БД — это же ужас-ужас!"
В моем понимании (думаю, и в понимании большинства) процедуры в базе это именно plsql/tsql. И эта фраза относится конретно к этим языкам. Использование же языков общего назначения, как языков хранимых процедур, не особо распространенная практика, производители субд не пиарят эту возможность (так как теряют vendor-lock), а следовательно у этого дела плохая инструментальная поддержка, мало документации. Убедить людей, что, например, писать на java вместо plsql или на c# вместо tsql намного удобнее, практически невозможно.
S>Нельзя сводить всю вот эту вот сложность к этой фразе. Разве что "свой опыт и возможности" равны нулю — но и то, это скорее повод расширять опыт и исследовать возможности, а не просто говорить "я не понимаю, как делать логику в БД, поэтому не буду её делать". S>От этого — один шаг до "я не понимаю реляционки, запилим всё на mongo DB".
Что вы имеете против NoSql? Xml, json в таблицах не храните?
Здравствуйте, amironov79, Вы писали: A>В моем понимании (думаю, и в понимании большинства) процедуры в базе это именно plsql/tsql. И эта фраза относится конретно к этим языкам.
Ну, вот видите — оказывается и относится не ко всему, и означает не то, что написано.
A> Использование же языков общего назначения, как языков хранимых процедур, не особо распространенная практика, производители субд не пиарят эту возможность (так как теряют vendor-lock),
Ну конечно же не пиарят. Прямо-таки скрывают от народа.
Про потерю вендор-лока тоже смешно. A>а следовательно у этого дела плохая инструментальная поддержка, мало документации. Убедить людей, что, например, писать на java вместо plsql или на c# вместо tsql намного удобнее, практически невозможно.
Странно. Буквально пяток ответов назад вы энергично доказывали мне, что писать на java вместо plsql или на c# вместо tsql намного удобнее. И вдруг — такой поворот!
A>Что вы имеете против NoSql? Xml, json в таблицах не храните?
Я даже начинать про это не буду
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
A>>В моем понимании (думаю, и в понимании большинства) процедуры в базе это именно plsql/tsql. И эта фраза относится конретно к этим языкам. S>Ну, вот видите — оказывается и относится не ко всему, и означает не то, что написано.
Проведите опрос среди базовиков: на каком языке пишутся хранимые процедуры? Думаю, подавляющее большинство не будет знать ничего за пределами plsql/tsql. А если будут, спросите про язык первого выбора для написания хранимки? Думаю 99.99% скажут про plsql/tsql.
A>> Использование же языков общего назначения, как языков хранимых процедур, не особо распространенная практика, производители субд не пиарят эту возможность (так как теряют vendor-lock), S>Ну конечно же не пиарят. Прямо-таки скрывают от народа.
Я про пиар, а не про документацию. У оракла java stored procedures тоже очень хорошо описаны. Но кто про это знает?
S>Про потерю вендор-лока тоже смешно.
И что смешного? Если система большей частью завязана на проприетарный язык, то портировать ее на другую базу практически невозможно, только переписать. А значит разработчики и пользователи этой системы будут постоянными покупателями данной субд. Разве это неочевидно?
A>>а следовательно у этого дела плохая инструментальная поддержка, мало документации. Убедить людей, что, например, писать на java вместо plsql или на c# вместо tsql намного удобнее, практически невозможно. S>Странно. Буквально пяток ответов назад вы энергично доказывали мне, что писать на java вместо plsql или на c# вместо tsql намного удобнее. И вдруг — такой поворот!
Для меня намного удобнее, прямо небо и земля. Другим надо русскую документацию, обучение по новому для них языку, интеграцию со средой разработки (чтобы им настроили и ткнули пальцем куда код писать), ну и распоряжение руководства, конечно же.
A>>Что вы имеете против NoSql? Xml, json в таблицах не храните? S>Я даже начинать про это не буду
Здравствуйте, Sinclair, Вы писали:
C>>А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать. S>Ну, во-первых, "линейный поиск" СУБД всё ещё может сделать быстрее, чем апп сервер. S>Потому, что при where IsZipCodeMatch(userAddress) можно делать "линейный поиск" по индексу, в котором есть только userAddress, что положительно сказывается на объёме дискового IO.
Ну так и пользовательский код тоже может запросить пары <ID>-<User Address>. Которые будут из того же индекса читаться.
S>А уже потом делать bookmark lookup, чтобы подтянуть остальные данные для дальнейшей фильтрации или отдачи клиенту. То есть переход от full table scan к index scan — это уже хорошо.
Ну так и пользовательский код потом может просто по списку совпадающих ID загрузить таблицу. Если смотреть новомодный GraphQL — там это вообще удобно делается.
S>Во-вторых, наличие "хранимки для регекспа" внутри базы позволяет мне делать вычисляемые колонки или индексированные/материализованные view. Что, в свою очередь, переводит запрос из index scan в index seek.
А вот это вообще лучше не использовать, из соображений сохранения вменяемости.
В принципе, я ещё могу понять использование каких-то очень абстрактных функций в БД, типа regexp match. Это скорее восполнение недостатка самой БД (девелоперы не додумались добавить), но я люто против чего-либо, что связано с бизнес-логикой. Т.е. "ZipMatches" — это уже крайне плохо.
Здравствуйте, amironov79, Вы писали:
A>Проведите опрос среди базовиков: на каком языке пишутся хранимые процедуры? Думаю, подавляющее большинство не будет знать ничего за пределами plsql/tsql. А если будут, спросите про язык первого выбора для написания хранимки? Думаю 99.99% скажут про plsql/tsql.
А если опросить фронтендеров про расшифровку SOLID, то 99% не смогут ответить.
Ну и что? Мы обсуждаем здесь не невежество отдельных представителей профессии, а правильные ответы на сложные вопросы.
A>Я про пиар, а не про документацию. У оракла java stored procedures тоже очень хорошо описаны. Но кто про это знает?
Все, кому интересно . A>И что смешного? Если система большей частью завязана на проприетарный язык, то портировать ее на другую базу практически невозможно, только переписать. А значит разработчики и пользователи этой системы будут постоянными покупателями данной субд. Разве это неочевидно?
Очевидно то, что синтаксис языка играет десятую роль. Всё упирается в нюансы: как устроено взаимодействие с контекстом. Даже если держать всю логику внутри апп.сервера, портирование на другую СУБД — это тот ещё квест.
В реальности написание хранимок на управляемом языке только усугубляет вендор-лок.
A>Для меня намного удобнее, прямо небо и земля. Другим надо русскую документацию, обучение по новому для них языку, интеграцию со средой разработки (чтобы им настроили и ткнули пальцем куда код писать), ну и распоряжение руководства, конечно же.
Всё это уже есть. И документация, и тьюториалы, и интеграция с MS VS. Распоряжение вашего руководства, увы, Редмонд обеспечить не в состоянии.
Да и вообще — руководству, ему ведь помогать надо. Оно "распоряжается" не на пустом месте; работа архитектора — принять решение и обосновать его. Обоснует pl/sql — будут писать на pl/sql. Обоснует java — будут писать на java. Обоснует хранимки на java в oracle — будут писать хранимки на java.
Вот, этот форум — он как раз для архитекторов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sinclair, Вы писали:
C>>>А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать. S>>Ну, во-первых, "линейный поиск" СУБД всё ещё может сделать быстрее, чем апп сервер. S>>Потому, что при where IsZipCodeMatch(userAddress) можно делать "линейный поиск" по индексу, в котором есть только userAddress, что положительно сказывается на объёме дискового IO. C>Ну так и пользовательский код тоже может запросить пары <ID>-<User Address>. Которые будут из того же индекса читаться. S>>А уже потом делать bookmark lookup, чтобы подтянуть остальные данные для дальнейшей фильтрации или отдачи клиенту. То есть переход от full table scan к index scan — это уже хорошо. C>Ну так и пользовательский код потом может просто по списку совпадающих ID загрузить таблицу. Если смотреть новомодный GraphQL — там это вообще удобно делается.
Я вам уже на это заранее ответил: Попытка сделать аналогичный финт в апп.сервере обладает всеми недостатками client side join.
То есть мы говорим о том, что вместо отбора 10% полных записей внутри СУБД, вы предлагаете втащить 100% пар ID-UserAddress в аппсервер, затем сделать фильтрацию, и запихать 10% ID в СУБД, чтобы извлечь из неё 10% полных записей.
Вам уже видно, почему это будет медленнее, чем предлагаемая альтернатива?
C>А вот это вообще лучше не использовать, из соображений сохранения вменяемости.
Да что вы! А что это за соображения — можно озвучить?
C>В принципе, я ещё могу понять использование каких-то очень абстрактных функций в БД, типа regexp match. Это скорее восполнение недостатка самой БД (девелоперы не додумались добавить), но я люто против чего-либо, что связано с бизнес-логикой. Т.е. "ZipMatches" — это уже крайне плохо.
Аргументы?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
S>>Ну, во-первых, "линейный поиск" СУБД всё ещё может сделать быстрее, чем апп сервер. S>>Потому, что при where IsZipCodeMatch(userAddress) можно делать "линейный поиск" по индексу, в котором есть только userAddress, что положительно сказывается на объёме дискового IO. C>Ну так и пользовательский код тоже может запросить пары <ID>-<User Address>. Которые будут из того же индекса читаться.
Откуда появится индекс, если в базе не будет IsZipCodeMatch? Можно, конечно, сделать дополнительное индексированное поле, куда писать результат IsZipCodeMatch сервером приложений, но это будет совсем другой индекс.
Здравствуйте, Sinclair, Вы писали:
A>>Я про пиар, а не про документацию. У оракла java stored procedures тоже очень хорошо описаны. Но кто про это знает? S>Все, кому интересно .
Интересно это немногим.
A>>И что смешного? Если система большей частью завязана на проприетарный язык, то портировать ее на другую базу практически невозможно, только переписать. А значит разработчики и пользователи этой системы будут постоянными покупателями данной субд. Разве это неочевидно? S>Очевидно то, что синтаксис языка играет десятую роль. Всё упирается в нюансы: как устроено взаимодействие с контекстом. Даже если держать всю логику внутри апп.сервера, портирование на другую СУБД — это тот ещё квест. S>В реальности написание хранимок на управляемом языке только усугубляет вендор-лок.
Каким же образом? Написал модуль на java: хочешь запускай его на сервере приложений, хочешь внутри оракла, хочешь на своей локальной машине. Какой vendor-lock? Возникнет необходимость можно будет запустить на кофемолке или на кофемашине (шутка ).
S>Вот, этот форум — он как раз для архитекторов.
Вон он чё, а я думаю, откуда столько снобизма в ветке?
Здравствуйте, amironov79, Вы писали: S>>Все, кому интересно . A>Интересно это немногим.
Ну, я так думаю, что если опросить разработчиков оракле "знаете ли вы про java stored procedures", то 100% ответят "да".
Но я могу ошибаться. S>>В реальности написание хранимок на управляемом языке только усугубляет вендор-лок. A>Каким же образом? Написал модуль на java: хочешь запускай его на сервере приложений, хочешь внутри оракла, хочешь на своей локальной машине. Какой vendor-lock? Возникнет необходимость можно будет запустить на кофемолке или на кофемашине (шутка ).
Хорошо, вы меня убедили. Да, для Java всё не так плохо, как для CLR — перетащить Java-хранимку с Oracle на DB2, наверное, проще, чем хранимку на pl/sql.
S>>Вот, этот форум — он как раз для архитекторов. A>Вон он чё, а я думаю, откуда столько снобизма в ветке?
Да ну, какой снобизм, вы о чём???
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну, я так думаю, что если опросить разработчиков оракле "знаете ли вы про java stored procedures", то 100% ответят "да". S>Но я могу ошибаться.
Одно дело знать, другое дело использовать. Используют их в крайних случаях, когда на plsql в принципе нельзя реализовать задачу.
S>Хорошо, вы меня убедили. Да, для Java всё не так плохо, как для CLR — перетащить Java-хранимку с Oracle на DB2, наверное, проще, чем хранимку на pl/sql.
А с clr какие проблемы? Был бы рантайм, а расширение при желании приделают. Для того же оракла под виндовс есть возможность писать на c#.
S>Да ну, какой снобизм, вы о чём???
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Serginio1, Вы писали:
C>>>А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать. S>> Ну вот представь объемы данных для передчи на клиента. S>>Ты на трафике сдохнешь. C>Если его супермного, то проблемы будут и у хранимок.
Ну это понятно. Здесь главное не тащить на клиент всю базу.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, amironov79, Вы писали:
A>А с clr какие проблемы? Был бы рантайм, а расширение при желании приделают.
Ну, для CLR надо как-то обеспечить коду наличие SqlContext. Я вот сходу не возьмусь его добавить, скажем, в Oracle или DB2. A>АДля того же оракла под виндовс есть возможность писать на c#.
Ага. Возможность-то есть; но портировать код существующего Database Project для SQL Server в эту "возможность" нереально.
Потому что ничего из SQL-server инфраструктуры там нет. Custom Data Types, Custom Aggregates — хренушки. CLR-триггер — никак. Table-Valued functions — увы.
С грехом пополам можно смигрировать только отдельные хранимки, которые не пользуются SqlContext.Pipe.
Проще уж SQL спортировать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ага. Возможность-то есть; но портировать код существующего Database Project для SQL Server в эту "возможность" нереально. S>Потому что ничего из SQL-server инфраструктуры там нет. Custom Data Types, Custom Aggregates — хренушки. CLR-триггер — никак. Table-Valued functions — увы.
S>С грехом пополам можно смигрировать только отдельные хранимки, которые не пользуются SqlContext.Pipe. S>Проще уж SQL спортировать.
Ну и смысл, так глубоко закапываться. Неужели, все это дает значимый прирост производительности? Даже, если и дает, то в простоте мы точно теряем.
Здравствуйте, amironov79, Вы писали:
A>Ну и смысл, так глубоко закапываться. Неужели, все это дает значимый прирост производительности? Даже, если и дает, то в простоте мы точно теряем.
Конечно даёт. Простота — это вообще что?
Решает не простота, а maintainability кода.
Тут, к сожалению, конь не валялся.
CLR добавили в SQL Server 15 лет назад. Ещё до генериков.
Логично было бы перепилить весь тот ужас на современные технологии, ну или хотя бы добавить нормальные контракты, оставив поддержку старых для совместимости — но нет, увы...
Я уж не говорю про то, что надо бы по хорошему добавить поддержку linq и всего современного инструментария в CLR-код, исполняемый в сервере.
Нет — zero progress. Увы. Не взлетает.
Опять же, есть подозрение, что это не смогли вкрутить в SQL Azure, и негласно хотят эту враждебную технологию закопать.
Гораздо выгоднее продать клиенту Azure SQL, чем дать ему решить проблему на уже купленном SQL Server Enterprise Perpetual License.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sharov, Вы писали:
C>>Перекладывание на БД логики. По идее, её там вообще не должно быть. S>Почему, если это не сильно нагурженное приложение, паркуа па? Для нагруженных лучше все гнать на клиента ибо их много.
Чисто для того, чтобы ограничить количество мест, где есть бизнес-логика.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
C>>>Перекладывание на БД логики. По идее, её там вообще не должно быть. S>>Почему, если это не сильно нагурженное приложение, паркуа па? Для нагруженных лучше все гнать на клиента ибо их много. C>Чисто для того, чтобы ограничить количество мест, где есть бизнес-логика.
Таких мест всего два и, вероятно, развитием и поддержкой будут заниматься разные люди. Или нет. В любом случае криминала немного.
Здравствуйте, Cyberax, Вы писали:
C>Чтобы не было "регэкспа" в БД.
А смысл?
C>Да. В обоих случаях "регэксп" будет обрабатывать ровно одинаковый объём.
Да, но этот объём обрабатывается в разных местах. Так-то можно и клиенту все данные на каждый чих отдавать — пусть ворочает локально.
S>>Это странная идея. Ну, то есть идеи-то могут быть любыми, но разработка — она же для людей и преследуемых людьми практических целей, а не для идей. Поэтому "идеи" обсуждать смысла нет. C>Это не странная идея совершенно. Более того, по факту это сейчас то, что происходит в индустрии — она уходит от SQL и логики в БД в сторону использования БД как тупого хранилища, с которым легко работать из языков более высокого уровня.
Вы считаете, что это хорошо?
C>Не шучу. SQL — это уродство хуже PHP.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Конечно даёт. Простота — это вообще что? S>Решает не простота, а maintainability кода.
А maintainability это что? Чем проще код, тем лучше maintainability.
S>Тут, к сожалению, конь не валялся. S>CLR добавили в SQL Server 15 лет назад. Ещё до генериков. S>Логично было бы перепилить весь тот ужас на современные технологии, ну или хотя бы добавить нормальные контракты, оставив поддержку старых для совместимости — но нет, увы... S>Я уж не говорю про то, что надо бы по хорошему добавить поддержку linq и всего современного инструментария в CLR-код, исполняемый в сервере.
Вот, про что и разговор: неудобная обвязка, ограничение по версии рантайма, по версии языка. Думаю, есть проблемы, если сборка использует нативный код или кодогенерацию. И зачем все это? На сервере приложений ты свободен в выборе. Можно при необходимости с каждым приложением свой рантайм таскать, любая библиотека с nuget в твоем распоряжении, инструментальная поддержка близка к идеальной. Да, если будут проблемы с выборкой данных, всегда есть простор для оптимизации, хочешь средствами базы, хочешь кэшированием, хочешь избыточностью данных, хочешь расширением канала между сервером приложения и базы .
Здравствуйте, amironov79, Вы писали:
A>А maintainability это что? Чем проще код, тем лучше maintainability.
Смотря что включать в понятие "код".
Например, linq2db — адски сложен по сравнению с прямым использованием ADO.NET.
Там под капотом такое, что шуба заворачивается.
Когда в C# завозили linq, многие скептики выступали в том же ключе: дескать, там "хрен пойми, что происходит", "мало того, что надо знать SQL, так теперь надо ещё и знать, во что вся эта порнография развернётся", и "да я проще руками все эти джойны напишу".
При этом маинтейнить приложение, использующее linq2db, в разы проще, чем традиционные для начала 2000х DAL и CRUD-хранимки.
A>Вот, про что и разговор: неудобная обвязка, ограничение по версии рантайма, по версии языка. Думаю, есть проблемы, если сборка использует нативный код или кодогенерацию. И зачем все это?
Для того, чтобы ваше приложение обошло конкурентов
A>На сервере приложений ты свободен в выборе. Можно при необходимости с каждым приложением свой рантайм таскать, любая библиотека с nuget в твоем распоряжении, инструментальная поддержка близка к идеальной. Да, если будут проблемы с выборкой данных, всегда есть простор для оптимизации, хочешь средствами базы, хочешь кэшированием, хочешь избыточностью данных, хочешь расширением канала между сервером приложения и базы .
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
A>>А maintainability это что? Чем проще код, тем лучше maintainability. S>Смотря что включать в понятие "код". S>Например, linq2db — адски сложен по сравнению с прямым использованием ADO.NET. S>Там под капотом такое, что шуба заворачивается. S>Когда в C# завозили linq, многие скептики выступали в том же ключе: дескать, там "хрен пойми, что происходит", "мало того, что надо знать SQL, так теперь надо ещё и знать, во что вся эта порнография развернётся", и "да я проще руками все эти джойны напишу". S>При этом маинтейнить приложение, использующее linq2db, в разы проще, чем традиционные для начала 2000х DAL и CRUD-хранимки.
Да, я имею в виду именно использование. Какой смысл программисту, решающему бизнес-задачу, лезть в исходники linq2db? Только если что-то пойдет не так. Также программисты на plsql/tsql в потроха субд не лезут. Кстати, а linq2db или dapper можно подключить к базе?
A>>Вот, про что и разговор: неудобная обвязка, ограничение по версии рантайма, по версии языка. Думаю, есть проблемы, если сборка использует нативный код или кодогенерацию. И зачем все это? S>Для того, чтобы ваше приложение обошло конкурентов
Каким образом? Вы заставляете пользователя покупать sql server, а у него уже может быть есть корпоративный сервер с oracle, или он не прочь на postgres посидеть, или ему для дома вообще sqlite достаточно.
Здравствуйте, Sinclair, Вы писали:
S>Что значит "подключить к базе"?
Использовать их в clr stored procedures.
S>А для реальных случаев с существенной нагрузкой покупка SQL сервера — только часть решения. Если решение X потребует лицензирования четырёх железок с Oracle, а решение Y — лицензирования одной железки с MS SQL, то заказчик запросто слюнями наплюёт на то, что у него "уже есть корпоративный сервер с oracle".
Я никогда не поверю, что использование хранимок позволит сократить количество серверов в 4 раза. Проблема там будет в чем-то другом. А корпоративный сервер он уже есть, куплен, персонал знает как его обслуживать, админы на mssql криво смотрят.
S>И наоборот. S>И вообще, я наблюдал случаи, когда клиент говорит "ок, да ставьте уже что вам удобно" и переезжает с винды/mssql на линукс/постгрес потому, что его не устраивает ждать апдейтов вдвое дольше, чем всем остальным. S>Ожидание получается не из каких-то особенных свойств MS SQL, а из того, что 90% partner base сидит на линуксах, и, естественно, для них апдейты выпускаются в первую очередь. S>А начиналось-то всё как раз из ваших соображений: не заставлять же партнёра предоставлять окружение по нашему выбору; давайте мы лучше прогнёмся под него.
Ничего не понял. Так завязываемся на mssql или postgres?
Здравствуйте, amironov79, Вы писали: A>Использовать их в clr stored procedures.
Теоретически — ничто не мешает. Там же примерно то же, что и в оракле — доступ к самой базе через специальную строку подключения; остальная часть вроде бы та же, что и в обычном коде.
Меня больше беспокоить как грамотно завернуть то, что построено при помощи linq2sql в SqlPipe.
Ну, или как оформить TVF на основе linq2db.
A>Я никогда не поверю, что использование хранимок позволит сократить количество серверов в 4 раза.
Всякое бывает. Бывает, что ничего не меняется, а бывает, что раджакумаровский код на модной жаве, который вытаскивает в апп.сервер полбазы на каждый чих, требует четырёх железок под ферму апп-сервера плюс удвоенное железо для базы, а нормальный код, который обрабатывает данные там, где они лежат, обходится одним апп-сервером плюс один сервер БД. A>Проблема там будет в чем-то другом. А корпоративный сервер он уже есть, куплен, персонал знает как его обслуживать, админы на mssql криво смотрят.
Вот это вот иллюзия. Я ж говорю — сам всю жизнь так думал, а потом посмотрел, как в реальности заказчики говорят "админы — на зарплате. Либо выучат, либо заменим".
Кого там волнует мнение специалиста с зарплатой в $3000, когда обсуждается вопрос "миграции в клауд" со стоимостью под $200k, плюс TCO в пару десятков килобаксов в месяц.
Но, повторюсь — всякое бывает. Хороший специалист должен при обсуждении таких вопросов говорить не "логика в базе — это ужас-ужас", и не "ой, у вас же уже есть сервер на оракле", а что-типа "ну ок, вот это вам будет стоить X сейчас, но экономить Y в месяц". Ну, либо наоборот — сэкономите X сейчас, а потом заплатите Y, но уже ежемесячно". Или "давайте так взлетим, а по мере роста нагрузки я знаю, как перетащить IO/bound в базу надёжным способом, CPU-bound мы запустим на ферме в качестве фоновой работы, а Network-bound мы зарулим при помощи кэширования на reverse-proxy. Не беспокойтесь, к моменту, когда вам это понадобится, вы сможете бросать в меня деньгами".
A>Ничего не понял. Так завязываемся на mssql или postgres?
Завязываемся на что-то одно, вместо иллюзии "щас мы сделаем приложение, которое будет работать на любой платформе и СУБД по выбору заказчика".
Или вот ещё смешной факт: один из модулей, которыми я занимаюсь, требует свою собственную реляционную базу. Начиналось всё с того самого sqlite, и табличек (guid id, varchar(max) jsondata).
Ну, это когда у всех кастомеров всех реселлеров всех партнёров вместе взятых, было на всех 2 (два) конечных пользователя, работало нормально.
Постепенно sqlite устраивать перестал, зато схема более-менее стабилизировалась.
Переписали это дело на mssql. Миграция базы самого большого партнёра (~50000 пользователей) заняла, емнип, 40 секунд.
Но дело не в этом. Дело в том, что мы как-то стеснялись внезапно поднимать требования в апдейте — типа вчера всё работало бесплатно, а сегодня вынь да полож настоящий MS SQL.
Ок, запилили в инсталляцию по умолчанию localDB — он бесплатный, и к ресурсам непрожорлив.
В реальности, кстати, на полумиллионе пользователей наша штука нагрузки на СУБД практически не создаёт. Там банальные данные типа лицензии/подписки/пользователи, никакой там новомодной бигдаты или машин-лёрнинга.
Так вот: партнёры потихонечку начали приходить к нам с вопросами типа "а давайте мы это как-то перевезём на настоящие большие SQL Server-а".
Ну, мы-то что: там файл скопировать да приаттачить; перевозите!
А они такие: "а вам точно надо SQL Server Express? Можно мы это на Enterprise запустим?"
Ну, то есть нет такой проблемы у них, как поставить пару машин с SQL Server. И стоимость Enterprise лицензии их ничуть не пугает.
И да — это всё те же люди, которые эксплуатируют основную платформу, к которой мы — плагин, на жаве/постгре/линухе. То есть это не так, что у них там стоял единственный корпоративный MS SQL, купленный ещё на инвестиции первого раунда в 2001, и они хотят все приложения туда перевезти.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Теоретически — ничто не мешает. Там же примерно то же, что и в оракле — доступ к самой базе через специальную строку подключения; остальная часть вроде бы та же, что и в обычном коде.
Мешают требования безопасности. Если разработчику бизнес-логики дать рефлекшен и кодогенерацию, то это как дать ему ключи от сервера. Или там рефлекшена нет, или на каждый чих надо выдавать права.
S>Постепенно sqlite устраивать перестал, зато схема более-менее стабилизировалась.
S>Переписали это дело на mssql. Миграция базы самого большого партнёра (~50000 пользователей) заняла, емнип, 40 секунд.
Либо у вас там какое-то супер железо, либо данных кот наплакал.
Здравствуйте, Sinclair, Вы писали:
C>>Чтобы не было "регэкспа" в БД. S>А смысл?
Логика в одном месте, управляемая и версируемая в одной VCS, и т.д.
C>>Да. В обоих случаях "регэксп" будет обрабатывать ровно одинаковый объём. S>Да, но этот объём обрабатывается в разных местах.
Это уже не так критично как раньше. Особенно учитывая, что диски нынче тоже через сеть работают.
S>Так-то можно и клиенту все данные на каждый чих отдавать — пусть ворочает локально.
Не совсем. У РСУБД есть индексы, которые позволяют ограничивать объём данных.
По-хорошему, API БД должен представлять из себя что-то типа ленивых списков, которые можно пересекать или ограничивать по построенным индексам.
C>>Это не странная идея совершенно. Более того, по факту это сейчас то, что происходит в индустрии — она уходит от SQL и логики в БД в сторону использования БД как тупого хранилища, с которым легко работать из языков более высокого уровня. S>Вы считаете, что это хорошо?
Да. SQL провалился как язык для работы с данными. Он само-ограничился областями, где не нужна высокая производительность и большие объёмы данных.
Здравствуйте, amironov79, Вы писали: A>Мешают требования безопасности. Если разработчику бизнес-логики дать рефлекшен и кодогенерацию, то это как дать ему ключи от сервера. Или там рефлекшена нет, или на каждый чих надо выдавать права.
Ну, если честно, то это — надуманная проблема. У разработчика бизнес-логики и так есть доступ до более-менее всего. С учётом того, что он может инжектить в код произвольный SQL, который исполняется под правами "сервис-аккаунта", то что он такого не может сделать с базой, что мог бы при помощи кодогенерации? A>Либо у вас там какое-то супер железо, либо данных кот наплакал.
Нет, простое, обычное современное железо. О том и речь, что обычные бизнес-задачи, которые зарабатывают единицы миллионов долларов в год, прекрасно отрабатывают за скромные времена.
Ну, то есть можно, конечно, и такие задачи сделать через подъём всего подряд в память апп сервера, а потом реализовать отложенное исполнение на MQ-решениях, чтобы на каждую строчку происходил новый запуск джава-машины, и тогда апгрейд будет сутки бегать. Зато ентерпрайз, зато кластеры, зато паттерны, зато все при деле.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
C>Логика в одном месте, управляемая и версируемая в одной VCS, и т.д.
Этот вопрос ортогонален месту исполнения кода. Обеспечение согласованного развёртывания базы и апп-сервера — да, это серъёзный вопрос; но средства для его решения существуют.
Нет смысла пытаться избегать этого вопроса — всё равно вместе с эволюцией кода эволюционирует и схема; если ваши инструментальные средства могут просохатить изменение кода в "хранимке", то они с тем же успехом просохатят и изменение структуры таблиц.
C>Это уже не так критично как раньше. Особенно учитывая, что диски нынче тоже через сеть работают.
Ну, может быть, вы и правы. Но что-то меня берут обоснованные сомнения. Не верю я в то, что блочный доступ через сеть используется в построении реальных промышленных СУБД-решений.
C>Не совсем. У РСУБД есть индексы, которые позволяют ограничивать объём данных.
Ну так индексы-то тоже в каком-то смысле "логика". Просто к ней вы привыкли, и надёжность индексов такова, что никто в здравом уме не рассматривает сценарий "а что, если СУБД забудет проапдейтить индекс".
C>По-хорошему, API БД должен представлять из себя что-то типа ленивых списков, которые можно пересекать или ограничивать по построенным индексам.
Отож. Вопрос только в том, что мы считаем "встроенным индексом", и что он должен уметь в рамках "пересечения или ограничения". C>Да. SQL провалился как язык для работы с данными. Он само-ограничился областями, где не нужна высокая производительность и большие объёмы данных.
Ну, вам виднее.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну, если честно, то это — надуманная проблема. У разработчика бизнес-логики и так есть доступ до более-менее всего. С учётом того, что он может инжектить в код произвольный SQL, который исполняется под правами "сервис-аккаунта", то что он такого не может сделать с базой, что мог бы при помощи кодогенерации?
Может выйти за пределы сервера базы в систему: работать с файлами, запускать процессы с правами системного пользователя, под которым работает субд. Думаю, там есть система прав доступа, которую надо настраивать. В том же oracle для работы с java надо гонять приложение и смотреть, какие права требуются, вплоть до разрешения подключиться к любому удаленному узлу:
Здравствуйте, Sinclair, Вы писали:
C>>Логика в одном месте, управляемая и версируемая в одной VCS, и т.д. S>Этот вопрос ортогонален месту исполнения кода. Обеспечение согласованного развёртывания базы и апп-сервера — да, это серъёзный вопрос; но средства для его решения существуют.
И все они кривые.
S>Нет смысла пытаться избегать этого вопроса — всё равно вместе с эволюцией кода эволюционирует и схема; если ваши инструментальные средства могут просохатить изменение кода в "хранимке", то они с тем же успехом просохатят и изменение структуры таблиц.
В некоторой степени, да.
C>>Это уже не так критично как раньше. Особенно учитывая, что диски нынче тоже через сеть работают. S>Ну, может быть, вы и правы. Но что-то меня берут обоснованные сомнения. Не верю я в то, что блочный доступ через сеть используется в построении реальных промышленных СУБД-решений.
Я уже давно не видел решений, которые НЕ используют. Даже простейший EC2 и тот использует EBS, который работает через сеть.
C>>Не совсем. У РСУБД есть индексы, которые позволяют ограничивать объём данных. S>Ну так индексы-то тоже в каком-то смысле "логика". Просто к ней вы привыкли, и надёжность индексов такова, что никто в здравом уме не рассматривает сценарий "а что, если СУБД забудет проапдейтить индекс".
Индексы — это как-бы фундаментальная фича РСУБД. Без них они были бы бесполезны совсем.
C>>По-хорошему, API БД должен представлять из себя что-то типа ленивых списков, которые можно пересекать или ограничивать по построенным индексам. S>Отож. Вопрос только в том, что мы считаем "встроенным индексом", и что он должен уметь в рамках "пересечения или ограничения".
Только ограничения в рамках индексированных данных (+главный ключ).
Я понимаю, что в теории РСУБД должны уметь оптимизировать запросы, вычисляя идеальный порядок join'ов, но на практике для больших OLTP-систем это просто не применимо. Всё что требует сложных join'ов будет работать слишком медленно.
Построение оффлайновых отчётов и анализ данных — это вообще отдельный разговор. Там вообще ничего нормального пока не придумали, что с SQL, что без.
Здравствуйте, amironov79, Вы писали:
A>Может выйти за пределы сервера базы в систему: работать с файлами, запускать процессы с правами системного пользователя, под которым работает субд.
Совершенно не факт, что СУБД работает под какими-то более широкими правами, чем тот же самый апп-сервер.
Думаю, там есть система прав доступа, которую надо настраивать. В том же oracle для работы с java надо гонять приложение и смотреть, какие права требуются, вплоть до разрешения подключиться к любому удаленному узлу: A>
Ну да, конечно же там работает песочница — как и везде. Но ещё раз: что такого ценного вы видите на сервере СУБД, что более ценно, чем сама база данных?
Там самый главный файл — это собственно БД, только она денег и стоит. Человек, который может задеплоить произвольный код в сервер приложений, прекрасно дампнет вашу базу конкурентам безо всякой кодогенерации.
Основной риск — это code injection, когда злоумышленником выступает не программист, а внешний пользователь. Ну так опять же — drop table customers он вам заинжектит и через обычный DML, даже если прав на динамическое развёртывание кода у него нету.
Ну и опять же — тот же самый .jsp весь построен на том, что есть контейнер, который автоматически порождает .java по .jsp-разметке и компилирует её на лету. То есть у апп-сервера хватает прав на динамическое порождение кода; но это никого не пугает — ведь все пути порождения такого кода аккуратно закрыты: права "быренько создать bypasssecuritycheck.jsp" у самого jsp нету, поэтому обычной механики проверки прав на развёртывание вполне хватает.
Так и развёртывание встроенного в СУБД кода можно вынести из прикладного кода — когда .jsp означает не "java server page", а "java stored procedure", и вся эта ботва компилируется и развёртывается в БД контейнером, который полностью аналогичен резине или томкэту.
Основное препятствие тут — "это ещё не сделано"
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Somescout, Вы писали:
S>Чисто для корректировки: У меня получалось от менее 1 мс, до 5 мс. В среднем 3.
Стесняюсь спросить — это на соседней машине, или в пределах одной машины?
Сам давно уже не сидел с секундомером.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Чисто для корректировки: У меня получалось от менее 1 мс, до 5 мс. В среднем 3. S>Стесняюсь спросить — это на соседней машине, или в пределах одной машины? S>Сам давно уже не сидел с секундомером.
Разные сервера в одном здании.
Что интересно, я запускал тест на двух системах по разному подключённых к SQL-серверу (напрямую по 25Gbit ethernet, и по 1Gbit ethernet через роутер) — результаты +/- одинаковые. То есть сеть не сильно влияет на производительность таких запросов.
Здравствуйте, Sinclair, Вы писали:
A>>Может выйти за пределы сервера базы в систему: работать с файлами, запускать процессы с правами системного пользователя, под которым работает субд. S>Совершенно не факт, что СУБД работает под какими-то более широкими правами, чем тот же самый апп-сервер.
Здесь опять-таки вопрос разграниечения доступа. Под каким системным пользователем работает процесс, в котром иполняется процедура? Наверняка под каким-то пользователем, который имеет расширенные права с возможностью чтения всех data-файлов. В сервере же приложений разные модули могут работать под разными пользователями и даже на разных машинах.
S>Ну да, конечно же там работает песочница — как и везде. Но ещё раз: что такого ценного вы видите на сервере СУБД, что более ценно, чем сама база данных? S>Там самый главный файл — это собственно БД, только она денег и стоит. Человек, который может задеплоить произвольный код в сервер приложений, прекрасно дампнет вашу базу конкурентам безо всякой кодогенерации.
Баз может быть несколько, и не ко всем базам из субд будет доступ, и при правильном подходе бизнес-программист в базе далеко не админ.
S>Основной риск — это code injection, когда злоумышленником выступает не программист, а внешний пользователь. Ну так опять же — drop table customers он вам заинжектит и через обычный DML, даже если прав на динамическое развёртывание кода у него нету.
Это другое, здесь именно риск получения доступа на уровне операционной системы. Я, конечно, понимаю всякие системы прав, песочницы, домены, но настройка сильно усложяется, и можно, не заметив, выдать слишком много прав.
Здравствуйте, amironov79, Вы писали:
A>Здравствуйте, white_znake, Вы писали:
_>>Партицирование, шардирование вполне себе повышают масштабируемость бд. Другое дело, что масштабировать бд — это сложная задача. A>Это все про хранение данных, чем СУБД и должна заниматься. Вопрос же про код, то есть про сервер приложений, зачем его совать в СУБД?
Да, бизнес-правила должны выполняться в коде, данные должны обрабатываться в бд, но бизнес-правила тесно связаны с данными.
Потому многие делают валидацию бизнес-правил и обработку данных, необходимых для бизнес-правил, в коде на сервере, а потом, когда код на сервере начинает тормозить из-за обработки данных, то всю связку: валидацию бизнес правил + обработку данных необходимых для этого правила выносят в хранимку.
Потому что времени на правильный фикс — нет, ресурсов — нет.
А правильно — это переделывать одну модель на две модели: read & write. Что бы бизнес правила использовали read model.
Но это сложно сделать, потому что встают вопросы согласования моделей. А архитектура приложения под это не заточено.
Здравствуйте, Sinclair, Вы писали:
C>>Это уже не так критично как раньше. Особенно учитывая, что диски нынче тоже через сеть работают. S>Ну, может быть, вы и правы. Но что-то меня берут обоснованные сомнения. Не верю я в то, что блочный доступ через сеть используется в построении реальных промышленных СУБД-решений.
Вам выше пытаются вдуть в уши. Разумеется, диски работают через сеть, только сеть та — Fibre Channel или нечто подобное.
Здравствуйте, amironov79, Вы писали:
A>Здесь опять-таки вопрос разграниечения доступа. Под каким системным пользователем работает процесс, в котром иполняется процедура? Наверняка под каким-то пользователем, который имеет расширенные права с возможностью чтения всех data-файлов. В сервере же приложений разные модули могут работать под разными пользователями и даже на разных машинах.
И у java и у clr есть security context, который может запретить коду делать вообще всё, кроме вычислений. Далее, хранимка может исполняться под указанным пользователем БД.
A>Это другое, здесь именно риск получения доступа на уровне операционной системы. Я, конечно, понимаю всякие системы прав, песочницы, домены, но настройка сильно усложяется, и можно, не заметив, выдать слишком много прав.
A>Вот, например, просит приложение выдать ему: A>
A>dbms_java.grant_permission(user_name, 'SYS:java.lang.reflect.ReflectPermission', 'suppressAccessChecks', '');
A>
A>И как админу на это реагировать?
Знаете, у вас тут есть два малосочетаемых утверждения. Первое — что в конторе глупые или отупевшие от избытка работы админы, а второе — что по соседству с этими админами сидят чрезвычайно хитроумные программисты, которые пролезут через песочницу. Ситуация из каждого из этих утверждений может существовать в реальности, но не в одной конторе точно. Или — или. Это ведь не тред "как с помощью хранимок защититься от промышленного шпионажа".
Здравствуйте, Слава, Вы писали:
С>И у java и у clr есть security context, который может запретить коду делать вообще всё, кроме вычислений. Далее, хранимка может исполняться под указанным пользователем БД.
Ну и? Я ниже тоже самое и написал. Вы сможете это все настроить, и предвидеть последствия того или иного разрешения?
A>>Это другое, здесь именно риск получения доступа на уровне операционной системы. Я, конечно, понимаю всякие системы прав, песочницы, домены, но настройка сильно усложяется, и можно, не заметив, выдать слишком много прав.
A>>Вот, например, просит приложение выдать ему: A>>
A>>И как админу на это реагировать?
С>Знаете, у вас тут есть два малосочетаемых утверждения. Первое — что в конторе глупые или отупевшие от избытка работы админы, а второе — что по соседству с этими админами сидят чрезвычайно хитроумные программисты, которые пролезут через песочницу. Ситуация из каждого из этих утверждений может существовать в реальности, но не в одной конторе точно. Или — или. Это ведь не тред "как с помощью хранимок защититься от промышленного шпионажа".
Вопрос так не стоит. Вопрос следующий: как не открыть дыру с помощью хранимок?
Где я писал, что админы тупые? Наоборот, хороший админ сторонней организации пошлет вас лесом с подобными запросами. У него на сервере несколько баз, а тут вы такой красивый являетесь и говорите -- дай прав. Вы сможете его только административным ресурсом продавить. И зачем все это, если все тоже самое можно получить в приложении? Без всяких головоломок: собрали контейнер, установили, настроили, запустили. От базы только строка подключения нужна.
Здравствуйте, white_znake, Вы писали:
_>А правильно — это переделывать одну модель на две модели: read & write. Что бы бизнес правила использовали read model. _>Но это сложно сделать, потому что встают вопросы согласования моделей. А архитектура приложения под это не заточено.
То есть писать код в базе изначально -- это неправильно? Так про это и топик.
Здравствуйте, amironov79, Вы писали:
С>>И у java и у clr есть security context, который может запретить коду делать вообще всё, кроме вычислений. Далее, хранимка может исполняться под указанным пользователем БД.
A>Ну и? Я ниже тоже самое и написал. Вы сможете это все настроить, и предвидеть последствия того или иного разрешения?
Да, смогу. Другое дело, что я принципиально небыстро работаю. Безопасность в режиме "наговнякать ко вчера" не делается.
A>Где я писал, что админы тупые? Наоборот, хороший админ сторонней организации пошлет вас лесом с подобными запросами. У него на сервере несколько баз, а тут вы такой красивый являетесь и говорите -- дай прав. Вы сможете его только административным ресурсом продавить.
И хорошо бы продавить. А то получится, как в российском бизнеса "бухгалтерия не пускает". Да идут они нахер, организация работает не для бухгалтерии.
A>И зачем все это, если все тоже самое можно получить в приложении? Без всяких головоломок: собрали контейнер, установили, настроили, запустили. От базы только строка подключения нужна.
У меня вот есть встречный вопрос (той же степени осмысленности) — зачем писать на C# или Java, когда есть Хаскель?
Здравствуйте, Слава, Вы писали:
С>Да, смогу. Другое дело, что я принципиально небыстро работаю. Безопасность в режиме "наговнякать ко вчера" не делается.
А надо это сделать здесь и сейчас, чтобы приложение заработало. Потому как библиотеки, которые нормально работают в standalone режиме, начинают просить дикие разрешения, когда их загружают в базу. Сиди, читай, думай, дыра это разрешение или не дыра? Зачем это всё, когда в отдельном приложении такой проблемы просто нет?
A>>Где я писал, что админы тупые? Наоборот, хороший админ сторонней организации пошлет вас лесом с подобными запросами. У него на сервере несколько баз, а тут вы такой красивый являетесь и говорите -- дай прав. Вы сможете его только административным ресурсом продавить.
С>И хорошо бы продавить. А то получится, как в российском бизнеса "бухгалтерия не пускает". Да идут они нахер, организация работает не для бухгалтерии.
Причем здесь бухгалтерия? Админ отвечает за безопасность сервера, это его зона ответственности. С чего он должен пускать на сервер субд "какого-то хера с горы" со всякими извратными требованиями?
A>>И зачем все это, если все тоже самое можно получить в приложении? Без всяких головоломок: собрали контейнер, установили, настроили, запустили. От базы только строка подключения нужна.
С>У меня вот есть встречный вопрос (той же степени осмысленности) — зачем писать на C# или Java, когда есть Хаскель?
Если хотите, пишите на хаскеле. Если откинуть вопрос "зачем", то на сервере приложений это можно без проблем устроить, будет еще один сервис в отдельном контейнере.
Здравствуйте, amironov79, Вы писали:
A>Причем здесь бухгалтерия? Админ отвечает за безопасность сервера, это его зона ответственности. С чего он должен пускать на сервер субд "какого-то хера с горы" со всякими извратными требованиями?
При том, что главный бухгалтер может и сесть, а вот сидящих админов я ещё не видел, хотя сажать их не мешало бы, вместе с техлидами, ПМ'ами и прочими. Чтобы не слишком быстро бежали по пути прогресса.
Пусть на тестовом сервере это и отлаживает. На staging'е. Как это — нет staging? На внедорожник у директора деньги есть, а на staging — нету?
Здравствуйте, Слава, Вы писали:
A>>Причем здесь бухгалтерия? Админ отвечает за безопасность сервера, это его зона ответственности. С чего он должен пускать на сервер субд "какого-то хера с горы" со всякими извратными требованиями?
С>При том, что главный бухгалтер может и сесть, а вот сидящих админов я ещё не видел, хотя сажать их не мешало бы, вместе с техлидами, ПМ'ами и прочими. Чтобы не слишком быстро бежали по пути прогресса.
Нифига себе, до чего код в базе людей доводит. Теперь буду с опаской "PLSQL Developer" запускать...
Здравствуйте, amironov79, Вы писали:
A>Баз может быть несколько, и не ко всем базам из субд будет доступ, и при правильном подходе бизнес-программист в базе далеко не админ.
То же самое работает и для управляемого кода, исполняемого из-под СУБД.
A>Это другое, здесь именно риск получения доступа на уровне операционной системы. Я, конечно, понимаю всякие системы прав, песочницы, домены, но настройка сильно усложяется, и можно, не заметив, выдать слишком много прав.
A>Вот, например, просит приложение выдать ему: A>
A>dbms_java.grant_permission(user_name, 'SYS:java.lang.reflect.ReflectPermission', 'suppressAccessChecks', '');
A>
A>И как админу на это реагировать?
Да как обычно — есть же инструкции по развёртыванию. Просит — почему не дать? Оно же для чего-то нужно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Слава, Вы писали:
S>>Ну, может быть, вы и правы. Но что-то меня берут обоснованные сомнения. Не верю я в то, что блочный доступ через сеть используется в построении реальных промышленных СУБД-решений. С>Вам выше пытаются вдуть в уши. Разумеется, диски работают через сеть, только сеть та — Fibre Channel или нечто подобное.
Если брать AWS, то там везде обычный 10Gb Ethernet. FC сейчас практически совсем сдулся.
Здравствуйте, amironov79, Вы писали: A>Вопрос так не стоит. Вопрос следующий: как не открыть дыру с помощью хранимок?
В MS SQL хранимка исполняется под правами того пользователя, под которым авторизовано соединение к базе. Т.е. эскалировать привилегии не получится — не дураки писали.
Не знаю, как оно там в Оракле и DB2, но не думаю, что принципиально хуже.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
A>>Баз может быть несколько, и не ко всем базам из субд будет доступ, и при правильном подходе бизнес-программист в базе далеко не админ. S>То же самое работает и для управляемого кода, исполняемого из-под СУБД.
То же самое как где? Я про управляемый код в субд и говорю.
A>>Это другое, здесь именно риск получения доступа на уровне операционной системы. Я, конечно, понимаю всякие системы прав, песочницы, домены, но настройка сильно усложяется, и можно, не заметив, выдать слишком много прав.
A>>И как админу на это реагировать? S>Да как обычно — есть же инструкции по развёртыванию. Просит — почему не дать? Оно же для чего-то нужно.
Хороший подход, похож на: если какой-нибудь фонарик или компас просит читать смс на телефоне, почему не дать?
Здравствуйте, amironov79, Вы писали:
A>То же самое как где? Я про управляемый код в субд и говорю.
Всё то же самое, как и обычный SQL код в базе. При правильном подходе у этого кода далеко не админские права в базе.
S>>Да как обычно — есть же инструкции по развёртыванию. Просит — почему не дать? Оно же для чего-то нужно. A>Хороший подход, похож на: если какой-нибудь фонарик или компас просит читать смс на телефоне, почему не дать?
Эмм, я сам, конечно, к ДевоПсам не отношусь, но обычная практика очень простая: вместе с системой идёт инструкция по развёртыванию. И если в ней сказано "надо дать Global Admin права аккаунту х", то админ идёт и выдаёт.
Ну, кроме редких случаев, когда админ приходит к авторам системы с жалобой на то, что deployment guide противоречит их локальным правилам безопасности. Тогда вырабатывается консенсус — правятся либо правила, либо гайд. Либо код приложения подпиливается так, чтобы не требовать невозможного. Но это — прямо самое-самое редкое.
Поэтому, как бы смешно это ни звучало, но будет именно так: если CIO предложил всем сотрудникам поставить "фонарик", а CEO это решение утвердил, то всё — требует читать СМС, значит выдадим пермиссию.
Вот если потом окажется, что это решение имело последствия, то будут разматывать всю цепочку — и CIO, скорее всего, трахнут — за отсутствие due diligence при рассмотрении контракта.
Независимо от взыскания collateral damage с разработчика фонарика. Впрочем, где вы видели в новостях, чтобы разработчика софта нагнули за то, что его софт где-то порезвился?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, amironov79, Вы писали: A>Как это реализуется? Я не вижу в системе пользователей, которые есть в базе.
Ну, вообще-то рекомендованный способ работы — это integrated security.
Впрочем, если честно, я сам в этой теме плаваю. Году примерно в 2005м я разбирался с тем, как и что там устроено, но во-первых, это было давно и я не всё помню, а во-вторых это было давно и скорее всего поменялось
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, amironov79, Вы писали: A>>Использовать их в clr stored procedures. S>Теоретически — ничто не мешает. Там же примерно то же, что и в оракле — доступ к самой базе через специальную строку подключения; остальная часть вроде бы та же, что и в обычном коде.
в оракле все по другому все таки. там нет строки подключения, жаба процесс работает прямо в адресном пространстве субд, и на сколько помню есть синтаксис работы с курсором и соответственно жувать данные прямо из буферного кеша. без копирорвания в адресное пространство jvm.
но даже при такой эффективности не прижилось. сила жабы в либах и фреймворках. голая жава мало интересна, интересно было бы работать с гугло-тензорфлоу или со спрингом, но там такое обилие зависимостей, что хрен кто либо сможет чего-нить обрубком от той жава, что в субд собрешь.
Здравствуйте, Masterspline, Вы писали:
M>Offtop, конечно, но ты чё правда используешь машину без 8Г памяти?
M>Впрочем, с современной модой на ноутбуки это понятно.
Тоже оффтоп. А что, до сих пор много ноутбуков без 8Г?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Gt_, Вы писали:
Ops>>Тоже оффтоп. А что, до сих пор много ноутбуков без 8Г?
Gt_>у меня 3 intel nuc пристегнутых к телевизорам для ютуба и iptv, они с 4 гб шли по дефолту
Это не ноут, а весьма специфический нишевой девайс. У меня телек сам браузить умеет, но я без понятия, сколько в нем памяти, и зачем нужно в нем ходить по сайтам. Может если к нему пристегнуть хотя бы мышь, в браузере появится смысл, но я таким не страдал пока, а с пультом, и даже с приложением для смарта, браузер там лишь на самый крайний случай.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Gt_>>у меня 3 intel nuc пристегнутых к телевизорам для ютуба и iptv, они с 4 гб шли по дефолту
Ops>Это не ноут, а весьма специфический нишевой девайс. У меня телек сам браузить умеет, но я без понятия, сколько в нем памяти, и зачем нужно в нем ходить по сайтам. Может если к нему пристегнуть хотя бы мышь, в браузере появится смысл, но я таким не страдал пока, а с пультом, и даже с приложением для смарта, браузер там лишь на самый крайний случай.
не будет ничерта толком из телевизора работать. у меня и самсунги и lg — там по 1-2 гб памяти уже через пол года после покупки там толком уже ничерта не работало. а мне нравится лежа на кровати махать air мышой. но для этого дефолтных 4 гб мало.
Здравствуйте, Gt_, Вы писали:
Gt_>не будет ничерта толком из телевизора работать. у меня и самсунги и lg — там по 1-2 гб памяти уже через пол года после покупки там толком уже ничерта не работало. а мне нравится лежа на кровати махать air мышой. но для этого дефолтных 4 гб мало.
Ну вот у меня лыжа на WebOS, уже несколько лет как купил, все работает. Но мышой не машу, смотрю фильмы/сериалы, для этого обычного пульта даже много.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Gt_>>не будет ничерта толком из телевизора работать. у меня и самсунги и lg — там по 1-2 гб памяти уже через пол года после покупки там толком уже ничерта не работало. а мне нравится лежа на кровати махать air мышой. но для этого дефолтных 4 гб мало.
Ops>Ну вот у меня лыжа на WebOS, уже несколько лет как купил, все работает. Но мышой не машу, смотрю фильмы/сериалы, для этого обычного пульта даже много.
да, лет 8 назад я тоже так думал. смотрел в SD че дают в хрени типа мегого и был доволен. но теперь я хочу лежа на диване выбрать фильм из топа сайтика и оставить на закачку торенты и в том же положении бровсить, просматривать "смешной" спам что шлют друзья, со всяких фишки.нет
webos же че-то из 80х, работать может лишь одно приложение, понятия окна в принципе нет. есть экран с одной кастрированной прикладухой. причем ютуб кастрирован по самые гланды — даже коменты не почитать.
Здравствуйте, Gt_, Вы писали:
Gt_>да, лет 8 назад я тоже так думал. смотрел в SD че дают в хрени типа мегого и был доволен. но теперь я хочу лежа на диване выбрать фильм из топа сайтика и оставить на закачку торенты и в том же положении бровсить, просматривать "смешной" спам что шлют друзья, со всяких фишки.нет
Когда только купил, у всяких мегого только появлялся UHD контент, а FHD было полно. Но нет, я со своего DLNA в основном смотрю, у онлайновых не так много интересного мне контента, как хотелось бы.
Gt_>webos же че-то из 80х, работать может лишь одно приложение, понятия окна в принципе нет. есть экран с одной кастрированной прикладухой. причем ютуб кастрирован по самые гланды — даже коменты не почитать.
Вебос 3-я, которая у меня, вышла в 12 году.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Gt_>>webos же че-то из 80х, работать может лишь одно приложение, понятия окна в принципе нет. есть экран с одной кастрированной прикладухой. причем ютуб кастрирован по самые гланды — даже коменты не почитать.
Ops>Вебос 3-я, которая у меня, вышла в 12 году.
поздравляю с покупкой на алиэкспрес.
в lg webos лишь с 2015 года, но речь не о годе анонса, речь о технологиях. операционка умеющая запускать лишь одно приложение устарела в 80х.
Ops>Это ты вики поздравляй, они там информацию берут. Ну не думаешь же ты, что на телеке где-то написано, в каком году выпустили ОС?
в вики все верно расписано, лыжи с webos с 2014 года пошли.
вобщем нравится однопоточный кастрат, который даже ютуб коменты не показывает — пользуйте. мне удобней полноценный бровсер с 8гб и многопоточность.
Здравствуйте, Sinclair, Вы писали:
A>>Здесь вообще не понял про что речь. Статическая компиляция регулярки? S>Конечно. Вы же знали, что регулярку можно скомпилировать, а не интерпретировать?
В какой-нить p-код оно "компилируется" сейчас, т.е. всё-равно потом интерпретируется.
Помнится, ты резко возражал против компиляции в нейтив.
Здравствуйте, vdimas, Вы писали: V>В какой-нить p-код оно "компилируется" сейчас, т.е. всё-равно потом интерпретируется. V>Помнится, ты резко возражал против компиляции в нейтив.
Я резко возражал против необратимой AOT компиляции в нейтив. Так-то я обеими руками "за" — до тех пор, пока у нас сохраняется весь конвеер.
Т.е. компиляция и ре-компиляция происходит в рантайме, по мере появления данных о статистике исполнения и прочих полезностей.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>В какой-нить p-код оно "компилируется" сейчас, т.е. всё-равно потом интерпретируется. V>>Помнится, ты резко возражал против компиляции в нейтив. S>Я резко возражал против необратимой AOT компиляции в нейтив. Так-то я обеими руками "за" — до тех пор, пока у нас сохраняется весь конвеер. S>Т.е. компиляция и ре-компиляция происходит в рантайме, по мере появления данных о статистике исполнения и прочих полезностей.
Вообще-то я предлагал компилить всё м-но планов, если помнишь, а в рантайме уже лишь выбирать.
"Упаковка" всего разнообразия планов, когда оно делается АОТ, подчиняется логарифму от кол-ва всех планов, которые имеет смысл рассматривать (а не от всех возможных, и это тоже упоминалось, бо в рантайме тоже рассматриваются не все планы, многие эффективно отсекаются).
Из того обсуждения я вынес, что вы с Бодягиным не поняли, почему по логарифму-то, если в динамике в известных вам системах каждый план хранится базой независимо и есть целое направление телодвижений по конфигурированию кеша таких планов.
Здравствуйте, vdimas, Вы писали: V>Вообще-то я предлагал компилить всё м-но планов, если помнишь, а в рантайме уже лишь выбирать. V>"Упаковка" всего разнообразия планов, когда оно делается АОТ, подчиняется логарифму от кол-ва всех планов, которые имеет смысл рассматривать (а не от всех возможных, и это тоже упоминалось, бо в рантайме тоже рассматриваются не все планы, многие эффективно отсекаются).
V>Из того обсуждения я вынес, что вы с Бодягиным не поняли, почему по логарифму-то, если в динамике в известных вам системах каждый план хранится базой независимо и есть целое направление телодвижений по конфигурированию кеша таких планов.
В том обсуждении мы, как обычно и бывало, застряли на том, что на предложение прояснить конкретику кое-кто слился.
Поэтому да, мы так и не поняли, откуда берётся логарифм. У нас с Бодягиным возникло впечатление, что у нас с вами разное понимание термина "план".
В принципе, топик вроде бы ещё не заморожен — можно и вернуться к тому месту, на котором закончили.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, LaptevVV, Вы писали:
ЭФ>>Что же в этом хорошего? База данных — самое немасштабируемое место в системе. LVV>А ты читал Рефакторинг баз данных? LVV>Я — нет...
Там п1 удалить хранимки должно быть.
Здравствуйте, Cyberax, Вы писали:
C>Типичный пример — строка с автокомплитом, чтобы можно было по "ка ма 12" показывать вариант "ул. Карла Маркса, д. 123" из базы клиентов.
Ты предполагаешь поиск на клиенте делать? Т.е. базу всех адресов сперва на него отправить?
Я всегда такое на серверной стороне делал. В контексте обсуждения это не хранимка была, а на сервере приложений обрабатывалось после SQL запроса.
. 
