Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: ←Ctrl  назад   1 [2] 3   вперед  Ctrl→      все
 Re: Перестановка места в INNER JOIN-е  [new]
ambarka_max
Member

Откуда: Россия
Сообщений: 517
Обычно на диаграмме БД такие схемы имеют вид звезды или снежинки, за что и названы.

В реальности это не снежинка даже, а целый коралл.
13 май 13, 09:46    [14285915]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Testor1
View - не снижают производительность ?

Раньше я тоже пытался тяжелые селекты с джойнами перенести в View, но столкнулся с тем, что такие VIEW работают медленее в запросах, чем тем же оригинальные джойны.
14 май 13, 00:59    [14290279]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Testor1
View - не снижают производительность ?
Компиляции или запросов.
Запросов ни на капельку.
А постоянная перекопиляция сама по себе всё убъёт.
Так что поизвожительность идентичная.

А вот вероятность запросу "выпасть" на жопнутой системе чуточку выше. Но сама по себе жопнутая система - уже кранты.

Testor1
Раньше я тоже пытался тяжелые селекты с джойнами перенести в View, но столкнулся с тем, что такие VIEW работают медленее в запросах, чем тем же оригинальные джойны.
Если вы говорите о идентичных запросах - то вы скорее врёте.
Если VIEW напичкан, то 99% вы неправильно пишите VIEW, а в остальном скорее не впорядке с архитектурой.

Если у вас JOIN-ы во VIEW не LEFT, значит вы писать их не умеете. Надо понять смысл работы оптимизатора, его базовые принципы.

Да и вообще на этом жиздеца основной смысл скуля - заставить компилятор работать на себя и съекономить время на разработку и поддержку. Иначе можно и на С-ях писать.
14 май 13, 01:12    [14290300]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31780
Mnior
Testor1
Раньше я тоже пытался тяжелые селекты с джойнами перенести в View, но столкнулся с тем, что такие VIEW работают медленее в запросах, чем тем же оригинальные джойны.
Если вы говорите о идентичных запросах - то вы скорее врёте.
Есть такое, идентичные запросы из view и просто текстом ведут себя по разному, за что я и не люблю использовать view.
14 май 13, 08:42    [14290462]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
 		Mnior, коллега, поясните за неприятие "процедур с селектами".

Почему не пишите, почему считаете говнокодом?

Вот у меня за мою небольшую практику (6 лет,в основном,во всяких банках и ИК), "процедурный" подход к решению задач всегда рассматривался как что-то естесвенное.

Всякие отчеты расчитываются в теле процедур, процедуры возвращаяют датасеты для визуальных форм,бизнес логика определяется процедурами и никто не видит в этом что-либо предосудительное. Даже, иногда, целостность данных реализуется процедурами (хотя конкретно такой подход мне кажется сомнительным)
14 май 13, 09:47    [14290651]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31780
Cammomile
Mnior, коллега, поясните за неприятие "процедур с селектами".

Почему не пишите, почему считаете говнокодом?

Вот у меня за мою небольшую практику (6 лет,в основном,во всяких банках и ИК), "процедурный" подход к решению задач всегда рассматривался как что-то естесвенное.
Просто такое у Mnior видение, плюс некая категоричность в суждениях :-)

Я вот лично считаю использование вьюх и отказ от процедур говнокодом.
ИМХО использование процедур - очень хорошая сервис-ориентарованная архитектурная модель с разделением уровней СУБД-приложение.
А вьюхи не нравятся именно из за особенностей реализации, слишком много неприятных сюрпризов, хотя в принципе сама по себе идея была хорошая.
14 май 13, 11:38    [14291439]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
 		Я по комментам понял, что у Мниора какая-то своя парадигма разработки. Вот я потому и спрашиваю подробности - интересно.
14 май 13, 11:41    [14291466]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
alexeyvg
Cammomile
Mnior, коллега, поясните за неприятие "процедур с селектами".

Почему не пишите, почему считаете говнокодом?

Вот у меня за мою небольшую практику (6 лет,в основном,во всяких банках и ИК), "процедурный" подход к решению задач всегда рассматривался как что-то естесвенное.
Просто такое у Mnior видение, плюс некая категоричность в суждениях :-)

Я вот лично считаю использование вьюх и отказ от процедур говнокодом.
ИМХО использование процедур - очень хорошая сервис-ориентарованная архитектурная модель с разделением уровней СУБД-приложение.
А вьюхи не нравятся именно из за особенностей реализации, слишком много неприятных сюрпризов, хотя в принципе сама по себе идея была хорошая.

+146%
14 май 13, 12:20    [14291856]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Maxx
Member [скрыт]

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

+100500 , если что
14 май 13, 12:49    [14292060]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
alexeyvg
Я вот лично считаю использование вьюх и отказ от процедур говнокодом.
Не надо всё в кучу.
Никто здесь не говорил об отказе от процедур, а так же никто не навязывает использование вьюх из приложения.
Именно отсутствие в процедурах вьюх и копипаст одних и тех же конструкций и есть говнокод.
Более того вы, alexeyvg, знаете эту позицию, но словно перевираете мои слова.

alexeyvg
очень хорошая сервис-ориентарованная архитектурная модель с разделением уровней СУБД-приложение.
Много пафоса, "сервис-ориентарованная", "архитектурная", "разделением уровней" ...
Просто это практически единственный приемлемый по эффективности, интерфейс взаимодействия.
Но и вы и другие пользуются и прямым доступом к таблицам, так что нет никакой, ни у вас, ни у других "процедурной архитектурной модели". Нету!
Хватит тут категоричности, давайте аргументами, а всем остальным не вестись на эмоции.
Аргументы не могут быть категоричными и звучать категоричными, они могут быть не верными, не точными, не применимыми.

alexeyvg
А вьюхи ...., хотя в принципе сама по себе идея была хорошая.
Идея всё равно слабая. Вот когда можно будет изменять сразу целый датасеты одной командой и появятся декларативные триггера, тогда процедуры канут в лету.

alexeyvg
А вьюхи не нравятся именно из за особенностей реализации, слишком много неприятных сюрпризов ...

Есть такое, идентичные запросы из view и просто текстом ведут себя по разному, за что я и не люблю использовать view.
Плять, вот давайте вы возмёте свой текущий проект и все запросы завернёте в отдельную вью. А потом скажете сколько в %% соотношении хоть на бит изменилось в планах и работоспособности. Давайте, давайте. На 1% даже не наберётся, уверен. Хотя кода уменьшится минимум на 300%.
alexeyvg, давно пора избавииться от детских страхов и вздохнуть свободно и перестать ими пугать окружающих.

Вот уже который раз, или какой-то редкий баг, или невоиспроизводимый случай или просто профтыкал.
alexeyvg, намного легче оставаться на своей старой позиции и просто молоть языком.

alexeyvg
Я вот лично считаю использование вьюх и отказ от процедур говнокодом.
Никто не может декларативный код назвать говнокодом, никак, ни при каких условиях. Можно назвать неэффективным, непримелемым в текущей ситуации, но не говнокодом.
А вот тонны неподдерживаемого костылявого говна, который нельзя тронуть ибо завоняет - только это и можно назвать говнокодом.

PS: alexeyvg, троолинг засчитан.
14 май 13, 17:17    [14294423]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
 		А есть что по моему вопросу? Я не тролю же, мне же правда интересно какие подходы позволяют эффективно отказаться от процек.
14 май 13, 17:41    [14294620]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Cammomile
А есть что по моему вопросу?
Какому вопросу? Вы либо переводите тему или не поняли что я написал.
Писал чётко: "много join-в в процедурах, процедуры без view - говнокод".
Почему? Тоже писал: "копипаст - зло".

Почему у меня свербит в одном месте про говнокод? По тем же причина что и у alexeyvg свербит про view: что у ково болит, тот ...
Много проектов перенимал(ю) и поддерживал(ю) и было время поиграться с разными вариантами.
С одной стороны "наша архитектура рулез", а с другой лимон раз в день "не трогай этот костыль". Какая нафиг объективность?!
А на вопрос:
- А почему не юзали то-то, чтоб не писать код занимающий 30% от всего проекта?
- А там что-то не пошло
- Так это делается так-то
- Ой, не было времени разбираться так глубоко.
Какая нафиг объективность?! Если ты решаешь проблему по быстрому, не вдаёшься в детали, не епёшься с разными вариантами дохрена времени, то как можно называть себя специалистом?
Споры удел усидчивых и упёртых, у остальных сухое IMXO.
На IMXO надо смотреть через призму характеров.

Если писать нормально, а так у некоторых получается, поверьте. То писать тонны процедур ради наитупейшего селекта/инсерта - нет особого смысла. В итоге половины процедур просто нет.
Это не говоря что представления (параметризованные или нет) это тоже механизм контроля на уровне приложения - не мутабельность (в отличие от EXEC). Но никто не запрещает их писать. Пишите.
У процедур тоже есть неприятные вещи, включая интерфейс вызова. EXEC в селект не засунешь.

А спорить триггера или процедуры - оффтоп, лучше подымите старые темы.

Cammomile
Вот у меня за мою небольшую практику (6 лет,в основном,во всяких банках и ИК
Разные конторы работают по разному и стратегии бизнеса кардинально разные, противоположные можно сказать.
И есть где "А давайте наколбасим и продадим, а любое изменение - это кардинальная переделка - больше бабла"
А есть где каждый день постоянное расширение функционала, а отсуствие эффективного контроля жизненого цикла во всей инфраструктуре - смерть.

Так что "практика N лет в отрасли X" ничего не говорит.
Что я не вижу и меня это расстраивает так это нормальные дебаты разрабов. Которые не просто еле успевают клепать говнокод, а озабочены правильными подходами, инструментами и их реализацией, направлением развития отрасли и т.п. и со всеми деталями. Мы должны не только досконально понимать как этим можно пользоваться, а как оно фунчиклирует и как должно быть построено в отрыве от существующего.
А в итоге, или ты тупой птушник работающий в какой-то Митсубиши Банк Груп и плевать хотел на семантику языка, а сдругой прафффессор Принстона и плевать хотел как этой загогулиной будут пользоваться теже пэтэушники.
Замкнутый круг идиотизма. Цирк абсурда. Всем пох, над пропастью во ржи
14 май 13, 20:42    [14295429]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Knyazev Alexey
Member

Откуда: Екб -> Мск
Сообщений: 10234
Блог
Mnior
Замкнутый круг идиотизма. Цирк абсурда. Всем пох, над пропастью во ржи


спасибо, прочитал с удовольствием...жаль, но так есть и будет (
14 май 13, 20:56    [14295476]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
 		а я вот люблю тех, кто строит правильные предложения
у них есть сущности, обобщенные представления, доступ к данным через них же - универсальных
зачем писать стопицот запросов со сложными (временами) джойнами?
Можно написать представление, которое собирает сущность из таблиц - и использовать в запросах уже его, а не возится каждый раз со структурой.
Еще можно, скажем, разделять представления-сущности по "местам применения"
например представление, предлоставляющее базовый (опорный) список идентификаторов сущностей, и второе представление - предоставляющее детализацию сущности.
Естественно, оба этих представления должны базироваться на общем базовом представлении "сущность".
14 май 13, 21:11    [14295553]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31780
Mnior
Но и вы и другие пользуются и прямым доступом к таблицам, так что нет никакой, ни у вас, ни у других "процедурной архитектурной модели". Нету!
С чего такие утверждения???

Я (в те времена, когда имел какое то отношение к клиентским приложениям, сейчас я работаю только с сиквелом) использовал в проектах микрософтовские Enterprise Template Library (несколько модифицированные, как собственно всегда и происходит, это же темплейты, а не библиотека).
Так там просто не было технической возможности что то сделать с СУБД, кроме как вызвать процедуру (это было осознанное ограничение нашей архиртектуры). Зато вот это (вызов процедуры и получение результата) делалось бескоспромиссно быстро, насколько это вообще возможно... И с очень, очень минимальными затратами труда программиста, при сохранении правильной обработки типов и т.п. !

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

Mnior
Никто не может декларативный код назвать говнокодом, никак, ни при каких условиях. Можно назвать неэффективным, непримелемым в текущей ситуации, но не говнокодом.
А вот тонны неподдерживаемого костылявого говна, который нельзя тронуть ибо завоняет - только это и можно назвать говнокодом.
Опять только пустые слова, декларации...

"Декларативный подход" - это что подразумевается конкретно? Это лапша кода на императивном ЯП с вхреначаенными внутрь запросами, конструируемыми из кусочков строк?

"Говнокод", "лапшекод", "тонны неподдерживаемого костылявого говна" можно написать на любом языке и пользуясь любой парадигмой программирования, я вас уверяю.

Разделение приложения на слои, о котором я говорил, имеет хотя бы то неоспоримое преимущество, что код работы с данными на стороне СУБД может писать специалист, или хотя бы контролировать написание, или хотя бы поправить "после", хотя бы через годы.

А вот с лапшекодом с прямым доступом к таблицам поделать будет что то сложно. И не забывайте - с лапшекодом на разных языках, написанными разными людьми. которых уже давно нету, потому что время жизни СУБД больше жизни клиентских приложений, да и приложений этих пишется на одну СУБД много.
14 май 13, 21:42    [14295687]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
 		От специалиста я ожидал ответ в другом ключе. Некую аналитику в виде: 

Задачи типа "а" решаются: 
1...
2...
3 процедурами
4 представлениями 

Если мы используем процедуру то плюсы ... , а минусы ...  поэтому такие задачи лучше решать через... 

Задачи типа "б" решаются: 
1...
2...
3 процедурами
4 представлениями 


Если мы используем процедуру то плюсы ... , а минусы ...  поэтому такие задачи лучше решать через... 


Задачи типа "икс" .... 


ИТОГО: на  задачах ...  лучше использовать ..., а на задачах ... лучше то , общи счет K-M в пользу представлений, победили представления!



А что плохо писать плохой код и хорошо хороший все и так понимают.
15 май 13, 00:29    [14296349]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
 		Cammomile,

серебряной пули - не бывает
если задачу в принципе можно решить при помощи скуля, то решается это с использованием процедур, без использования процедур.... роли особой не имеет
Имеет значение только радиус кривизны рук того человека, который решает оную задачу
15 май 13, 02:35    [14296539]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Cammomile
От специалиста я ожидал ответ в другом ключе.
Много вы хотите.
В принципе мы это всё вместе с присуствующими уже описывали. Но только размазано шо песец по постам разных тем.
Ни у меня ни тем более у alexeyvg нет желания это искать заново.
locky довольно внятно написал. А я обычно начинаю все детали перечислять - что превращается в каламбур и всех путает.

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

Из последнего можно добавить в копилку, что MS сильно расширило типы индексирования. И индекс на представлениях упрощают иногда жизнь при малых затратах. Это (виды индексировния) кстати дало сильное понимание что к чему.
Более того, многие хотят им управлять в самих запросах (спулинг).

PS: Спасибо что ответили, ибо накатывал довольно большой ответ на 14295687. Тролюсь легко.
15 май 13, 02:41    [14296544]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
 		Да причем тут серебрянная пуля? Мне говорят что есть новая парадигма, я ее пытаюсь понять, но внятных ответов не вижу. Серебрянная это пуля или говенная вообще к вопросу отношения не имеет.

Ладно, сузим рамки.

Как вы уходите от процедур когда надо не давать данные, а СОЗДАВАТЬ.

Любая бизнес логика. Завели сделку, посчтитали то, сё, пятое, десятое, нагенерили проводок, записали раскидали комиссии по счетам, вот это вот все? Функции вместо процедур? Какие-то магические вьюхи?

Или предполагается что бизнес логика ТОЛЬКО на клиенте, а сервер только хранит и возвращает данные ?
15 май 13, 10:00    [14297020]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Cammomile
Мне говорят что есть новая парадигма
Где это?
Вас жестоко обманули, не ведитесь на троллинг.
Cammomile
Любая бизнес логика. Завели сделку, посчтитали то, сё, пятое, десятое, нагенерили проводок, записали раскидали комиссии по счетам, вот это вот все? Функции вместо процедур? Какие-то магические вьюхи?
alexeyvg, перелогинтесь.
Cammomile
Или предполагается что бизнес логика ТОЛЬКО на клиенте, а сервер только хранит и возвращает данные ?
И где тут новая парадигма? Стандартный случай в инете.
15 май 13, 13:05    [14298638]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
 		Новая для меня! У мну всю дорогу бизнес логика делается на сервере эскуэль и я вижу этому стопицот логических обоснований.

И непонятно как уйти от процедур и заменить их на вьюхи в подобном разрезе.

Собственно это я и пытаюсь узнать.
15 май 13, 13:18    [14298769]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Cammomile
Новая для меня! У мну всю дорогу бизнес логика делается на сервере эскуэль и я вижу этому стопицот логических обоснований.

И непонятно как уйти от процедур и заменить их на вьюхи в подобном разрезе.

Собственно это я и пытаюсь узнать.

3-tier, app server, Entity Framework, Linq2Sql, что там еще....
Полно вариантов не использовать SP
15 май 13, 15:21    [14299840]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
 		Но ведь коллега Мниор не делал же заявлений что "меняем процки на линку"

(линку кстати в топку сразу)
15 май 13, 15:26    [14299875]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Cammomile
Но ведь коллега Мниор не делал же заявлений что "меняем процки на линку"

(линку кстати в топку сразу)

линку всего навсего "еще один способ сгенерировать скл запрос"
я с таким же успехом могу продолжать писать запросы, оформляя их не процедурами на сервере, а, скажем, ресурсами в приложении - и приложение будет использовать эти запросы практически точно так же, как и SP
15 май 13, 15:59    [14300220]     Ответить | Цитировать Сообщить модератору
 Re: Перестановка места в INNER JOIN-е  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31780
locky
Cammomile
Новая для меня! У мну всю дорогу бизнес логика делается на сервере эскуэль и я вижу этому стопицот логических обоснований.

И непонятно как уйти от процедур и заменить их на вьюхи в подобном разрезе.

Собственно это я и пытаюсь узнать.

3-tier, app server, Entity Framework, Linq2Sql, что там еще....
Полно вариантов не использовать SP
ИМХО первое немного не то, как 3-tier и app server связаны с использованием или неиспользованием SP?

Entity Framework и Linq2Sql да, архитектурно абсолютный эквивалент встраивания запросов к СУБД в код проги на обычном ЯП.
15 май 13, 18:07    [14301208]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: ←Ctrl  назад   1 [2] 3   вперед  Ctrl→      все
Все форумы / Microsoft SQL Server Ответить