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

AP>Запись switch через оператор '?'. Зачем придумали switch он не нужен, ага?

Затем что switch в C# придумали хреново, не включая моск. Поэтому он не может быть выражением. Надо доделывать язык. Я с Мэдсом на эту тему говорил, он полностью согласен, и даже что то в этом направлении они уже ковыряли. Но это уже другая тема.

НС>>И в случае таких нарезок твой статический чекер идет лесом, так как запрос собирается динамически.
AP>Это ложь! Просто нет слов! После нескольких десятков постов выясняется, что ты ничего не понял. Просто ничего, ни капли. Даже не пытался понять.

Кто то что то там заливался про эмоции . Выключай истерику и включай моск.
Это — правда. Как только ты вместо своего творчества на тему query builder начнешь клеить строки, так твой статический анализатор сразу идет в лес. А если спецфункцию изобретать для свитча — так и для LINQ тоже можно добавить функцию, с сохранением всех пряников от наличия expression tree, в отличие от.

Здравствуйте, IT, Вы писали:
IT>Должно быть достаточно так

IT>

IT>private static IQueryable<Transaction> GetValues(IQueryable<Transaction> query, DateTime? dateTime)
IT>{
IT>    return query.Where(t => t.ShippedDate == dateTime);
IT>}
IT>

IT>linq провайдер должен сам разобраться и построить правильный SQL.
Спорно. Провайдер не должен умствовать в таких местах — иначе как я построю запрос "верни мне все накладные, где ShippedDate не задано"?

А вот раскрывать выражения на клиенте — можно:

private static IQueryable<Transaction> GetValues(IQueryable<Transaction> query, DateTime? dateTime)
{
    return query.Where(t => (t.ShippedDate == dateTime.Value || !dateTime.HasValue));
}

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

IT>>Тебе знаком такой термин — рефакторинг базы данных? Нет?
AP>Рефакторинг БД приходилось делать.

IT>>... предоставляют 100%-ный контроль над кодом, работающим с БД.
AP>Именно для этих целей и были сделаны методы CheckAllQueries и FindUsages(tableName, columnName=null). CheckAllQueries автоматически генерирует тесты для всех вариантов всех запросов (запуская их в режиме SchemaOnly).
Интересно. А как происходит генерация вариантов параметров запроса?
Как разруливаются ситуации с декомпозированными запросами, т.е. когда тело собирается кодом, расположенным в разных методах?
Как разруливаются ситуации с декомпозицией "поперёк" границы сборок?

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

S>Здравствуйте, IT, Вы писали:
IT>>Должно быть достаточно так

IT>>

IT>>private static IQueryable<Transaction> GetValues(IQueryable<Transaction> query, DateTime? dateTime)
IT>>{
IT>>    return query.Where(t => t.ShippedDate == dateTime);
IT>>}
IT>>

IT>>linq провайдер должен сам разобраться и построить правильный SQL.
S>Спорно. Провайдер не должен умствовать в таких местах — иначе как я построю запрос "верни мне все накладные, где ShippedDate не задано"?
linq2db такое генерит когда dateTime == null. Для EF нужно руками разные запросы на null и не-null делать.

S>А вот раскрывать выражения на клиенте — можно:
S>

S>private static IQueryable<Transaction> GetValues(IQueryable<Transaction> query, DateTime? dateTime)
S>{
S>    return query.Where(t => (t.ShippedDate == dateTime.Value || !dateTime.HasValue));
S>}
S>

В таком условии если dateTime==null, то запрос должен вернуть все записи.

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

S>Спорно. Провайдер не должен умствовать в таких местах — иначе как я построю запрос "верни мне все накладные, где ShippedDate не задано"?

Непонятна суть претензий. Так и построишь — передашь null в качестве значения dateTime. То что в сиквеле для сравнения с null требуются отделльные операторы — злобный и неисправимый косяк.

S>А вот раскрывать выражения на клиенте — можно:
S>

S>private static IQueryable<Transaction> GetValues(IQueryable<Transaction> query, DateTime? dateTime)
S>{
S>    return query.Where(t => (t.ShippedDate == dateTime.Value || !dateTime.HasValue));
S>}
S>

Чем это лучше "t => (t.ShippedDate == dateTime.Value || dateTime == null)"?

Здравствуйте, gandjustas, Вы писали:
G>В таком условии если dateTime==null, то запрос должен вернуть все записи.
А, виноват — неверно прочитал условие. Тут, конечно же, провайдер должен аккуратно обрабатывать такие ситуации.
Я, по привычке, ожидал стандартного where ShippedDate == @dateTime or @dateTime is null, который до сих пор плохо оптимизируется SQL-серверами.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Непонятна суть претензий. Так и построишь — передашь null в качестве значения dateTime. То что в сиквеле для сравнения с null требуются отделльные операторы — злобный и неисправимый косяк.
Перепутал задачи

S>>А вот раскрывать выражения на клиенте — можно:
S>>

S>>private static IQueryable<Transaction> GetValues(IQueryable<Transaction> query, DateTime? dateTime)
S>>{
S>>    return query.Where(t => (t.ShippedDate == dateTime.Value || !dateTime.HasValue));
S>>}
S>>

НС>Чем это лучше "t => (t.ShippedDate == dateTime.Value || dateTime == null)"?
Этого — ничем. Это лучше where t.ShippedDate = @dateTime or @dateTime is null в SQL, т.к. сиквел-сервер не занимается partial evaluation, constant propagation и прочими мелочами, привычными для обычных ЯП.

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

S>Я, по привычке, ожидал стандартного where ShippedDate == @dateTime or @dateTime is null, который до сих пор плохо оптимизируется SQL-серверами.

Так в этом, собственно, и был смысл примера — показать почему LINQ способен более эффективные запросы делать, нежели вьюшки или хранимки.

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


G>Насчет "путь в никуда" — очень даже ясно куда — EF7.
То что lightweight ORM, коим и должен быть EF7 путь в куда, твердили много лет назад. Но кто-то очень упертый отказывался признавать, что EF6 путь в никуда, и продолжал накручивать этого уродца с упорством достойным иного применения. Наконец-то уже и до разработчиков дошло (либо их просто сменили на адекватных)... Один ты, похоже, остался


G> Читаем пресс-релиз дальше:
Ну давай почитаем, тебе перевести?

G>

G>Upgrade from EF6 to EF7 is a key scenario for us, both in terms of existing code and existing knowledge. We’ll be keeping the same concepts and patterns wherever it makes sense. The upgrade to EF7 will require some changes to your code. Our aim is that code that uses the core functionality of the DbContext API will upgrade easily, code that makes use of the lower level APIs in EF may require more complicated changes.

"Конечно же переход на EF7 — это ключевой сценарий для нас. Поэтому мы постараемся сохранить ту же концепцию и паттерны, там где это имеет смысл. Переход, конечно же, потребует некоторых изменений в вашем коде. Наша задача, чтобы ваш код, который использует ключевую функциональность пострадал меньше всего..."
Таким образом, переводя с политкорректного на разговорный — ребята даже не планируют толком API сохранять. Прекрасный путь в куда — удачи товарищи! =)


G>Но я понимаю что все факты расходятся с твоей верой, поэтому ты ищешь проблемы в других.
Ты сам-то понял какие факты привел? =))

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

G>А ты что с чем сравниваешь? Мапить many-to-many никто кроме ef не умеет, поэтому даже сравнить не с чем...
Причем тут many2many? Это банальная связь один ко многим. Есть класс Order, который содержит набор товаров Product.
Отдельна жопа в том, что свойство Product обязательно должно быть ICollection<Product>, никаких тебе IEnumerable<> или Product[]. Хорошо хоть от virtual избавились, но не сильно спасает. Это все к вопросу о кривой концепции — когда EF делали, считали что LazyLoading это основной сценарий и все дизайнили под него, вот до сих пор хвосты и торчат.


G>Перепиши с промежуточной таблицей\классом проблем не будет, делает красивые inner join.
Не нужна здесь промежуточная таблица. На linq2SQL я могу сделать так:

 context.GetTable<Order>().GroupJoin(
 context.GetTable<Product>(), o => o.Id, p => p.OrderId,
 (o, p) => new Order
   {
    Id = o.Id,
    UserID = o.UserId,
    Products = p.ToArray()
   }).ToArray();

Или вообще в лоб:

 context.GetTable<Order>().Select(
   new Order
   {
    Id = o.Id,
    UserID = o.UserId,
    Products = context.GetTable<Product>().Where(p=>p.OrderId==o.Id).ToArray()
   }).ToArray();

И в обоих случаях будет один и тот же SQL запрос, в два раза эффективнее чем в EF, просто потому что там не будет дополнительного искуственного столбца и сортировки по нему.
И, что характерно, никаких ограничений на POCO классы — ему совершенно пофиг на что мапить, лишь бы тип подходящий был.
А EF так не умеет — не позволяет его хитропридуманная модель. Все запрос в таком стиле генерят исключение о невозможности построить linq выражение — что логично, нельзя править напрямую значения классов в обход внутренней модели. Конечно пользователь ее не видит, но палки в колеса она ставит на каждом шагу.
И это инструмент, который "идеально решает задачи для которых он делался"? Не смеши меня.

G>По странному стечению обстоятельств именно эта кривая архитектура\идеология позволяет мапить many-to-many
Многие ко многим мне нужно раз в год, по обещанию, как-нибудь ручками напишу. А вот запросы с left join у меня через один и если инструмент не может делать их эффективно, то он идет на свалку.
это к вопросу о "many seldom used features and capabilities in the code base that hamper performance and complicate development".

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

IB>Или вообще в лоб:
IB>

IB> context.GetTable<Order>().Select(
IB>   new Order
IB>   {
IB>    Id = o.Id,
IB>    UserID = o.UserId,
IB>    Products = context.GetTable<Product>().Where(p=>p.OrderId==o.Id).ToArray()
IB>   }).ToArray();
IB>

IB>И в обоих случаях будет один и тот же SQL запрос, в два раза эффективнее чем в EF, просто потому что там не будет дополнительного искуственного столбца и сортировки по нему.
Прикольно!
А можешь показать, какой SQL генерится в том и том случаях?

Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Так в этом, собственно, и был смысл примера — показать почему LINQ способен более эффективные запросы делать, нежели вьюшки или хранимки.
Да. По факту, есть всего три способа работы с "динамическими" запросами:
1. Кодируем всё в SQL. Нет такого запроса, который нельзя было бы выразить в терминах SQL:

select * from orders where (ShippedDate >= @shipDateFrom or @shipDateFrom is null) and (ShippedDate <= @shipDateTo or @shipDateTo is null)

1.а. Используем процедурное расширение SQL:

if (@shipDateFrom is null)
begin
  if (@shipDateTo is null)
    select * from orders
  else
    select * from orders where ShippedDate <= @shipDateTo
end
else begin
  if (@shipDateTo is null)
    select * from orders where ShippedDate >= @shipDateFrom
  else
    select * from orders where ShippedDate >= @shipDateFrom and ShippedDate <= @shipDateTo
end

2. Клеим строку динамически. Не очень важно — внутри SQL или снаружи:

q = 'select * from orders where 1=1 '
if (@shipDateFrom is not null)
  q = q + 'AND where ShippedDate >= @shipDateFrom '
if (@shipDateTo is null)
  q = q + 'AND ShippedDate <= @shipDateTo '
exec(q, @shipDateFrom, @shipDateTo);

3. Строим дерево запроса, и выполняем оптимизации. Либо вручную, либо автоматом (при помощи proven техник, хорошо известных из разработки компиляторов). SQL-Сервер этим не занимается, и слава байту — у него и так много работы; всю stateless работу лучше выносить за его пределы.

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>Ага, пошли ходить зигзагами. ))
V>>Рефакторинг работал.
НС>И как, можно было решарпером переименовать поле в БД?

А при чем здесь Linq и синхронизация кода и модели БД???

Тогда это было никак на любой технологии. Маппинг шел через атрибуты BLT, аргументы атрибутов — текст. Да и сейчас, если дата-контекст описывать руками, а не на живом соединении, то вовсе никак. Автоматический рефакторинг был только для кода. Если в поле менялось поле — то надо было обновить и маппинг.


V>>Всей разницы, что мы объекты проекций описывали явно, вместо автогенерирования компилятором анонимных типов.
НС>При чем тут анонимные типы и проекции? Банальное выражение фильтра foo.Bar > 4 ты как записывал?

прямо так и записывал, переопределенные операторы же ж...
потому что:

class FooMeta {
    Field<int> Bar { get; }
...
}

class Db {
    FooMeta Foo { get; }
}

Пояснения нужны?

V>>Конечно, наколотили свой аналог expression tree над выражениями SQL
НС>Да я уже давно все понял про твой трехколесный велосипед. И все проблемы этого велосипеда тоже прекрасно знаю.

Дык, модель автоматом генерилась. Опять же, спасибо "кишкам" BLT, которые экономили приличную часть работы даже для таких хелперов.
А проблемы таких велосипедов мы тоже прекрасно знаем, и? На тот момент это было лучшее решение из всевозможных виденных на дотнете.


НС>А нафига мне твои теоретические идеальные DBA, если и я и IT в реальных ситуациях видим совсем другое?

Почему идеальные? Обычные. Просто я в кач-ве DBA видел именно грамотных в этом деле людей. Но у нас как-то было без перегибов в сторону "разработка от базы". Т.е. не DBA разрабатывал базу, а ПМ выступал в роли аналитика, собирал инфу. Обсуждали командой вместе, вместе принимали решения по архитектуре на всех 3-х слоях. Т.е. программист БД знал, как данные идут на сервер приложений а от него — на десктопного клиента. Программист клиента знал, откуда берутся данные и что с ними в процессе доставки происходит. Но на стороне БД было оч много запрограммированного функционала, и оно было оправдано. По крайней мере на тех технологиях. Linq, положа руку на, еще в стадии становления. Провайдеры пока кривые и косые, низлежащее ADO тоже не блещет. Например, я лично баг отправлял в MS когда-то по парсеру MS SQL потока. Исправили потом в одном из SP.

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

Даже этот сайт, несложное, по-сути, приложение (это без попыток наезда) периодически выдаёт ошибки базы. А переспросишь страницу — всё ОК. Несерьезно. В банках и на бирже такое недопустимо принципиально. И я не говорю, что вы, программисты, в этом виноваты. Я как никто другой знаю, что нет. Вас можно обвинить только в том, что вы не навесили какие-нить костыли-воркараунды для этого случая, чтобы самостоятельно перезапросить построение страницы и отдать её, пусть на секунду позже, но без стыдливого окошка с сообщением об ошибке. Ну вот такова на сегодня надежность этих технологий, что тут сделаешь? Я почти сразу столкнулся с тем, что под нагрузкой ADO.Net периодически глюкало еще с самых первых версий. Блин, я такого даже вообразить не мог, когда пользовался ODBC или OLE DB, там надежность была железобетонная. Это же БАЗА, ёптить! )))


НС>>>NDA.
V>>Та ладно... Прям маленький кусочек нельзя показать?
НС>Там немаленький кусочек.

Зато участок кода с причиной тормозов обычно небольшой.


НС>>>Нет там рекурсии. От слова "совсем".
V>>Ну тогда пример нерелевантный, бо ты как аргумент решил привести чьи-то кривые руки. Нафига там были временные таблицы, тогда?

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

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


НС>А если там еще и пейджинг, да total к нему нужен ... Это ж до последней версии такого уродца надо было сочинять. А тут наклал все во времянку, а потом из нее нужную страничку и total выдернул.

Ну ты хоть понимаешь, кривизну какого уровня ты описываешь? Ну вот я что-то такое и предполагал.
Это как на C# создать/инициализировать миллион сложных объектов, а потом использовать парочку самых последних созданных. Как программист тот DBA был г-но, сорри за прямую речь. Наверно это был какой-то бывший админ без профильного образования. Те разрабы БД, с которыми я имел дело — обычные программисты-системотехники, которые волею случая постепенно осели в программизме SQL на оч многих и разных по архитектуре серваках. Даже средней руки программист не сотворит того, что ты описал. Ты описал примерно то же, что я часто вижу в скриптах — "лишь бы хоть как-то работало". Скрипты обычно тоже пишут те еще "программисты". ))


НС>Разный, да не совсем. Количество вариантов в реальности сильно ограничено. А если кто сочинил что то новое — ну будет при первом запросе компиляция, не смертельно.

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

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

S>А можешь показать, какой SQL генерится в том и том случаях?
Да все просто как рельс — нужно через left join выбрать одну большую простыню заказов и продуктов в заказах, а дальше в памяти разобрать по объектам.
Только EF, для своих внутренних нужд, еще вкрячивает дополнительный столбец типа CASE WHEN (Product.ID IS NULL) THEN CAST(NULL as int) ELSE 1 END as C1,
оборачивает это в еще один внешний запрос и сортирует результат — ORDER BY Order.Id ASC, C1 ASC
Стоимость этой операции увеличивает общую стоимость запроса больше чем в два раза. И есть у меня стойкое подозрение, что это упражнение EF проделывает с каждым left join-ом.

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

НС>>И как, можно было решарпером переименовать поле в БД?
V>А при чем здесь Linq и синхронизация кода и модели БД???

При чем тут синхронизация? Я переименовал поле в БД. Теперь мне надо переименовать это поле во всем прикладном коде. В случае LINQ типы БД интегрированы в язык, поэтому работает самый обыкновенный рефакторинг. А вот в случае склейки строк или твоих экзерсисов на тему query builder все намного печальнее.

V>А проблемы таких велосипедов мы тоже прекрасно знаем, и? На тот момент это было лучшее решение из всевозможных виденных на дотнете.

В контексте топика никого тот момент не волнует, к чему ты его приплел? Сейчас есть expression tree, поэтому всю это кривоватую хрень можно смело выкинуть.

НС>>А нафига мне твои теоретические идеальные DBA, если и я и IT в реальных ситуациях видим совсем другое?
V>Почему идеальные? Обычные.

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

V>В банках и на биржах тебе рассмеются в лицо, если ты им предложишь что-то на дотнете-Linq

Ты просто не в теме. IT, кстати, в отличие от тебя, последнее время в основном в финансово-банковской сфере работает. И вот, такое дело, его наблюдения почему то полностью совпадают с моими.

V>, для чего-то, где нужна хоть какая-то надежность.

О, программисты АЭС. Давненько их тут не появлялось.

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

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

V> Они почти всегда одни и те же, эти основные джоины.

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

V>Ну ты хоть понимаешь, кривизну какого уровня ты описываешь?

Это вот такая реальность и такие DBA.

НС>>Разный, да не совсем. Количество вариантов в реальности сильно ограничено. А если кто сочинил что то новое — ну будет при первом запросе компиляция, не смертельно.
V>Наверно у меня недостаточно инфы или мы не понимаем друг друга... Вот я делаю выборку с итогом по некоему товару, скажем, из довольно большой таблицы движений, и каждый раз запрашиваю итоги по другому товару, будет ли тут кеширование запроса, если это не хранимка с параметром или табличная ф-ия, а прямо в тексте подаваемого запроса фигурирует новое числовое некое ID товара?

А зачем прямо в тексте то? Параметры отменили что ли?

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

IB>Да все просто как рельс — нужно через left join выбрать одну большую простыню заказов и продуктов в заказах, а дальше в памяти разобрать по объектам.
IB>Только EF, для своих внутренних нужд, еще вкрячивает дополнительный столбец типа CASE WHEN (Product.ID IS NULL) THEN CAST(NULL as int) ELSE 1 END as C1,
IB>оборачивает это в еще один внешний запрос и сортирует результат — ORDER BY Order.Id ASC, C1 ASC
красавцы, чо.
IB>Стоимость этой операции увеличивает общую стоимость запроса больше чем в два раза. И есть у меня стойкое подозрение, что это упражнение EF проделывает с каждым left join-ом.
.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ну вот а обычных я имел возможность наблюдать в дикой природе с соответствующими выводами.
Меня всегда умиляют вот эти рассказы про мега-DBA. Примерно так же, как админы радуются выпадающим им окошкам типа "произошла непонятная ошибка, обратитесь к администратору". Ну, я — админ, мне к кому обращаться?
Это я к тому, что это у меня опыт работы с БД с 1991. Все рассказы про мегалогику в идеальных спроках, которые придумываются вместе с со специалистом в UX, и меинтейнятся потом с помощью "инструментов автоматической проверки" — городские легенды.
В жизни колонку с опечаткой типа ProdactCode держат в том же виде десятилетиями, ибо невозможно гарантировать корректность кода после переименования. Даже если бы существовал волшебный способ лёгким манием руки принудить перекомпиляцию всех хранимок в базе, это никак не поможет отловить dynamic SQL. А без Dynamic SQL невозможно написать сколь-нибудь сложный код — потому что средств декомпозиции в SQL никаких нету.
И чем больше размер проекта — тем хуже ситуация. Если в проектике на троих есть шанс, что хотя бы один из авторов держит в голове ~90% логики и представляет, что от чего зависит, то в проекте на 60 человек главная мантра — "работает — не трогай". Я занимался разгребанием результатов деятельности "профессиональных DBA", в том числе и себя же на пять лет младше.

И в итоге, на основании своего богатого жизненного опыта и глубокого понимания того, как работает SQL сервер, и, что ещё важнее — как он не работает, я считаю linq манной небесной. К сожалению, его мало кто хорошо готовит. Но принципиальная разница между ним и чем-угодно видна как раз опытному DBA, который в гробу видал мейнтенанс всех этих 2000 хранимок в БД. И это ещё если мы говорим про частный проектик, где все изменения контролируются командой разработчиков, у которых есть точные данные от DBA про статистику использования и конкретные размеры конкретных таблиц. Про коробочный продукт, который должен уметь обновляться в unattended режиме, и при этом корректно проглатывать все кастомизации, сделанные местным DBA, я вообще молчу.

А тут кругом ходят люди, которые явно SQL видели только в пересказе, и вещают мне про то, как я (как DBA) должен любить всю эту порнографию. Ха-Ха.

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

S> Даже если бы существовал волшебный способ лёгким манием руки принудить перекомпиляцию всех хранимок в базе...

Я опасаюсь вторых священных войн, но всё равно интересно: зачем вообще в 21 веке используют "хранимки"? Одни тут прогресс двигают, квадратики рисуют, MVC, MVVM и т.п., а другие шмякают эти "процедуры 20 века" и в ус не дуют! Что там такого "волшебного" делается, чего нельзя сделать на серверной стороне обычным кодом внутри "модели"?

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

B>Я опасаюсь вторых священных войн, но всё равно интересно: зачем вообще в 21 веке используют "хранимки"? Одни тут прогресс двигают, квадратики рисуют, MVC, MVVM и т.п., а другие шмякают эти "процедуры 20 века" и в ус не дуют! Что там такого "волшебного" делается, чего нельзя сделать на серверной стороне обычным кодом внутри "модели"?

Сегодня спроки нужны в основном для услады паранойки. Кому-то всё ещё кажется, что они работают быстрее, кто-то ими накрывает все таблицы, чтобы типа обеспечить сикьюрити.

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

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

S>> Даже если бы существовал волшебный способ лёгким манием руки принудить перекомпиляцию всех хранимок в базе...

B>Я опасаюсь вторых священных войн, но всё равно интересно: зачем вообще в 21 веке используют "хранимки"? Одни тут прогресс двигают, квадратики рисуют, MVC, MVVM и т.п., а другие шмякают эти "процедуры 20 века" и в ус не дуют! Что там такого "волшебного" делается, чего нельзя сделать на серверной стороне обычным кодом внутри "модели"?

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