Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 19   вперед  Ctrl
 Re: ORM vs sql  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
ShSerge
Там должны обрабатываться данные (!) все. Даже, если напишете 1+2 - только на SQL-сервере.

1. Во-первых, это бред. 1 + 2 можно и не на SQL сервере исполнять. SQL сервер - это хранение данных, а не математический слой.
2. Во-вторых, чем его запрос не угодил? Конкретно по пунктам.
ShSerge
По многим причинам, хотя бы по таким элементарным, что числовые типы совершенно однозначно не маппятся.

А по-русски?

SeVa
МСУ
Уже 100500 раз объяснял. Вот тут вкратце.

Начать лучше с этого ORM is the Vietnam of the Computer Science

Начинать лучше с другого: Объекты и искусство моделирования данных
6 янв 12, 22:11    [11866315]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1876
SeVa
Lelouch
блокноте мне было лень вспоминать написание. А то, что использование DataTable в случае WPF - прошлый век, признает даже Seva


Этот код будет на серверной стороне, а на клиенте ObservableCollection

Какой код? У меня всего-дишь создается коллекция объектов - результатов запроса. Я ни строчки ее обработки не писал...
6 янв 12, 23:06    [11866429]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Worobjoff
Member

Откуда: Москва
Сообщений: 2462
Lelouch
То есть в ваших системах, чтобы показать пользователю какой-нибудь список необходимо использовать запросы с десятками join, курсоры, etc.?
И естественно все эти запросы надо пропускать через аналитиков.. )
1. "Какой-нибудь" список для пользователя - это в среднем 5-10 джойнов. Но есть и на десятки.
2. Курсоры не пишем, и писать не собираемся.
3. Неправильное у вас представление о взаимодействии с аналитиками.

Это - зарубежная ERP.
6 янв 12, 23:15    [11866460]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1876
Worobjoff
Lelouch
То есть в ваших системах, чтобы показать пользователю какой-нибудь список необходимо использовать запросы с десятками join, курсоры, etc.?
И естественно все эти запросы надо пропускать через аналитиков.. )
1. "Какой-нибудь" список для пользователя - это в среднем 5-10 джойнов. Но есть и на десятки.
2. Курсоры не пишем, и писать не собираемся.
3. Неправильное у вас представление о взаимодействии с аналитиками.

Это - зарубежная ERP.


По вашему ORM не справится с 5-10 join'ами?
6 янв 12, 23:26    [11866503]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
SeVa
Member [заблокирован]

Откуда: Москва
Сообщений: 4324
МСУ
Начинать лучше с другого: Объекты и искусство моделирования данных

Mуся, я без этой статьи давно уже говорил, что ORM можно использовать только в качестве тупого DAL и что все они расчитаны на жирные графы объектов, которые совершенно неприспособлены для требований UI(разным use case нужны разные данные).
6 янв 12, 23:29    [11866516]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Worobjoff
Member

Откуда: Москва
Сообщений: 2462
Lelouch
Worobjoff
пропущено...
1. "Какой-нибудь" список для пользователя - это в среднем 5-10 джойнов. Но есть и на десятки.
2. Курсоры не пишем, и писать не собираемся.
3. Неправильное у вас представление о взаимодействии с аналитиками.

Это - зарубежная ERP.


По вашему ORM не справится с 5-10 join'ами?
Думаю что справится. Но это будет хардкод, в котором к тому же, надублируется изрядно функционал. Представления в базе используются многими.
Запросы не очень легкие для сервера, и возможности оптимизации уже исчерпаны. Как тут будет вести ORM?
6 янв 12, 23:37    [11866542]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1876
Worobjoff
Lelouch
То есть в ваших системах, чтобы показать пользователю какой-нибудь список необходимо использовать запросы с десятками join, курсоры, etc.?
И естественно все эти запросы надо пропускать через аналитиков.. )
1. "Какой-нибудь" список для пользователя - это в среднем 5-10 джойнов. Но есть и на десятки.
2. Курсоры не пишем, и писать не собираемся.
3. Неправильное у вас представление о взаимодействии с аналитиками.

Это - зарубежная ERP.

10-15 Join'ов это простые запросы. Если он выполняется медленно всегда можно из ORM получить код генерируемого SQL и понять как это можно решить (я про индексы).
6 янв 12, 23:38    [11866546]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1876
Worobjoff
Lelouch
пропущено...


По вашему ORM не справится с 5-10 join'ами?
Думаю что справится. Но это будет хардкод, в котором к тому же, надублируется изрядно функционал. Представления в базе используются многими.
Запросы не очень легкие для сервера, и возможности оптимизации уже исчерпаны. Как тут будет вести ORM?


Всмысле? Что именно надублируется? join идет через подзапросы. EF это умеет.
6 янв 12, 23:40    [11866555]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Worobjoff
Member

Откуда: Москва
Сообщений: 2462
Lelouch
Worobjoff
пропущено...
Думаю что справится. Но это будет хардкод, в котором к тому же, надублируется изрядно функционал. Представления в базе используются многими.
Запросы не очень легкие для сервера, и возможности оптимизации уже исчерпаны. Как тут будет вести ORM?


Всмысле? Что именно надублируется? join идет через подзапросы. EF это умеет.
В EF есть аналог SQL-представлений?
6 янв 12, 23:47    [11866589]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Worobjoff
Member

Откуда: Москва
Сообщений: 2462
SeVa
Lelouch
пропущено...

Сравните
+
var conection = new SqlConection("<conection string>");
var command = conection.CreateCommand();
command.CommantText = @"SELECT * FROM [TABLE] WHERE [DATE1] > @date1 AND [DATE2] = @date2"
command.Parameters.Add(new SqlParameter("@date1", DateTime.Now));
command.Parameters.Add(new SqlParameter("@date2", DateTime.Now));
var listOfResult = new List<Result>();
using(var reader = command.ExecuteReader)
{
	while(reader.Read())
	{
		var temp = new Result()
		{
			Field1 = (int)reader["field1"],
			Field2 = reader["field2"] as double?,
			<etc>
		};
		listOfResult.Add(temp);
	}
}

c

var context = new MyObjectContext();
var listOfResult = (from obj in context.Table
		   where obj.Date1 > DateTime.Now && obj.Date2 = DateTime.Now
		   select new Result()
		   {
			Field1 = obj.field1,
			Field2 = obj.field2,
			<etc>
		   }).ToList()

Во втором случае можно к тому же обойтись сгенерированным классом. или анонимным.


А что сравнивать? По скорости выполнения ef будет проигрывать минимум в десять раз. С кодогенератором получить готовый код будет не медленней. Это тривиальный случай, а для сложных, пока ты будешь бросать камушки в черный ящик, можно будет протестировать минумум три варианта на чистом sql и выбрать лучший.
А я положу комбобокс на форму и в его свойстве запишу:
"SELECT * FROM [TABLE] WHERE [DATE1] > getdate() AND [DATE2] = getdate()"
И ни одной строчки программного кода.

Или настрою атрибут свойства доменного объекта. Тогда в комбобоксе будет только имя этого свойства.
6 янв 12, 23:48    [11866593]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Парамон
Member

Откуда:
Сообщений: 1468
Люблю SQL, но в процессе составления запросов из строк, есть вероятность допустить ошибку, об этой ошибке я предпочитаю узнать во время компиляции а не во время исполнения.

зы
Склеенный из строк запрос - есть длинный "magic string".
7 янв 12, 00:17    [11866713]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
ShSerge
Member

Откуда: ʚонɔ dиw
Сообщений: 24911
Парамон
Люблю SQL, но в процессе составления запросов из строк, есть вероятность допустить ошибку, об этой ошибке я предпочитаю узнать во время компиляции а не во время исполнения.

А вы его, как все нормальные люди, тестируйте сначала под манажемент студией и смотрите при этом план запроса (желательно).
Тот факт, что компилятор не выдал ошибки, абсолютно не означает, что запрос правильный. :)
7 янв 12, 00:23    [11866721]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1876
Worobjoff
SeVa
пропущено...


А что сравнивать? По скорости выполнения ef будет проигрывать минимум в десять раз. С кодогенератором получить готовый код будет не медленней. Это тривиальный случай, а для сложных, пока ты будешь бросать камушки в черный ящик, можно будет протестировать минумум три варианта на чистом sql и выбрать лучший.
А я положу комбобокс на форму и в его свойстве запишу:
"SELECT * FROM [TABLE] WHERE [DATE1] > getdate() AND [DATE2] = getdate()"
И ни одной строчки программного кода


Это какой-то особый комбобокс или я что то не знаю про стандартные контролы?. А если мне нужно в качестве параметров не 2 текущих времени, а 2, выбираемых пользователем?
И еще, что, если мне не надо выполнять повторный запрос при повторном открытии формы?

P.S. WFP combobox + EF:
combobox1.ItemsSource = from i in context.Table1 select i;

Кода как видите тоже немного.

L2S точно умеет использовать вьюхи в базе, так что я думаю что и EF на это способен.
7 янв 12, 00:26    [11866733]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
Worobjoff
Это - зарубежная ERP.

Да хоть отечественная. Какое это имеет отношение к вышесказанному?
SeVa
МСУ
Начинать лучше с другого: Объекты и искусство моделирования данных

Mуся, я без этой статьи давно уже говорил, что ORM можно использовать только в качестве тупого DAL и что все они расчитаны на жирные графы объектов, которые совершенно неприспособлены для требований UI(разным use case нужны разные данные).

У тебя каша в голове.
Worobjoff
Думаю что справится. Но это будет хардкод, в котором к тому же, надублируется изрядно функционал. Представления в базе используются многими.

Каким образом многие коррелируют с дата-слоем конкретного (-ых) приложения (-ий)?
Worobjoff
Запросы не очень легкие для сервера, и возможности оптимизации уже исчерпаны. Как тут будет вести ORM?

Религия запрещает использовать сторед объекты, намапленные на типизированный контекст?
Worobjoff
В EF есть аналог SQL-представлений?

EF - это не аналог БД. RTFM. Воробье, изучите тему, - Ваши высказывания отдают ламеризмом. Другими словами, мелете языком, вообще не понимая сути. Без обид.
7 янв 12, 00:34    [11866748]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
Worobjoff
А я положу комбобокс на форму и в его свойстве запишу:
"SELECT * FROM [TABLE] WHERE [DATE1] > getdate() AND [DATE2] = getdate()"

Вот это называется жесткий хардкод. Прощай рефакторинг.
7 янв 12, 00:36    [11866753]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1876
И кстати EF озволяет сопоставлять сущности нескольким таблицам. http://msdn.microsoft.com/ru-ru/library/cc716698.aspx
7 янв 12, 00:37    [11866757]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
SeVa
Member [заблокирован]

Откуда: Москва
Сообщений: 4324
МСУ
Worobjoff
Это - зарубежная ERP.

Да хоть отечественная. Какое это имеет отношение к вышесказанному?
SeVa
пропущено...

Mуся, я без этой статьи давно уже говорил, что ORM можно использовать только в качестве тупого DAL и что все они расчитаны на жирные графы объектов, которые совершенно неприспособлены для требований UI(разным use case нужны разные данные).

У тебя каша в голове.
Worobjoff
Думаю что справится. Но это будет хардкод, в котором к тому же, надублируется изрядно функционал. Представления в базе используются многими.

Каким образом многие коррелируют с дата-слоем конкретного (-ых) приложения (-ий)?
Worobjoff
Запросы не очень легкие для сервера, и возможности оптимизации уже исчерпаны. Как тут будет вести ORM?

Религия запрещает использовать сторед объекты, намапленные на типизированный контекст?
Worobjoff
В EF есть аналог SQL-представлений?

EF - это не аналог БД. RTFM. Воробье, изучите тему, - Ваши высказывания отдают ламеризмом. Другими словами, мелете языком, вообще не понимая сути. Без обид.

Муся, у тебя торичелливая пустота в голове, только с ней ты мог дать ссылку на подобную статью, агитируя за ORM.
7 янв 12, 01:18    [11866847]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Worobjoff
Member

Откуда: Москва
Сообщений: 2462
МСУ
Worobjoff
А я положу комбобокс на форму и в его свойстве запишу:
"SELECT * FROM [TABLE] WHERE [DATE1] > getdate() AND [DATE2] = getdate()"

Вот это называется жесткий хардкод. Прощай рефакторинг.
А запрос в LINQ - не хардкод. Ага.
Ты как скорпион в полемике - бьешь себя своим же хвостом.
7 янв 12, 01:25    [11866859]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
ViPRos
Member

Откуда:
Сообщений: 9883
МСУ
ViPRos
а что будет если я на стороне сервера просто убью пару табличек (которые нужны на клиенте и все красиво отмаппено и строго так типизировано) после всех потуг на стороне клиента?

А что если я сервер со всеми клиентами оболью бензином и подожгу? Твой "випрос" продолжит работу?

т.е. ты понимаешь, что твоя "строгая типизация" - МИФ?
А с ВИПРОС все проще.
Фиг кто сможет удалить таблицу, да хоть атрибут, если она использована хоть в одном методе ВИПРОС без соответствующих прав, а если права есть и эти действия могут привести к неработоспособности методов, то методы метятся как "неисполнимые" и менеджер методов просто не будет их вызывать, а сгенерирует ихзепшн.
т.е. метод выставляет контекстные требования к хранилищу, а менеджер метаданных пытается их удовлетварить. это я называю контрактом.
7 янв 12, 01:27    [11866862]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
SeVa
Муся, у тебя торичелливая пустота в голове, только с ней ты мог дать ссылку на подобную статью, агитируя за ORM.

Сева, у тебя смешение фантазии и действительности в разуме, дай ему отдохнуть - он помутнён. Только ты можешь юзкейсы сравнивать с далом.

Worobjoff
МСУ
пропущено...
Вот это называется жесткий хардкод. Прощай рефакторинг.
А запрос в LINQ - не хардкод. Ага.
Ты как скорпион в полемике - бьешь себя своим же хвостом.

Видимо у Вас представление о хардкоде несколько иное. Именно Ваш magic string и есть хардкод. Про рефакторинг комментарии будут? Вот тут всё сказано: 11866713
Изменится поле, как рефакторить будете по всему проекту?

ViPRos
т.е. ты понимаешь, что твоя "строгая типизация" - МИФ?

В чем миф, отец? :)
7 янв 12, 12:14    [11867325]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
ViPRos
это я называю контрактом.

Это не контракт, это банальная обработка исключения. Я тоже так умею
7 янв 12, 12:43    [11867364]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
Worobjoff
Ты как скорпион в полемике - бьешь себя своим же хвостом.


SELECT 
    p.Description,
    s.Name,
    (SELECT COUNT(*) FROM PurchaseItem pi WHERE p.ID = pi.PurchaseID) PurchaseItemCount	
FROM Purchase p
    LEFT OUTER JOIN 
        Customer c 
            INNER JOIN Address a ON c.AddressID = a.ID
            LEFT OUTER JOIN SalesPerson s ON c.SalesPersonID = s.ID
    ON p.CustomerID = c.ID	
WHERE
    (a.State = 'WA' OR p.CustomerID IS NULL)
    AND p.ID in
    (
        SELECT PurchaseID FROM PurchaseItem
        GROUP BY PurchaseID HAVING SUM (SaleAmount) > 1000
    )
ORDER BY
    (SELECT SUM (SaleAmount) FROM PurchaseItem pi WHERE p.ID = pi.PurchaseID) DESC


from p in db.Purchases
where p.Customer.Address.State == "WA" || p.Customer == null
let purchaseValue = p.PurchaseItems.Sum (pi => pi.SaleAmount)
where purchaseValue > 1000
orderby purchaseValue descending
select new
{
   p.Description,
   p.Customer.SalesPerson.Name,
   PurchaseItemCount = p.PurchaseItems.Count()
}


Что скажешь, скорпион? :) Во-вторых, у меня на этапе компиляции будет известно об ошибке, в отличие от хардкодного сиквел-запроса.
7 янв 12, 12:50    [11867369]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Worobjoff
Member

Откуда: Москва
Сообщений: 2462
МСУ
Worobjoff
Ты как скорпион в полемике - бьешь себя своим же хвостом.


SELECT 
    p.Description,
    s.Name,
    (SELECT COUNT(*) FROM PurchaseItem pi WHERE p.ID = pi.PurchaseID) PurchaseItemCount	
FROM Purchase p
    LEFT OUTER JOIN 
        Customer c 
            INNER JOIN Address a ON c.AddressID = a.ID
            LEFT OUTER JOIN SalesPerson s ON c.SalesPersonID = s.ID
    ON p.CustomerID = c.ID	
WHERE
    (a.State = 'WA' OR p.CustomerID IS NULL)
    AND p.ID in
    (
        SELECT PurchaseID FROM PurchaseItem
        GROUP BY PurchaseID HAVING SUM (SaleAmount) > 1000
    )
ORDER BY
    (SELECT SUM (SaleAmount) FROM PurchaseItem pi WHERE p.ID = pi.PurchaseID) DESC


from p in db.Purchases
where p.Customer.Address.State == "WA" || p.Customer == null
let purchaseValue = p.PurchaseItems.Sum (pi => pi.SaleAmount)
where purchaseValue > 1000
orderby purchaseValue descending
select new
{
   p.Description,
   p.Customer.SalesPerson.Name,
   PurchaseItemCount = p.PurchaseItems.Count()
}
Даже мысли не допускаю эту порнографию хардкодить.
МСУ, ты сам за других додумываешь, и сам этим своим додумкам отвечаешь на этом сайте.
Сам с собой так.
7 янв 12, 13:24    [11867396]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
SeVa
Member [заблокирован]

Откуда: Москва
Сообщений: 4324
Math.Pi-r, оставь свои пионерские статейки при себе. Кроме table ты ничего не видел
7 янв 12, 13:26    [11867398]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
SeVa
Member [заблокирован]

Откуда: Москва
Сообщений: 4324
МСУ
Worobjoff
Ты как скорпион в полемике - бьешь себя своим же хвостом.


SELECT 
    p.Description,
    s.Name,
    (SELECT COUNT(*) FROM PurchaseItem pi WHERE p.ID = pi.PurchaseID) PurchaseItemCount	
FROM Purchase p
    LEFT OUTER JOIN 
        Customer c 
            INNER JOIN Address a ON c.AddressID = a.ID
            LEFT OUTER JOIN SalesPerson s ON c.SalesPersonID = s.ID
    ON p.CustomerID = c.ID	
WHERE
    (a.State = 'WA' OR p.CustomerID IS NULL)
    AND p.ID in
    (
        SELECT PurchaseID FROM PurchaseItem
        GROUP BY PurchaseID HAVING SUM (SaleAmount) > 1000
    )
ORDER BY
    (SELECT SUM (SaleAmount) FROM PurchaseItem pi WHERE p.ID = pi.PurchaseID) DESC


from p in db.Purchases
where p.Customer.Address.State == "WA" || p.Customer == null
let purchaseValue = p.PurchaseItems.Sum (pi => pi.SaleAmount)
where purchaseValue > 1000
orderby purchaseValue descending
select new
{
   p.Description,
   p.Customer.SalesPerson.Name,
   PurchaseItemCount = p.PurchaseItems.Count()
}


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


За такие запросы нужно голову откручивать. В твоем случае - задницу
7 янв 12, 13:28    [11867403]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 19   вперед  Ctrl
Все форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM Ответить