Здравствуйте, VladD2, Вы писали:
VD>Как это нет?
А вот так. 90% запросов тупо прошиты в коде, в том числе и тот, который IT переписал.
VD>В прочем ты не раз оптимизировал код сервера, но он все равно упорно продолжает тормозить.
Ни я, ни кто другой, никогда не пытались привести там все в порядок, просто лечили наиболее острые проблемы. К чему такой подход приводит вообщем-то очевидно и совершенно не зависит от используемого инструмента и даже области — линк, хранимки, C++, C# — без разницы.
VD> IT замечательно продемонстрировал, что с помощью линка и грамотного подхода можно резко увеличить производительность.
А с этим кто-то спорил?
VD>Как раз к триггерам у меня особых вопросов нет.
А у меня есть. И именно об этом я и писал, а не про линк.
VD>Кстати, а теперь можно писать триггеры на донтете?
В каком смысле? Ты можешь конечно задействовать код написанный на дотнете из триггера, равно как и из любой хранимки, но на практике толку от этого мало.
VD>Дык тема как раз про линк и перенос этой логики в хранимки. Причем не в виде продуманного решения, а так чтобы компиляцию устранить.
Но я этой темы здесь не касался и писал совершенно не об этом.
Здравствуйте, VladD2, Вы писали:
VD>Возможно. А возможно и нет. VD>Поделись своими мыслями... поглядим.
Это на хорошую статью потянет, а они уже написаны. Вот здесь например: http://technet.microsoft.com/ru-ru/library/cc966425(en-us).aspx
VD>Понятно, что какие-то там нюансы существуют. Но для понимания общего принципа оно не нужно.
Ты как-то совсем общий принцип урезал. =)
Здравствуйте, IB, Вы писали:
VD>>Кстати, а теперь можно писать триггеры на донтете? IB>В каком смысле? Ты можешь конечно задействовать код написанный на дотнете из триггера, равно как и из любой хранимки, но на практике толку от этого мало.
Если есть возможность создавать хранимки на дотнете, то было бы логично сделать интерфейс и для создания триггеров на дотнете. То есть, не вызвать дотнетный код из T-SQL-ного триггера, а напрямую подключать метод в качестве обработчика. Что-то типа событий.
Судя по твоей реакции такого нет. А жаль.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Это на буржуйском. Плюс статья явно устарела. Статья 2004 года, а в 2008, как я понимаю как раз в области планов были серьезные изменения.
VD>>Понятно, что какие-то там нюансы существуют. Но для понимания общего принципа оно не нужно. IB>Ты как-то совсем общий принцип урезал. =)
Ты всю ветку читал? Видел на что я отвечал?
Человек не понимает самого общего принципа кэшироания планов. От того сделал вывод, что динамические запросы в хранимках всегда ухудшают производительность. А дело (скорее всего) было в том, что EXEC применялся, а параметры были в код зашиты. В итоге кэшировалось все подряд и толку от такого кэша практически не было.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Если есть возможность создавать хранимки на дотнете, то было бы логично сделать интерфейс и для создания триггеров на дотнете. То есть, не вызвать дотнетный код из T-SQL-ного триггера, а напрямую подключать метод в качестве обработчика. Что-то типа событий.
VD>Судя по твоей реакции такого нет. А жаль.
CREATE TRIGGER trigger_name ON table_name FOR INSERT
AS EXTERNAL NAME assembly_name.class_name.method_name
L>>CREATE TRIGGER trigger_name ON table_name FOR INSERT
L>>AS EXTERNAL NAME assembly_name.class_name.method_name
L>>
VD>А как должен метод выглядеть?
< method_specifier >
For a CLR trigger, specifies the method of an assembly to bind with the trigger. The method must take no arguments and return void. class_name must be a valid SQL Server identifier and must exist as a class in the assembly with assembly visibility. If the class has a namespace-qualified name that uses '.' to separate namespace parts, the class name must be delimited by using [ ] or " " delimiters. The class cannot be a nested class.
Здравствуйте, kenzo_u, Вы писали:
_>Почему фиолетово для квалифицированного разработчика и почему только хранимки для стажеров?
Потому что у квалифицированного DAL будет, а значит где конкретно находятся запросы не столь важно, а у стажера — все равно будет каша, так хоть запросы отдельно лягут, да и руку набивать надо.
Здравствуйте, VladD2, Вы писали:
VD>Ну, так за чем дело встало?
Я последние лет несколько сиквелом не очень плотно занимаюсь.
VD>Это на буржуйском. Плюс статья явно устарела.
Она более чем актуальна.
VD> Статья 2004 года, а в 2008, как я понимаю как раз в области планов были серьезные изменения.
Серьезных не было. Там планомерные улучшения с 2000-й версии.
VD>Ты всю ветку читал? Видел на что я отвечал?
Мнизу вверх, сначало это, а потом то что раньше — по нетбуку совсем не удобно.. )
Здравствуйте, VladD2, Вы писали:
VD>Судя по твоей реакции такого нет. А жаль.
Нет, у меня реакция — "есть но непонятно зачем". На практике такое пожалуй только для поддержки легаси кода нужно, ну или какая-нибудь экзотика...
Здравствуйте, VladD2, Вы писали:
VD>Я еще не видел, чтобы интеграция работала лучше компилятора. У него и времени больше, и проблем меньше.
Я тебе про DBPro еще два года назад рассказывал, ты и тогда не верил, а проверить поленился...
Все очень не плохо работает, те недостатки которые ты описываешь, этот инструмент убирает, правда определенная культура нужна.
А линк, к сожалению не панацея, нельзя весь код на него перенести.
VD>Лучше бы чтобы все автоматом менялось.
Можно и автоматом, можно и в строковых константах.
VD>Гы. Любимый аргумент любителей скриптов. "А у нас юнит-тесты есть".
Дело не в скриптах, а в том, что юнит-тесты много где могут пригодится, в том числе и в БД.
Здравствуйте, gandjustas!
G>Видимо про UI недопоняли друг друга. G>Разделяю вашу точку зрения.
Дико извиняюсь — без причины наехал на человека, когда вокруг столько кандидатов... упс
G>Если пытаться вытягивать кучу связанных сущнстей из БД, то это может превратиться в огромную портянку заджойненых данных. G>Передача сериализованных объектов бдет экономичнее.
Не дошло — вы про денормализацию? Бесполезно ведь для работы с данными, разве что только для отчётов...
Или вы про грабли с выборкой части данных? Если второе — то решается кучей способов. Как правило заводитсся view типа UserOrders, который внутри себя определяет какие из заказов доступны текущему пользователю, и пишутся хранимки, что жойнят view c нужными таблицами (допустим, orders и orderdetails) и отдают нужные данные.
С точки зрения клиента в базе вообще нет данных, кроме тех что он выгребает (на самом деле и тех нет по большей части — они живут в других базах).
S>>На выходе имеем мешанину из сущностей различных типов, причём отслеживать изменения в контексте невозможно. Кэш нельзя использовать для удобной выборки локальных данных, для валидации при изменениях и для биндинга. Зачем он нужен в десктоп-клиенте? G>.OfType ? G>Для биндинга и валидации одной сущности и кеш не нужен. Достаточно одного объекта. G>Для графа надо создавать отдельный viewmodel.
Ну собстно мы и пришли к одному и тому же выводу, только я его озвучиваю слегка провокационно
Здравствуйте, kenzo_u, Вы писали:
_>Давно я не встречал технических документов, которые были написаны хуже чем этот. Уже несколько лет читаю книги и литературу на английском, но этот текст заставил меня неслабо напрягаться и перечитывать предложения и абзацы по несколько раз.
Ничего, есть и более плохой вариант
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinix, Вы писали: S>0) почему база-то будет загибаться??? ей практически всё равно сколько данных отдавать, если они хорошо нормализованы и хороший index coverage. Скорее наоборот, куча мелких обращений обойдётся дороже. S>1) у нас всё ещё десктоп клиент, так? В память выгребаются только данные, нужные клиенту. От пары тысяч сущностей он загнётся?
Не понимаю, как вы собираетесь проверить глобальную уникальность по паре тысяч сущностей. Пожалуйста, поподробнее — это может быть переворот в управлении данными!
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Если коротко, там обсуждалась только нагрузка на одного клиента, где-то рядом ещё обсуждали проблему локальной валидации и возможность сделать её декларативно силами EF.
На глобальную валидацию никто вроде не замахивался.
Есть желание — напишу кучу других неправильных букв про то, чем хороши локальные проверки.
Мы уже победили, просто это еще не так заметно...
