Здравствуйте, ·, Вы писали:
_>>>>Ну т.е. вот смотри, допустим мы пишем работу с БД на чистом sql, вообще без всяких дополнительных инструментов. Это же реально, правильно? ) Так вот подобную реализацию можно условно считать референсной, т.к. в нет вообще никакого оверхеда. _>>·>Реально в тривиальных случаях. _>>В каких ещё тривиальных случаях? ) Раньше вообще только так весь код писали и всё. ))) dot>Так раньше код на перфокартах писали... и что?
А то что на перфокартах сейчас если и пишут, то только в развлекательных/познавательных/исторических целях.
А вот sql-строчки до сих пор используются в реальных проектах — на том самом C#, и на том самом stackoverflow:
Здравствуйте, ·, Вы писали:
_>>В каких ещё тривиальных случаях? ) Раньше вообще только так весь код писали и всё. ))) ·>Так раньше код на перфокартах писали... и что?
Какие ещё перфокарты? ) До сих пор все веб-движки так и написаны. Загляни в любой и увидишь там эти самые sql строки. Правда в нормальных проектах они обычно отделены в специальный слой (DBAL), чтобы не быть привязанным к конкретной СУБД.
_>>В этой же темке обсуждался другой вопрос. Что в .net попытались создать некое подобное такой системы на базе задание запросов в виде linq выражений и разбора их потом в рантайме. Удобство и безопасность они при этом реализовать сумели, но только ценой большого оверхеда (т.е. кроме указанной выше склейки строк и параметров в рантайме делается ещё куча всего ненужного, типа обходов деревьев linq выражений через рефлексию и т.п.). Оценки этого оверхеда (те самые реальные замеры, которые ты хотел) можно увидеть в сообщения выше — там местами до 500% доходит. ))) ·>Там замеры были или корявые (ну кто меряет тест выполнения запросов, выполняя инструкцию 1 раз и сравнивая 10мс и 13мс?! и делая вывод — 146%!). Либо тормоза возникали из-за других фич. Измерение конкретно рефлексии или склейки строк не было. Или я что-то пропустил?
), т.к. там и с измерениями всё нормально и тест идеально подходящий (можно увидеть реализацию и на sql строках и на linq для одной и той же ORM).
Там с замерами лажа
Func<int> simpleEfDbContextCodeFirstTop10 = () =>
{
using (var ctx = new NorthwindEfDbContextCodeFirst())
{
var list =
(
from o in ctx.Orders
join c in ctx.Customers on o.CustomerID equals c.CustomerID
select new { o.OrderID, o.OrderDate, c.Country, c.CompanyName }
).Take(10).ToList();
return list.Count;
}
};
Кроме того такие запросы предварительно можно компилировать.
А можно и использовать тот SqlConnection для пакетных запросов или использовать специфические для каждой бд инструкции.
Мало того от версии к версии все меняется.
То есть есть огромная свобода. Но ты привязан только к скорости.
Еще раз основная доля учетных систем написана на 1С. Важна скорость и надежность разработки. Но тебе этого не понять. Ведь на С++ пишутся простые и понятные программы только для тебя.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ночной Смотрящий, Вы писали:
_>>>Вообще то в данном контекте речь шла о сравнение вариант на C# с linq vs вариант на C# с голыми sql строками. И в данном случае все тормоза от работы с linq тут являются чистым оверхедом. НС>>А теперь посмотрим на практику — http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html
_>Вот, отлично! Наконец то не просто отзывы профессионалов на форуме, а уже специальные замеры. И они полностью подтверждают мои слова. Даже более того, я конечно ожидал десятков процентов тормозов, но не 50% для лучшей реализации и 500% для худшей (однако более популярной). Естественно такие радикальные цифры наблюдаются только для быстрых запросов. В случае же тяжёлых запросов величина оверхеда относительно времени исполнения самого запроса естественно снижается, до соответственно 10% в лучшей реализации и 100% в худшей. Что всё равно очень много на мой взгляд.
_>P.S. Цифры для EF конечно же вообще шокирующие. ))) _>P.P.S. Теперь будет куда тыкать носом всяких умников, которые тут болтают про бред или просто молча минусы рисуют... )))
Вот давай как раз ум то и включим
Берем CodeFirst
Func<int> simpleEfDbContextCodeFirstTop500 = () =>
{
using (var ctx = new NorthwindEfDbContextCodeFirst())
{
var list =
(
from o in ctx.Orders
join c in ctx.Customers on o.CustomerID equals c.CustomerID
select new { o.OrderID, o.OrderDate, c.Country, c.CompanyName }
).Take(500).ToList();
return list.Count;
}
};
И ADO
Func<int> simpleAdoNetTop500 = () =>
{
int count = 0;
using (var con = new SqlConnection(connectionStringNorthwind))
{
con.Open();
var sql = @"
SELECT TOP 500 O.OrderID, O.OrderDate, C.Country, C.CompanyName
FROM Orders O
JOIN Customers C ON O.CustomerID = C.CustomerID
";
using (var cmd = new SqlCommand(sql, con))
{
using (var reader = cmd.ExecuteReader())
{
if (reader.HasRows)
{
var list = new List<SimpleQueryRow>();
while (reader.Read())
{
list.Add(new SimpleQueryRow
{
OrderId = reader.GetInt32(0),
OrderDate = reader.IsDBNull(1) ? null : (DateTime?)reader.GetDateTime(1),
Country = reader.IsDBNull(2) ? null : reader.GetString(2),
CompanyName = reader.IsDBNull(3) ? null : reader.GetString(3),
});
}
count = list.Count;
}
}
}
}
return count;
};
На этом описательная часть закончена, перейдём к самому вкусному.
Используя предка, можно написать обобщенную функцию.
public TEntity ПолучитьЭлементСправочника<TEntity>(string ID) where TEntity : СправочникПредок
{
var query2 = from спр in this.Set<TEntity>()
where спр.ID == ID
select спр;
return query2.SingleOrDefault<TEntity>();
}
Теперь мы можем вызвать её таким способом
public static СправочникПредок ПолучитьЗначениеНеопределенногоСправочника(string НеопределенныйИД)
{
var тип = НеопределенныйИД.Substring(0, 4);
var id = НеопределенныйИД.Substring(4, 9);
switch (тип)
{
case ВыдСправочника36.Аналоги:
return БД.ПолучитьЭлементСправочника<Справочник.Аналоги>(id);
case ВыдСправочника36.Банки:
return БД.ПолучитьЭлементСправочника<Справочник.Банки>(id);
При получении неопределенного справочника нам доступны все свойства и методы предка.
Следует отметить, что Linq возвращает не реальный объект, а прокси. То есть для того, что бы получить реальный тип нужно вызвать GetType().BaseType
А эта надстройка может реализовать изменения, биндинг итд, на что тоже тратится время.
Есть еще одна замечательная особенность — это использование переменных в запросе
Суть запроса такова. Сгруппируем единицы по владельцу, количество подчиненных которых превышает один элемент. Запрос будет выводить дерево по Владельцу, при этом в корне мы получаем агрегированные данные (Count())
var бд = Константы1С.ГлобальныйКонтекст.БД;
var qr = (from единица in бд.Спр_Единицы
group единица by new {
единица.ВладелецId,
Наименование=единица.Владелец.Наименование.TrimEnd()
}
into группа
let Количество = группа.Count()
where Количество > 1
selectnew
{
Наименование = группа.Key.Наименование,
Количество = Количество,
Группа = группа
});
foreach (var элем in qr)
{
// Console.WriteLine("{0}.{1} - ", элем.Наименование, элем.Количество);foreach (var единица in элем.Группа)
{
Console.WriteLine("{0}.{1} - ", единица.ОКЕИ.Наименование, единица.ШтрихКод);
}
}
Генерирует такой запрос
SELECT
[Project1].[C2] AS [C1],
[Project1].[C3] AS [C2],
[Project1].[C1] AS [C3],
[Project1].[PARENTEXT] AS [PARENTEXT],
[Project1].[C4] AS [C4],
[Project1].[ID] AS [ID],
[Project1].[PARENTEXT1] AS [PARENTEXT1],
[Project1].[ISMARK] AS [ISMARK],
[Project1].[SP79] AS [SP79],
[Project1].[SP76] AS [SP76],
[Project1].[SP78] AS [SP78],
[Project1].[SP80] AS [SP80],
[Project1].[SP8752] AS [SP8752],
[Project1].[SP9519] AS [SP9519]
FROM ( SELECT
[GroupBy1].[A1] AS [C1],
[GroupBy1].[K1] AS [PARENTEXT],
[GroupBy1].[K2] AS [C2],
[GroupBy1].[K3] AS [C3],
[Join2].[ID1] AS [ID],
[Join2].[PARENTEXT] AS [PARENTEXT1],
[Join2].[ISMARK1] AS [ISMARK],
[Join2].[SP79] AS [SP79],
[Join2].[SP76] AS [SP76],
[Join2].[SP78] AS [SP78],
[Join2].[SP80] AS [SP80],
[Join2].[SP8752] AS [SP8752],
[Join2].[SP9519] AS [SP9519],
CASE WHEN ([Join2].[ID1] IS NULL) THEN CAST(NULL AS int) ELSE 1 END AS [C4]
FROM (SELECT
[Join1].[K1] AS [K1],
[Join1].[K2] AS [K2],
[Join1].[K3] AS [K3],
COUNT([Join1].[A1]) AS [A1]
FROM ( SELECT
[Extent1].[PARENTEXT] AS [K1],
1 AS [K2],
RTRIM([Extent2].[DESCR]) AS [K3],
1 AS [A1]
FROM [dbo].[SC75] AS [Extent1]
INNER JOIN [dbo].[SC84] AS [Extent2] ON [Extent1].[PARENTEXT] = [Extent2].[ID]
) AS [Join1]
GROUP BY [K1], [K2], [K3] ) AS [GroupBy1]
LEFT OUTER JOIN (SELECT [Extent3].[ID] AS [ID1], [Extent3].[PARENTEXT] AS [PARENTEXT], [Extent3].[ISMARK] AS [ISMARK1], [Extent3].[SP79] AS [SP79], [Extent3].[SP76] AS [SP76], [Extent3].[SP78] AS [SP78], [Extent3].[SP80] AS [SP80], [Extent3].[SP8752] AS [SP8752], [Extent3].[SP9519] AS [SP9519], [Extent4].[DESCR] AS [DESCR]
FROM [dbo].[SC75] AS [Extent3]
INNER JOIN [dbo].[SC84] AS [Extent4] ON [Extent3].[PARENTEXT] = [Extent4].[ID] ) AS [Join2] ON ([GroupBy1].[K1] = [Join2].[PARENTEXT]) AND(([GroupBy1].[K3] =(RTRIM([Join2].[DESCR]))) OR(([GroupBy1].[K3] IS NULL) AND(RTRIM([Join2].[DESCR]) IS NULL)))
WHERE [GroupBy1].[A1] > 1
) AS [Project1]
ORDER BY [Project1].[C2] ASC, [Project1].[PARENTEXT] ASC, [Project1].[C3] ASC, [Project1].[C4] ASC
Это уже не просто склейка строк.
и солнце б утром не вставало, когда бы не было меня
Ну так это же только EF касается и всё. Для других измеренных инструментов ничего подобного не требуется. Более того, даже если говорить о EF, то там же можно увидеть сравнение EF в режиме linq и sql, в котором этот нюанс опять же не будет играть никакой роли.
S>Кроме того такие запросы предварительно можно компилировать. S>А можно и использовать тот SqlConnection для пакетных запросов или использовать специфические для каждой бд инструкции. S>Мало того от версии к версии все меняется. S>То есть есть огромная свобода. Но ты привязан только к скорости.
Свобода есть везде. Нужна не свобода, а готовый удобный инструмент. Если ты можешь продемонстрировать мне инструмент для .net, позволяющий удобно работать со статически типизированным sql без затормаживания (ну скажем накладные расходы не более нескольких процентов относительно варианта с голыми sql строками) системы, то это будет аргументом. А всё остальное — это пустая болтовня.
[Skip]
_>Свобода есть везде. Нужна не свобода, а готовый удобный инструмент. Если ты можешь продемонстрировать мне инструмент для .net, позволяющий удобно работать со статически типизированным sql без затормаживания (ну скажем накладные расходы не более нескольких процентов относительно варианта с голыми sql строками) системы, то это будет аргументом. А всё остальное — это пустая болтовня.
Именно, спорить с тобой бесполезно. Приципился с этой рефлексией, а бенефита так и не увидел, потому что уже упрежденно что-то для себя похоронил.
Удачи тебе в склейке строк.
), т.к. там и с измерениями всё нормально и тест идеально подходящий (можно увидеть реализацию и на sql строках и на linq для одной и той же ORM).
S>> Там с замерами лажа S>> Если хотим в равные условия то тогда и AsNoTrackig добавить. S>>http://www.c-sharpcorner.com/UploadFile/ff2f08/entity-framework-and-asnotracking/ S>>http://metanit.com/sharp/entityframework/4.8.php
_>Ну так это же только EF касается и всё. Для других измеренных инструментов ничего подобного не требуется. Более того, даже если говорить о EF, то там же можно увидеть сравнение EF в режиме linq и sql, в котором этот нюанс опять же не будет играть никакой роли.
Кто сказал? В режиме SQL тоже идет отображение. Никакой разницы нет. S>>Кроме того такие запросы предварительно можно компилировать. S>>А можно и использовать тот SqlConnection для пакетных запросов или использовать специфические для каждой бд инструкции. S>>Мало того от версии к версии все меняется. S>>То есть есть огромная свобода. Но ты привязан только к скорости.
_>Свобода есть везде. Нужна не свобода, а готовый удобный инструмент. Если ты можешь продемонстрировать мне инструмент для .net, позволяющий удобно работать со статически типизированным sql без затормаживания (ну скажем накладные расходы не более нескольких процентов относительно варианта с голыми sql строками) системы, то это будет аргументом. А всё остальное — это пустая болтовня.
Так вот твой инструмент не может строить динамических запросов в ран тайме. А это как правило основные запросы.
Сравниваем скорость разработки, в том числе и интерактивное изменение данных. Вот пока действительно ты даже инструмент не держал в руках, но осуждаешь.
Еще раз у большинства нет нареканий на скорость 1С. Главное скорость разработки и порог вхождения. А с оверхедами от версии к версии избавляются.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Danchik, Вы писали:
_>>Свобода есть везде. Нужна не свобода, а готовый удобный инструмент. Если ты можешь продемонстрировать мне инструмент для .net, позволяющий удобно работать со статически типизированным sql без затормаживания (ну скажем накладные расходы не более нескольких процентов относительно варианта с голыми sql строками) системы, то это будет аргументом. А всё остальное — это пустая болтовня. D>Именно, спорить с тобой бесполезно. Приципился с этой рефлексией, а бенефита так и не увидел, потому что уже упрежденно что-то для себя похоронил. D>Удачи тебе в склейке строк.
Здравствуйте, Serginio1, Вы писали:
_>>Ну так это же только EF касается и всё. Для других измеренных инструментов ничего подобного не требуется. Более того, даже если говорить о EF, то там же можно увидеть сравнение EF в режиме linq и sql, в котором этот нюанс опять же не будет играть никакой роли. S> Кто сказал? В режиме SQL тоже идет отображение. Никакой разницы нет.
Именно про это я и сказал. Т.е. раз отображение идёт везде, то вся разница между измерением EF с linq и EF с row sql идёт за счёт тормозов обработки linq. Можешь сам вычислить эту разницу по данным графикам. Да, и кстати... Если убрать тормоза от трекинга в EF, то в процентном отношение накладные расходы от linq будут выглядеть только хуже (т.к. они не изменятся, а общее время запроса уменьшится).
_>>Свобода есть везде. Нужна не свобода, а готовый удобный инструмент. Если ты можешь продемонстрировать мне инструмент для .net, позволяющий удобно работать со статически типизированным sql без затормаживания (ну скажем накладные расходы не более нескольких процентов относительно варианта с голыми sql строками) системы, то это будет аргументом. А всё остальное — это пустая болтовня. S> Так вот твой инструмент не может строить динамических запросов в ран тайме. А это как правило основные запросы.
Вообще то может (было бы смешно иначе, суметь сделать сложное и не суметь простое), хотя это и не часто необходимая функция.
S>Сравниваем скорость разработки, в том числе и интерактивное изменение данных. Вот пока действительно ты даже инструмент не держал в руках, но осуждаешь. S> Еще раз у большинства нет нареканий на скорость 1С. Главное скорость разработки и порог вхождения. А с оверхедами от версии к версии избавляются.
А причём тут вообще бухгалтерский софт, когда мы обсуждали высоконагруженные сервисы? ) Естественно, что на современных компьютерах одиночный запрос в БД не будет тормозить, даже если он генерируется на bash'e. ))) Но это не значит, что тебе удастся написать на bash'e сайт с нормальной посещаемостью.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Ну так это же только EF касается и всё. Для других измеренных инструментов ничего подобного не требуется. Более того, даже если говорить о EF, то там же можно увидеть сравнение EF в режиме linq и sql, в котором этот нюанс опять же не будет играть никакой роли. S>> Кто сказал? В режиме SQL тоже идет отображение. Никакой разницы нет.
_>Именно про это я и сказал. Т.е. раз отображение идёт везде, то вся разница между измерением EF с linq и EF с row sql идёт за счёт тормозов обработки linq. Можешь сам вычислить эту разницу по данным графикам. Да, и кстати... Если убрать тормоза от трекинга в EF, то в процентном отношение накладные расходы от linq будут выглядеть только хуже (т.к. они не изменятся, а общее время запроса уменьшится).
Там тоже идет парсинг текста . Посмотри статью http://infostart.ru/public/393228/
_>>>Свобода есть везде. Нужна не свобода, а готовый удобный инструмент. Если ты можешь продемонстрировать мне инструмент для .net, позволяющий удобно работать со статически типизированным sql без затормаживания (ну скажем накладные расходы не более нескольких процентов относительно варианта с голыми sql строками) системы, то это будет аргументом. А всё остальное — это пустая болтовня. S>> Так вот твой инструмент не может строить динамических запросов в ран тайме. А это как правило основные запросы.
_>Вообще то может (было бы смешно иначе, суметь сделать сложное и не суметь простое), хотя это и не часто необходимая функция.
На самом деле нужно в основном динамические запросы строить особенно интерактивные.
S>>Сравниваем скорость разработки, в том числе и интерактивное изменение данных. Вот пока действительно ты даже инструмент не держал в руках, но осуждаешь. S>> Еще раз у большинства нет нареканий на скорость 1С. Главное скорость разработки и порог вхождения. А с оверхедами от версии к версии избавляются.
_>А причём тут вообще бухгалтерский софт, когда мы обсуждали высоконагруженные сервисы? ) Естественно, что на современных компьютерах одиночный запрос в БД не будет тормозить, даже если он генерируется на bash'e. ))) Но это не значит, что тебе удастся написать на bash'e сайт с нормальной посещаемостью.
1С это не только бухгалтерия, но и 1С:ERP, производство где нагруженность большая.
То о чем ты говоришь это типа Гугла, то там и Linq не нужен. Linq нужен где нужно писать тонны кода. И вот здесь во главе угла уже скорость разработки.
Опять же если хочешь сравнивать, то нужно их сравнивать правильно, в том числе и на сложных запросах с группированием данных в иерархии.
Опять же отображения на объекты нужны для редактирования. Обычные запросы как правило возвращают ID,Наименование и прочие поля. Да там тоже идет отображение на аноноимные типы, но не нужно отслеживать кэши и изменения.
На самом деле прошу прощения. До конца не просмотрел запрос
select new { o.OrderID, o.OrderDate, c.Country, c.CompanyName }
).Take(500).ToList();
Здесь никакого поиска по Кэшам, так как возвращается анонимный класс. Но можно было бы сравнить с применением CompiledQuery.Compile
Здравствуйте, Serginio1, Вы писали:
_>>Именно про это я и сказал. Т.е. раз отображение идёт везде, то вся разница между измерением EF с linq и EF с row sql идёт за счёт тормозов обработки linq. Можешь сам вычислить эту разницу по данным графикам. Да, и кстати... Если убрать тормоза от трекинга в EF, то в процентном отношение накладные расходы от linq будут выглядеть только хуже (т.к. они не изменятся, а общее время запроса уменьшится). S> Там тоже идет парсинг текста . Посмотри статью http://infostart.ru/public/393228/
Эээ что? ) Какой парсинг, какого текста? )
_>>Вообще то может (было бы смешно иначе, суметь сделать сложное и не суметь простое), хотя это и не часто необходимая функция. S> На самом деле нужно в основном динамические запросы строить особенно интерактивные.
Да что ты говоришь. ))) Ну вот например мы сейчас находимся на форуме. Он работает на основе sql БД (более того, он даже на linq2sql написан, но это к делу уже не относится). И в каких же местах по твоему тут нужны динамические запросы? )
_>>А причём тут вообще бухгалтерский софт, когда мы обсуждали высоконагруженные сервисы? ) Естественно, что на современных компьютерах одиночный запрос в БД не будет тормозить, даже если он генерируется на bash'e. ))) Но это не значит, что тебе удастся написать на bash'e сайт с нормальной посещаемостью. S> 1С это не только бухгалтерия, но и 1С:ERP, производство где нагруженность большая. S>То о чем ты говоришь это типа Гугла, то там и Linq не нужен. Linq нужен где нужно писать тонны кода. И вот здесь во главе угла уже скорость разработки.
Вообще то гугл и ему подобные — это уже следующие уровень, на котором sql БД уже не используются. А мы обсуждаем что-то средненькое, пока ещё с sql, но уже не домашнюю страничку васи пупкина.
S>На самом деле прошу прощения. До конца не просмотрел запрос S>select new { o.OrderID, o.OrderDate, c.Country, c.CompanyName } S> ).Take(500).ToList(); S>Здесь никакого поиска по Кэшам, так как возвращается анонимный класс. Но можно было бы сравнить с применением CompiledQuery.Compile S>https://msdn.microsoft.com/ru-ru/library/bb399335(v=vs.110).aspx S>И посмотреть где идет задержка.
Нуу вперёд, всем будет любопытно посмотреть на ещё варианты замеров) Только не забудь брать за базу вариант на ADO.NET. )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Именно про это я и сказал. Т.е. раз отображение идёт везде, то вся разница между измерением EF с linq и EF с row sql идёт за счёт тормозов обработки linq. Можешь сам вычислить эту разницу по данным графикам. Да, и кстати... Если убрать тормоза от трекинга в EF, то в процентном отношение накладные расходы от linq будут выглядеть только хуже (т.к. они не изменятся, а общее время запроса уменьшится). S>> Там тоже идет парсинг текста . Посмотри статью http://infostart.ru/public/393228/
_>Эээ что? ) Какой парсинг, какого текста? )
Если ты читал мои статьи, то там названия полей могут быть отличными от полей в Базе. Кроме того там могут применяться объектные запросы.
Кроме того в Linq to EF можно использовать Entity SQL
Например
var str = @"Select VALUE p From [Спр_Номенклатура] as p";
var Запрос = qr.CreateQuery<Справочник.Номенклатура>(str );
var res = Запрос.Execute(MergeOption.NoTracking);
foreach (var элем in res)
{
Console.WriteLine("{0}.{1} - {2}", элем.Наименование.TrimEnd(), элем.Артикул, элем.ПолнНаименование.TrimEnd());
}
Идентификаторы
В языке Transact-SQL сравнение идентификаторов всегда осуществляется с учетом параметров сортировки текущей базы данных. В Entity SQL идентификаторы всегда чувствительны к регистру и диакритическим знакам (то есть Entity SQL различает диакритические знаки, например, «а» отличается от «?»). Entity SQL обрабатывает версии букв, которые кажутся такими же, но являются другими символами и происходят из других кодовых страниц. Для получения дополнительной информации см. Набор символов ввода (Entity SQL).
Функциональность Transact-SQL, недоступная в Entity SQL
Следующая функциональность Transact-SQL недоступна в языке Entity SQL.
DML
В настоящее время язык Entity SQL не поддерживает инструкции DML (вставка, обновление, удаление).
DDL
Текущая версия Entity SQL не поддерживает DDL.
Командное программирование
Язык Entity SQL не поддерживает командное программирование в отличие от Transact-SQL. Используйте вместо этого языки программирования.
Функции группирования
Язык Entity SQL пока не поддерживает функции группирования (например, CUBE, ROLLUP и GROUPING_SET).
Функции аналитики
Язык Entity SQL не предоставляет (пока) поддержку функций аналитики.
Встроенные функции, операторы
Язык Entity SQL поддерживает подмножество встроенных функций и операторов Transact-SQL. Вероятно, эти операторы и функции будут реализованы ведущими поставщиками хранилищ. В языке Entity SQL используются специальные функции для хранилищ, объявленные в манифесте поставщика. Кроме того, модель Entity Framework позволяет объявлять встроенные и пользовательские функции хранилища для использования в Entity SQL.
Подсказки
Язык Entity SQL не предоставляет механизм подсказок в запросах.
Пакетирование результатов запроса
Entity SQL не поддерживает пакетирование результатов запросов. Например, допустим следующий запрос Transact-SQL (отправляемый как пакет):
select * from products;
select * from catagories;
Однако эквивалент Entity SQL не поддерживается.
Select value p from Products as p;
Select value c from Categories as c;
Entity SQL поддерживает только запросы, которые выдают один результат на одну команду.
_>>>Вообще то может (было бы смешно иначе, суметь сделать сложное и не суметь простое), хотя это и не часто необходимая функция. S>> На самом деле нужно в основном динамические запросы строить особенно интерактивные.
_>Да что ты говоришь. ))) Ну вот например мы сейчас находимся на форуме. Он работает на основе sql БД (более того, он даже на linq2sql написан, но это к делу уже не относится). И в каких же местах по твоему тут нужны динамические запросы? )
Угу. На этом форуме не так много запросов. С таким объемом и 1С прекрасно справляется. Система оооочень прочтая.
_>>>А причём тут вообще бухгалтерский софт, когда мы обсуждали высоконагруженные сервисы? ) Естественно, что на современных компьютерах одиночный запрос в БД не будет тормозить, даже если он генерируется на bash'e. ))) Но это не значит, что тебе удастся написать на bash'e сайт с нормальной посещаемостью. S>> 1С это не только бухгалтерия, но и 1С:ERP, производство где нагруженность большая. S>>То о чем ты говоришь это типа Гугла, то там и Linq не нужен. Linq нужен где нужно писать тонны кода. И вот здесь во главе угла уже скорость разработки.
_>Вообще то гугл и ему подобные — это уже следующие уровень, на котором sql БД уже не используются. А мы обсуждаем что-то средненькое, пока ещё с sql, но уже не домашнюю страничку васи пупкина.
Со средненьким и 1С прекрасно справляется.
S>>На самом деле прошу прощения. До конца не просмотрел запрос S>>select new { o.OrderID, o.OrderDate, c.Country, c.CompanyName } S>> ).Take(500).ToList(); S>>Здесь никакого поиска по Кэшам, так как возвращается анонимный класс. Но можно было бы сравнить с применением CompiledQuery.Compile S>>https://msdn.microsoft.com/ru-ru/library/bb399335(v=vs.110).aspx S>>И посмотреть где идет задержка.
_>Нуу вперёд, всем будет любопытно посмотреть на ещё варианты замеров) Только не забудь брать за базу вариант на ADO.NET. )))
Да на самом деле мне интересно, как меняется скорость от версии к версии. А вот насчет скорости, то берем и считаем стоимость и скорость разработки, стоимость поддержки. Считаем стоимость железа для поддержки необходимой производительности.
Могут быть трех звенки, двух звенки и гибриды того и другого. Вот кому платит за это и должно быть интересно.
Например на 1С там трех звенка и её можно разнести по кластерам. Но зато там мегабайты кода, но интерпретатор.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
_>>Эээ что? ) Какой парсинг, какого текста? ) S> Если ты читал мои статьи, то там названия полей могут быть отличными от полей в Базе. Кроме того там могут применяться объектные запросы. S>Кроме того в Linq to EF можно использовать Entity SQL S>Например S>...
И какое это всё имеет отношение к обсуждаемой теме? )
S>>> На самом деле нужно в основном динамические запросы строить особенно интерактивные. _>>Да что ты говоришь. ))) Ну вот например мы сейчас находимся на форуме. Он работает на основе sql БД (более того, он даже на linq2sql написан, но это к делу уже не относится). И в каких же местах по твоему тут нужны динамические запросы? ) S> Угу. На этом форуме не так много запросов. С таким объемом и 1С прекрасно справляется. Система оооочень прочтая.
Какое имеет отношение количество видов запросов к возможностям системы выдержать нагрузку? ) Даже если у тебя будет ровно один простой статический запрос (но не кэшируемый), то при миллионе запросов в секунду его не так просто выдержать будет. )))
_>>Вообще то гугл и ему подобные — это уже следующие уровень, на котором sql БД уже не используются. А мы обсуждаем что-то средненькое, пока ещё с sql, но уже не домашнюю страничку васи пупкина. S>Со средненьким и 1С прекрасно справляется.
Да? ) Т.е. 1C умеет работать например на десятке инстансов амазона или чем-то подобном? )
_>>Нуу вперёд, всем будет любопытно посмотреть на ещё варианты замеров) Только не забудь брать за базу вариант на ADO.NET. ))) S> Да на самом деле мне интересно, как меняется скорость от версии к версии. А вот насчет скорости, то берем и считаем стоимость и скорость разработки, стоимость поддержки. Считаем стоимость железа для поддержки необходимой производительности.
Ну так чтобы сделать все эти оценки надо же в начале всё же скорость работы оценить. Точнее если говорить в контексте нашей беседы, то оценить процент накладных расходов от Linq относительно времени основных запросов.
Здравствуйте, alex_public, Вы писали:
_>А причём тут вообще бухгалтерский софт, когда мы обсуждали высоконагруженные сервисы? ) Естественно, что на современных компьютерах одиночный запрос в БД не будет тормозить, даже если он генерируется на bash'e. ))) Но это не значит, что тебе удастся написать на bash'e сайт с нормальной посещаемостью.
Дались вам эти "высоконагруженные" сервисы. В большинстве случаев, это просто прожирание денег инвестора или продажа "перспективного проекта" от одного инвестора другому. Денег они сами не зарабатывают, в отличие от "формоклепских" приложений.
Здравствуйте, alex_public, Вы писали:
_>>>Вообще то гугл и ему подобные — это уже следующие уровень, на котором sql БД уже не используются. А мы обсуждаем что-то средненькое, пока ещё с sql, но уже не домашнюю страничку васи пупкина. S>>Со средненьким и 1С прекрасно справляется.
_>Да? ) Т.е. 1C умеет работать например на десятке инстансов амазона или чем-то подобном? )
Общеизвестно, что при интенсивном использовании железа, выгоднее его покупка, а не аренда у Амазона и тому подобных. Тем более, что никто свою коммерцию в облако отдавать не будет. Облака — это для фоток с котиками или для мапредьюса по фоткам инстаграмма.
Здравствуйте, alex_public, Вы писали:
>Я правильно понял, что ты допускаешь ситуации, в которых linq решение обойдёт по скорости запрос на голых sql строках? ))) И даже не просто допускаешь, а говоришь что "есть масса реальных сценариев"? )
Разумеется. Что делать с твоими голыми sql строками если надо вдруг часть запроса выполнять, скажем, не против sql server а против out process кеша ?
Здравствуйте, Ikemefula, Вы писали:
>>Я правильно понял, что ты допускаешь ситуации, в которых linq решение обойдёт по скорости запрос на голых sql строках? ))) И даже не просто допускаешь, а говоришь что "есть масса реальных сценариев"? ) I>Разумеется. Что делать с твоими голыми sql строками если надо вдруг часть запроса выполнять, скажем, не против sql server а против out process кеша ?
SQL запрос к memcached? ) Это оригинально... Прекращай уже принимать там всякие препараты... )))
Здравствуйте, Danchik, Вы писали:
D>Ты дальше упорото не понимаешь что тебе твердят. То что ты пишешь лишь частный случай и жостко захардкодженый. D>Ты можешь вот это вот, "код" D>
D>вынести в функцию и заджоинится на нее и получить нормальный SQL?
Ты говоришь о чём-то вроде такого
auto F() {return select(users.id, users.name).from(users).where(users.total>total).as(rich_users);}
auto q=F();
for(const auto& row: db(select(orders.user).from(orders.join(q).on(orders.user==q.id)).where(orders.year>year))){
//...
}
кода? Не пойму как в таких тривиальных вещах можно видеть что-то сложное и думать что реализация подобной элементарщины — это какой-то высокий уровень. )))
Здравствуйте, alex_public, Вы писали:
>>>Я правильно понял, что ты допускаешь ситуации, в которых linq решение обойдёт по скорости запрос на голых sql строках? ))) И даже не просто допускаешь, а говоришь что "есть масса реальных сценариев"? ) I>>Разумеется. Что делать с твоими голыми sql строками если надо вдруг часть запроса выполнять, скажем, не против sql server а против out process кеша ?
_>SQL запрос к memcached? ) Это оригинально... Прекращай уже принимать там всякие препараты... )))