Здравствуйте, 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>Перекладывание на БД логики. По идее, её там вообще не должно быть.

Почему, если это не сильно нагурженное приложение, паркуа па? Для нагруженных лучше все гнать на клиента ибо их много.

Здравствуйте, 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>Чисто для того, чтобы ограничить количество мест, где есть бизнес-логика.

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

Здравствуйте, Sinclair, Вы писали:

C>>Нет. Сначала применяем условия, которые не зависят от регэкспа, потом достаём выбираем пары ID-UserAddress, затем на стороне клиента фильтруем.
S>Ну, вот в предположении о том, что регекс отбирает только 10% записей, вы на ровном месте удесятеряете трафик между СУБД и апп-сервером. Зачем?
Чтобы не было "регэкспа" в БД.

C>>Всё ровно как в случае с ХП.
S>Нет. В случае с нормальной реализацией, в апп сервер сразу уезжает в 10 раз меньше данных, чем предлагаете вы.
Да. В обоих случаях "регэксп" будет обрабатывать ровно одинаковый объём.

C>>Использование видов и всяческих вычисляемых колонок — сушит моск и калечит архитектуру.
S>Точно — в трёхзвенку рано.
Нет, это как раз результат работы с недо-трехзвенкой, в которой логика размазана тонким слоем.

C>>Перекладывание на БД логики. По идее, её там вообще не должно быть.
S>Это странная идея. Ну, то есть идеи-то могут быть любыми, но разработка — она же для людей и преследуемых людьми практических целей, а не для идей. Поэтому "идеи" обсуждать смысла нет.
Это не странная идея совершенно. Более того, по факту это сейчас то, что происходит в индустрии — она уходит от SQL и логики в БД в сторону использования БД как тупого хранилища, с которым легко работать из языков более высокого уровня.

C>>Даже SQL, по сути, является ошибкой индустрии из-за того, что позволяет часть логики переносить в запросы. Крайне кривой язык, который не приспособлен нормально ни для оффлайновой аналитики, ни для онлайн-запросов.
S>Нет, всё-таки шутите. А я уж испугался )
Не шучу. SQL — это уродство хуже PHP.

Здравствуйте, Cyberax, Вы писали:

C>Чтобы не было "регэкспа" в БД.
А смысл?

C>Да. В обоих случаях "регэксп" будет обрабатывать ровно одинаковый объём.
Да, но этот объём обрабатывается в разных местах. Так-то можно и клиенту все данные на каждый чих отдавать — пусть ворочает локально.

S>>Это странная идея. Ну, то есть идеи-то могут быть любыми, но разработка — она же для людей и преследуемых людьми практических целей, а не для идей. Поэтому "идеи" обсуждать смысла нет.
C>Это не странная идея совершенно. Более того, по факту это сейчас то, что происходит в индустрии — она уходит от SQL и логики в БД в сторону использования БД как тупого хранилища, с которым легко работать из языков более высокого уровня.
Вы считаете, что это хорошо?

C>Не шучу. SQL — это уродство хуже PHP.

Здравствуйте, Sharov, Вы писали:
S>Таких мест всего два и, вероятно, развитием и поддержкой будут заниматься разные люди. Или нет. В любом случае криминала немного.
По факту — три.
Ограничения вроде (check constraint), NOT NULL, Foreign Key живут в БД, в апп.сервере, и на клиенте (JS).
В идеале всё это должно описываться в одном месте, а исполняться — там, где оптимально. Например, везде.

Здравствуйте, Sinclair, Вы писали:

S>Конечно даёт. Простота — это вообще что?
S>Решает не простота, а maintainability кода.

А maintainability это что? Чем проще код, тем лучше maintainability.

S>Тут, к сожалению, конь не валялся.
S>CLR добавили в SQL Server 15 лет назад. Ещё до генериков.
S>Логично было бы перепилить весь тот ужас на современные технологии, ну или хотя бы добавить нормальные контракты, оставив поддержку старых для совместимости — но нет, увы...
S>Я уж не говорю про то, что надо бы по хорошему добавить поддержку linq и всего современного инструментария в CLR-код, исполняемый в сервере.

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

Здравствуйте, Cyberax, Вы писали:

C>Не шучу. SQL — это уродство хуже PHP.

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

Здравствуйте, 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 достаточно.

Здравствуйте, 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, Вы писали:

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 секунд.

Либо у вас там какое-то супер железо, либо данных кот наплакал.