Здравствуйте, Tom, Вы писали:
L>>Нет, этот вариант хуже линка, уверяю вас. Маппинг придется реализовывать в ручную. Хотя кому-то это очень нравится (DuШes). Tom>Я предпологал, что тул так же генерирует набор классов, на которые мапятся вызовы стор. Или у вас это не так?
Классы генерятся, если процедура возвращает 1 рекордсет. Если больше одного, надо самостоятельно указывать тип.
L>Здесь процедура CustOrderHistTwice возвращает 2 резалтсета.
L>Использовать во так:
L>
L>DataClasses1DataContext ctx = new DataClasses1DataContext();
L>var result = ctx.CustOrderHistTwice("CACTU");
L>foreach (var hist in result.GetResult<CustOrderHistResultEntry>())
L>{
L> Console.WriteLine(new { hist.ProductName, hist.Total });
L>}
L>Console.WriteLine("==============");
L>foreach (var hist in result.GetResult<CustOrderHistResultEntry>())
L>{
L> Console.WriteLine(new { hist.ProductName, hist.Total });
L>}
L>
L>И все.
L>Как видишь, никакой магии и правки руками. Только стандартный функционал.
давайте наверно уже закончим я понял что вы имеет ввиду, магия здесь в классах CustOrderHistResultEntry и в поддержке такиго рода в синхронном состоянии
Здравствуйте, DuШes, Вы писали:
L>>Как видишь, никакой магии и правки руками. Только стандартный функционал.
DШ>давайте наверно уже закончим
давайте для начала вы ответите на вопросы, которые вам были заданы. проявляйте уважение к собеседнику.
DШ>я понял что вы имеет ввиду, магия здесь в классах CustOrderHistResultEntry и в поддержке такиго рода в синхронном состоянии
Опишите свой вариант. Как вы поддерживаете синхронность кроме как руками? Я вариантов вообще не вижу. Более того, у меня есть подозрение, что это нельзя сделать атоматически всилу того, что sqlserver не возвращает схему резалтсетов, следующих за первым. Хотя по этому поводу я не на 100% уверен.
Здравствуйте, kenzo_u, Вы писали:
_>Почему фиолетово для квалифицированного разработчика и почему только хранимки для стажеров?
Потому что у опытного разработчика DAL будет в любом случае, а стажеру надо учиться запросы отделять, да и руку набивать в работе с базой. А то потом появляются разработчики, которые БД боятся как огня, не знают что с ней делать и только мифы всякие распространяют.. =)
Здравствуйте, Sinix, Вы писали:
S>Сорри, что вмешиваюсь, но получение схемы результсета хранимой процедуры — вполне выполнимая операция. Скажем, дадасет дизайне такое умеет.
Значит ошибался. А где можно посмотреть как оно работает?
L>Классы генерятся, если процедура возвращает 1 рекордсет. Если больше одного, надо самостоятельно указывать тип.
А больше одного и нафик не нужно обычно.
L>Значит ошибался. А где можно посмотреть как оно работает?
Ага, интересно особенно как оно будет работать если мы вдруг ему подсунем стору которая возвращает разные наборы при разных входных параметрах.
Здравствуйте, Tom, Вы писали:
L>>Классы генерятся, если процедура возвращает 1 рекордсет. Если больше одного, надо самостоятельно указывать тип. Tom>А больше одного и нафик не нужно обычно.
У всех разные сценарии.
Нафига все это нужно?!?! Если для того, чтобы получить 1 запись из базы вынимаются все!!! и потом из них уже возвращается одна. Либо я чего-то не понимаю. Ведь быстрее вытащить только то, что нам надо, чем потом искать?!?!
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, DuШes, Вы писали:
L>>>Как видишь, никакой магии и правки руками. Только стандартный функционал.
DШ>>давайте наверно уже закончим
L>давайте для начала вы ответите на вопросы, которые вам были заданы. проявляйте уважение к собеседнику.
да о чем вы говорите, вы сами давно уже прекратили здесь http://rsdn.ru/forum/message/3335827.1.aspx
насчет ваших вопросов: L>Так вот, что вы имели в виду. Вы оказывается, dbml называете кодом, а автоматической генерацией называете процедуру перетаскивания всех таблиц в дизайнер или то, что получается при первоначальном создании dbml-я по базе. Я вас правильно понял?
dbml — да, именно тот код, а вы что подразумевали под классами-врапперами, о которых я уже устал писать ...
L>Теперь что по поводу "реализовывать трекинг вручную"?
насчет трекинга вручную, в вашем примере: L>
L>DataClasses1DataContext ctx = new DataClasses1DataContext();
L>var result = ctx.CustOrderHistTwice("CACTU");
L>foreach (var hist in result.GetResult<CustOrderHistResultEntry>())
L>{
L> Console.WriteLine(new { hist.ProductName, hist.Total });
L>}
L>Console.WriteLine("==============");
L>foreach (var hist in result.GetResult<CustOrderHistResultEntry>())
L>{
L> Console.WriteLine(new { hist.ProductName, hist.Total });
L>}
L>
L>И все.
это не все, если уж быть до конца честным, давайте рассмотрим еще и классы врапперы CustOrderHistResultEntry...хорошо если процедура состоит из банального select и дизайнер сумеет таки сгенерить вам класс, хотя, как вы сами здесь и утверждаете S>Сорри, что вмешиваюсь, но получение схемы результсета хранимой процедуры — вполне выполнимая операция. Скажем, дадасет дизайне такое умеет. L>Значит ошибался. А где можно посмотреть как оно работает?
класс-врапперы вы не генерите, а пишите сами, это и есть вручную или я ошибаюсь?
Вообще, при более-менее сложной логике сигнатура возвращаемых данных может быть гораздо сложнее, это и преобразования типа, и вычисляемые поля, и вложенные select для конкретного поля из записи рекордсета...и тут уже приходится писать такие классы вручную, что собственно и приводит к необходимости написания "трекинга" кода именно вручную...
Возвращаясь (просто уж о наболевшем в конктексте использования процедур в linqtosql): L>Как видишь, никакой магии и правки руками. Только стандартный функционал.
такой же "стандартный" функционал есть классическое использование datareader|dataset, и в данном конкретном случае необходимости в линке вообще не вижу
DШ>>я понял что вы имеет ввиду, магия здесь в классах CustOrderHistResultEntry и в поддержке такиго рода в синхронном состоянии L>Опишите свой вариант. Как вы поддерживаете синхронность кроме как руками? Я вариантов вообще не вижу. Более того, у меня есть подозрение, что это нельзя сделать атоматически всилу того, что sqlserver не возвращает схему резалтсетов, следующих за первым. Хотя по этому поводу я не на 100% уверен.
да здесь я не спорю, я как раз и утверждаю, что такого рода синхронность добиться сделать ну практически нереально...точнее, можно сделать, но просто лишив программиста вообще такого слоя как структура базы данных, тем самым просто придя к понятию объектных хранилиш, где за основу берется интерфейс самого класса, а не структура таблиц и сигнатур процедур, чтото вроде db4o
Здравствуйте, Spender, Вы писали:
S>На самом деле ли LINQ к Store Procedure сможет улучшить производительность системы?
Нет это чушь.
SP могут увеличить производительность только за счет того, что можно будет множество запросов выполнить не покидая процесса сиквила. Что же касается компиляции запросов, то как раз linq тут вне конкуренции. Он порождает параметризованные запросы которые отлично компилируются и используются повторно. Более того, linq может оказаться предпочтительнее в случае сложных изменяемых многопараметрических запросов, так как он порождает конечный набор параметризованных запросов которые отлично кэшируются. Реализовать тоже самое в рамках хранимых процедур будет значительно сложнее.
Так что ваш начальник просто не владеет информацией и делает поспешные выводы. Я бы на его месте покурил бы статьи посвященные оптимизации многопараметрических запросов и произвел бы тесты.
Что касается оптимизации межпроцессного взаимодействия, то тут могут помочь хранимки написанные на дотнете (если конечно сервером выступает MS SQL). В них можно применять linq и они выполняются в рамках процесса сиквела.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, TK, Вы писали:
TK>Плюс хранимой процедуры в том, что ее можно "оптимизировать" не трогая оригинальное приложение. в остальном, современные SQL сервера умеют кешировать планы выполнения запросов.
Проблема в том, что если хранимка не прямолинейна, то очень не просто добиться для нее хороших планов для разных входных параметров. Линк же будет генерировать разные запросы которые по определению будут давать более оптимальные планы.
Что касается оптимизации, то у MS SQL 2008 в этом плане есть существенные улучшения, так что и для отдельных запросов можно добиться хороших результатов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Spender, Вы писали:
S>[крик души]
S>Нафига все это нужно?!?! Если для того, чтобы получить 1 запись из базы вынимаются все!!! и потом из них уже возвращается одна. Либо я чего-то не понимаю. Ведь быстрее вытащить только то, что нам надо, чем потом искать?!?!
Мне кажется, вы не совсем правильно поняли, что имелось в виду.
Например, у вас есть хранимая процедура GetOrder. Она принимает сл. параметры: @OrderID, @WithOrderLines, @WithDeliveryHistory.
Соответственно, когда вы запустили ее вот так:
, то она тоже вернет два рекордсета: 1) "шапка" заказа 2) строчки истории доставки. Но в этом случае второй рекордсет будет уже другим (его колонки могут отличаться).
Как получить схему резалтсета такой процедуры лично мне совсем не понятно. Единственный вариант, который я вижу — это самостоятельно это разруливать руками.
Здравствуйте, Tom, Вы писали:
TK>>Почитайте тут: http://msdn.microsoft.com/ru-ru/library/ms181055.aspx TK>>В остальном, надо исходить из того, что SQL Server хранит только исходный код хранимых процедур и триггеров. При выполнении хранимой процедуры или триггера в первый раз исходный код компилируется в план выполнения. т.е. разница только в том, где будет хранится "текст" запросов. в случае с хранимыми процедурами (особенно если их тысячи) вы "усложняете" себе поддержку вашего решения.
Tom>А в чём усложнение?
А замена проверяемого во время компиляции, поддающегося рефакторингу и хранимого в системе контроля версий кода на код хранимый в БД, проверяемый только во время интерпретации и плохо поддающийся рефаторингу — это не усложнение?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
S>>[крик души]
L>Мне кажется, вы не совсем правильно поняли, что имелось в виду.
Все что Вы написали, я понимаю. Это же был крик души на то, что я увидел в коде системы. Для получения одной записи вытаскиваются все из БД, а потом уже полученный результат преобразуется в List<T> и там ищется по параметрам.
я понял что вы имеет ввиду, магия здесь в классах CustOrderHistResultEntry и в поддержке такиго рода в синхронном состоянии
Мы уже победили, просто это еще не так заметно...
Я плякаль...
