Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Посоветуйте ORM  [new]
krudensoft
Member

Откуда:
Сообщений: 83
Исходные данные: WinForms клиент, MS SQL Server (2005, 2008) .NET 2.0
БД большая (складская программа)

Задача следующая:
1. Считать и показать список накладных (100 - 100000 строк);
2. Открыть и отредактировать накладную (шапка + 100-5000 строк товаров) ;
3. Быстро сохранить в одной транзакции эту накладную (шапку и товарку)(система многопользовательская).

Системы, которые за меня будут генерить запросы - не предлагайте, я знаю TSQL лучше, чем они 8).
Написание CRUD на клиенте тоже малоинтересно, в силу его медлительности.

Сейчас использую залив данных на сервер во времянки через Bulk Insert и далее выполнение ХП для валидации и слива в постоянки.
Конечно, возможно, есть еще более быстрый способ быстро слить большой объем данных на сервер, чем bulk. 8)

Премного благодарен. 8)
25 авг 11, 16:02    [11179367]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
SolYUtor
Member

Откуда:
Сообщений: 948
krudensoft
Системы, которые за меня будут генерить запросы - не предлагайте, я знаю TSQL лучше, чем они 8).
Написание CRUD на клиенте тоже малоинтересно, в силу его медлительности.


Хм. Вы точно ORM ищете? Собственно, они и занимаются генерацией CRUD запросов на клиенте.
25 авг 11, 16:20    [11179592]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
krudensoft
Member

Откуда:
Сообщений: 83
SolYUtor,

Дело в том, что мне нужно быстро сохранять данные на сервер.
Сохранение построчно с помощью CRUD комманд - это очень, очень медленно.

Возможно, я что-то путаю.

Чего хочется: некое готовое решение для паттерна MVC (я считал, что ORM и предназначены как раз для его реализации), которое позволяло бы писать свои механизмы для заливки на сервер (или использовало бы описанный мной).
25 авг 11, 16:27    [11179658]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
SolYUtor
Member

Откуда:
Сообщений: 948
krudensoft,

ааа, так вы боитесь построчного обращения к БД? Приличные ORM умеют отправлять запросы пакетами, так что предаврительно изучить возможности конкретной ORM.

Далее буду говорить как большой сторонник NHibernate, за него и агитирую. :)

krudensoft
Исходные данные: WinForms клиент, MS SQL Server (2005, 2008) .NET 2.0
БД большая (складская программа)


С 2.0 выбор будет сильно огранчен. Ибо его поддержку даже мелкософт прекратила. Может хотя бы на 3.5 перейти? Но может взять старую версию - NH 2.1.1.

krudensoft
Задача следующая:
1. Считать и показать список накладных (100 - 100000 строк);
2. Открыть и отредактировать накладную (шапка + 100-5000 строк товаров) ;
3. Быстро сохранить в одной транзакции эту накладную (шапку и товарку)(система многопользовательская).


1. 100 - это нормально. Но 100000 зачем? И дело даже не в ORM, просто по сети передавать долго будет. Но вот недавно пробовал на NHibernate скорость загрузки проекции из 400к строк. Заняло несколько секунд.
2-3. Насколько быстро можно выполнить этот пункт зависит не только и не столько от ORM. Но если это обычная операция сохранения, то особой разницы по сравнению с обычным TSQL не заметите.

В остальном оптимизация возможна для каждого конкретного случая.
25 авг 11, 16:33    [11179711]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
krudensoft
Member

Откуда:
Сообщений: 83
SolYUtor,

Тут не просто сохранение.
При сохранении накладной осуществляется валидация сохраняемых данных и по итогам валидации решается, будет ли сохранен документ в БД или нет.

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

Сохранение балком 100 записей из накладной длится меньше секунды. 3-4 секунды - это уже слишком много.
Впервые столкнувшись с .NET я использовал как раз стандартный книжный подход для DataAdapter`a и он меня жутко разочаровал из-за своей скорости...

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

Вот почему и интересовался, есть ли ORM, которые умеют сохранять с помошью BulkInsert или хотя бы дающие возможность переопределить методы сохранения?
25 авг 11, 16:51    [11179916]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
SolYUtor
Member

Откуда:
Сообщений: 948
krudensoft,

Наличие ORM предполагает, что ваша бизнес логика и будет на клинете, либо сервере приложений.
Что касается валидации - надо пробовать на ваших данных и базе. Теоретически, загрузить всю необходимую информацию можно за один поход к БД, проверить валидацию на клиенте, и в случае успеха отправить накладную на в БД. На накладую из 100 строк думаю вполне реально получить результат меньше секудны.

Переопределять методы сохранения, загрузки и т.д. можно. Но в этом случае вы потеряте многие возможности ORM связанные с эффективными запросами к БД.
25 авг 11, 17:05    [11180058]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
krudensoft
Member

Откуда:
Сообщений: 83
SolYUtor,
SolYUtor
Наличие ORM предполагает, что ваша бизнес логика и будет на клинете, либо сервере приложений.

Т.е. правильно ли я понял, что вся прелесть ORM в том, что не надо писать запросы?

SolYUtor
Что касается валидации - надо пробовать на ваших данных и базе. Теоретически, загрузить всю необходимую информацию можно за один поход к БД, проверить валидацию на клиенте, и в случае успеха отправить накладную на в БД. На накладую из 100 строк думаю вполне реально получить результат меньше секудны.

У некоторых клиентов базы данных превышают 450Гб. Используется сегментирование и прочие хитрости, чтобы такие обьемы ворочались достаточно шустро. Делать валидацию на клиенте нереально, т.к. за время закачки результатов валидации и слива данных на скул, валидация может устареть.

SolYUtor
>Переопределять методы сохранения, загрузки и т.д. можно. Но в этом случае вы потеряте многие возможности ORM связанные с >эффективными запросами к БД.

Спасибо за ответы. Получается, под мои задачи ORM не подходят... Ну или надо менять задачи. 8)
25 авг 11, 17:42    [11180399]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
SolYUtor
Member

Откуда:
Сообщений: 948
krudensoft
Т.е. правильно ли я понял, что вся прелесть ORM в том, что не надо писать запросы?

В первую очередь ORM помогает избавится от рутинного CRUD'а. Особенно для простых сущностей. Всякие справочники и т.д. идут на ура, там где надо более сложная логика - приходится потрудится чуть побольше. Но разве с T-SQL дело обстоит так же. :)

krudensoft
У некоторых клиентов базы данных превышают 450Гб. Используется сегментирование и прочие хитрости, чтобы такие обьемы ворочались достаточно шустро. Делать валидацию на клиенте нереально, т.к. за время закачки результатов валидации и слива данных на скул, валидация может устареть.

Вряд ли вы одиноки в своих проблема насчёт 450Гб. И есть много способов оптимизации в т.ч. при работе с ORM. Устаревать валидация не будет, т.к. загрузка данных, валидация, и сохранение накладной идут в рамках транзакции.

SolYUtor
Спасибо за ответы. Получается, под мои задачи ORM не подходят... Ну или надо менять задачи. 8).

Скорее вам придётся кардинально менять способы решения задачи. :)
Ибо ORM"ы заточены под DDD, использует все преимущества неведения о сохранямости, улучшает возможности тестирования и надёжность приложения. Но естественно, не бесплатно, некоторое снижение производительности будет. Насколько сильно - зависит от понимания узких мест, возможностей ORM, и вашего уровня владения им. ;)
25 авг 11, 18:02    [11180557]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
krudensoft
Исходные данные: WinForms клиент, MS SQL Server (2005, 2008) .NET 2.0
БД большая (складская программа)

Entity Framework однозначно.
25 авг 11, 20:07    [11181224]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
bured
Member

Откуда:
Сообщений: 24297
Забавный топик. ТС пока не понял что такое ОРМ, но он ему очень нужен.
25 авг 11, 20:15    [11181244]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
krudensoft
Посоветуйте ORM


krudensoft
Системы, которые за меня будут генерить запросы - не предлагайте


Великолепно.

krudensoft
Написание CRUD на клиенте тоже малоинтересно, в силу его медлительности.


Ни дать ни взять. Всё чётко.

krudensoft
Сейчас использую залив данных на сервер во времянки через Bulk Insert и далее выполнение ХП для валидации и слива в постоянки.


Чудо-система, просто пестец какой-то.



25 авг 11, 20:19    [11181254]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
SolYUtor
Member

Откуда:
Сообщений: 948
МСУ
krudensoft
Исходные данные: WinForms клиент, MS SQL Server (2005, 2008) .NET 2.0
БД большая (складская программа)

Entity Framework однозначно.


Видимо первый EF, да?
25 авг 11, 23:37    [11181823]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
SolYUtor
Видимо первый EF, да?

Либо ап .NET'а, либо ... ну хибер, согласен )
26 авг 11, 08:59    [11182306]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13632
BLToolKit ещё можно взять. Впрочем, вызывает сомнение необходимость тягать из/в БД NNNNNN записей.
26 авг 11, 11:06    [11183274]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
SeVa
Member [заблокирован]

Откуда: Москва
Сообщений: 4324
SolYUtor
Скорее вам придётся кардинально менять способы решения задачи. :)
Ибо ORM"ы заточены под DDD, использует все преимущества неведения о сохранямости, улучшает возможности тестирования и надёжность приложения. Но естественно, не бесплатно, некоторое снижение производительности будет. Насколько сильно - зависит от понимания узких мест, возможностей ORM, и вашего уровня владения им. ;)


Другими словами: нужно четко понимать ограничения ORM и знать, как с этим бороться. А бороться можно только одним способом - подстраиваться под эти ограничения и узкие места, набивать шишки, пытаться понять, что закопано в этом черном ящике.
Процес муторный и долгий.
Помимо этого есть еще один момент - разным пользователям в разные моменты нужны разные срезы данных, а ORM тащит толстый граф, начинаются муторные мультики с ленивыми загрузками. Пока из попытки соединить ужа с ежом ничего путного не получается.
Если сюда прибавить кривую работу с БД, то лучший ORM - отсутствие его как такового.
26 авг 11, 11:21    [11183403]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
SolYUtor
Member

Откуда:
Сообщений: 948
SeVa,

большое спасибо за подтверждение моих слов!
26 авг 11, 12:50    [11184305]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
SolYUtor
Member

Откуда:
Сообщений: 948
Алексей К
BLToolKit ещё можно взять. Впрочем, вызывает сомнение необходимость тягать из/в БД NNNNNN записей.

BLToolKit это конечно не ORM, но явно лучше голого ADO.NET.
26 авг 11, 13:00    [11184446]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
SeVa
Если сюда прибавить кривую работу с БД, то лучший ORM - отсутствие его как такового.

При сложных срезах и прочих телодвижениях всегда есть возможность раскурить срарую добрую хранимую процедуру или функцию, намапленную на свою дата-модель. Для круда и прочего ребячества, коего 90% в более менее серьезном проекте, ORM - то, что доктор прописал. Никаких графов.
26 авг 11, 13:13    [11184596]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
SeVa
Member [заблокирован]

Откуда: Москва
Сообщений: 4324
Если нет графов, то это только какой-то примитивный классификатор, в остальных 99% - сложный граф
26 авг 11, 13:29    [11184750]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
EDUARD SAPOTSKI
Member

Откуда:
Сообщений: 2371
Как здесь смайлики вставлять? Ну типа :Ржунимагу:

Вы мне скажите нафига Вам ваще ORM сдался если речь идет только об накладных?
Два класса - накладная и товар, товар соответственно списком идет в накладной. Коннектор, команд, риадер... полдня работы и накладные летают только в путь и никаких проблем с производительностью.
26 авг 11, 14:09    [11185190]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
SolYUtor
Member

Откуда:
Сообщений: 948
EDUARD SAPOTSKI,

Если вы думаете, что обработка накладной - это кинуть в базу шапку и товар, то нужен смайлик чтобы поржать над вами. А то что вы описали на полдня, можно сделать за почаса с ORM'ом.
26 авг 11, 14:28    [11185309]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
SolYUtor
Member

Откуда:
Сообщений: 948
SeVa
Если нет графов, то это только какой-то примитивный классификатор, в остальных 99% - сложный граф


Проблемой графов вы не один озадачились. ORM'ы имеют эффективные средства для их загрузки ( или не загруки, it depends).
26 авг 11, 14:30    [11185326]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
SeVa
Если нет графов, то это только какой-то примитивный классификатор, в остальных 99% - сложный граф

Вовсе нет, я могу использовать "линейные" прокси сущности, объединяющие в себе конкретные атрибуты некоторыъ других сущностей. Такая педаль как-раз и достигается с помощью линк-запросов или сторед объектов в угоду производительности. Всё от задачи зависит.
26 авг 11, 14:38    [11185403]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
EDUARD SAPOTSKI
Member

Откуда:
Сообщений: 2371
SolYUtor
EDUARD SAPOTSKI,

Если вы думаете, что обработка накладной - это кинуть в базу шапку и товар, то нужен смайлик чтобы поржать над вами. А то что вы описали на полдня, можно сделать за почаса с ORM'ом.

Где я такое писал, что я так думаю? Даже если так, а оно так и есть, Вы можете много придумать реальных операций с накладными которые требуют применений нетривиальных алгоритмов? Примеры в студию! Я чето сходу так и не придумаю.

>>А то что вы описали на полдня, можно сделать за почаса с ORM'ом.

:Ржунимагу: особенно применительно к поставленной задаче.
26 авг 11, 15:01    [11185648]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте ORM  [new]
SolYUtor
Member

Откуда:
Сообщений: 948
EDUARD SAPOTSKI
Где я такое писал, что я так думаю? Даже если так, а оно так и есть, Вы можете много придумать реальных операций с накладными которые требуют применений нетривиальных алгоритмов? Примеры в студию! Я чето сходу так и не придумаю.


Сложность не в алгоритмах. А в количестве простых действий, которые надо выполнить в рамках одной транзакции.
26 авг 11, 15:23    [11185841]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM Ответить