Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 вперед Ctrl→ все |
ambarka_max Member Откуда: Россия Сообщений: 517 |
В реальности это не снежинка даже, а целый коралл. |
||
13 май 13, 09:46 [14285915] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
|
||
14 май 13, 00:59 [14290279] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Запросов ни на капельку. А постоянная перекопиляция сама по себе всё убъёт. Так что поизвожительность идентичная. А вот вероятность запросу "выпасть" на жопнутой системе чуточку выше. Но сама по себе жопнутая система - уже кранты.
Если VIEW напичкан, то 99% вы неправильно пишите VIEW, а в остальном скорее не впорядке с архитектурой. Если у вас JOIN-ы во VIEW не LEFT, значит вы писать их не умеете. Надо понять смысл работы оптимизатора, его базовые принципы. Да и вообще на этом жиздеца основной смысл скуля - заставить компилятор работать на себя и съекономить время на разработку и поддержку. Иначе можно и на С-ях писать. |
||||
14 май 13, 01:12 [14290300] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31780 |
|
||||
14 май 13, 08:42 [14290462] Ответить | Цитировать Сообщить модератору |
Cammomile Member Откуда: Сообщений: 1214 |
Mnior, коллега, поясните за неприятие "процедур с селектами". Почему не пишите, почему считаете говнокодом? Вот у меня за мою небольшую практику (6 лет,в основном,во всяких банках и ИК), "процедурный" подход к решению задач всегда рассматривался как что-то естесвенное. Всякие отчеты расчитываются в теле процедур, процедуры возвращаяют датасеты для визуальных форм,бизнес логика определяется процедурами и никто не видит в этом что-либо предосудительное. Даже, иногда, целостность данных реализуется процедурами (хотя конкретно такой подход мне кажется сомнительным) |
14 май 13, 09:47 [14290651] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31780 |
Я вот лично считаю использование вьюх и отказ от процедур говнокодом. ИМХО использование процедур - очень хорошая сервис-ориентарованная архитектурная модель с разделением уровней СУБД-приложение. А вьюхи не нравятся именно из за особенностей реализации, слишком много неприятных сюрпризов, хотя в принципе сама по себе идея была хорошая. |
||
14 май 13, 11:38 [14291439] Ответить | Цитировать Сообщить модератору |
Cammomile Member Откуда: Сообщений: 1214 |
Я по комментам понял, что у Мниора какая-то своя парадигма разработки. Вот я потому и спрашиваю подробности - интересно. |
14 май 13, 11:41 [14291466] Ответить | Цитировать Сообщить модератору |
tpg Member Откуда: Novosibirsk Сообщений: 23902 |
+146% |
||||
14 май 13, 12:20 [14291856] Ответить | Цитировать Сообщить модератору |
Maxx Member [скрыт] Откуда: Сообщений: 24290 |
tpg, +100500 , если что |
14 май 13, 12:49 [14292060] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Никто здесь не говорил об отказе от процедур, а так же никто не навязывает использование вьюх из приложения. Именно отсутствие в процедурах вьюх и копипаст одних и тех же конструкций и есть говнокод. Более того вы, alexeyvg, знаете эту позицию, но словно перевираете мои слова.
Просто это практически единственный приемлемый по эффективности, интерфейс взаимодействия. Но и вы и другие пользуются и прямым доступом к таблицам, так что нет никакой, ни у вас, ни у других "процедурной архитектурной модели". Нету! Хватит тут категоричности, давайте аргументами, а всем остальным не вестись на эмоции. Аргументы не могут быть категоричными и звучать категоричными, они могут быть не верными, не точными, не применимыми.
alexeyvg, давно пора избавииться от детских страхов и вздохнуть свободно и перестать ими пугать окружающих. Вот уже который раз, или какой-то редкий баг, или невоиспроизводимый случай или просто профтыкал. alexeyvg, намного легче оставаться на своей старой позиции и просто молоть языком.
А вот тонны неподдерживаемого костылявого говна, который нельзя тронуть ибо завоняет - только это и можно назвать говнокодом. PS: alexeyvg, троолинг засчитан. |
||||||||||
14 май 13, 17:17 [14294423] Ответить | Цитировать Сообщить модератору |
Cammomile Member Откуда: Сообщений: 1214 |
А есть что по моему вопросу? Я не тролю же, мне же правда интересно какие подходы позволяют эффективно отказаться от процек. |
14 май 13, 17:41 [14294620] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Писал чётко: "много join-в в процедурах, процедуры без view - говнокод". Почему? Тоже писал: "копипаст - зло". Почему у меня свербит в одном месте про говнокод? По тем же причина что и у alexeyvg свербит про view: что у ково болит, тот ... Много проектов перенимал(ю) и поддерживал(ю) и было время поиграться с разными вариантами. С одной стороны "наша архитектура рулез", а с другой лимон раз в день "не трогай этот костыль". Какая нафиг объективность?! А на вопрос:
Споры удел усидчивых и упёртых, у остальных сухое IMXO. На IMXO надо смотреть через призму характеров. Если писать нормально, а так у некоторых получается, поверьте. То писать тонны процедур ради наитупейшего селекта/инсерта - нет особого смысла. В итоге половины процедур просто нет. Это не говоря что представления (параметризованные или нет) это тоже механизм контроля на уровне приложения - не мутабельность (в отличие от EXEC). Но никто не запрещает их писать. Пишите. У процедур тоже есть неприятные вещи, включая интерфейс вызова. EXEC в селект не засунешь. А спорить триггера или процедуры - оффтоп, лучше подымите старые темы.
И есть где "А давайте наколбасим и продадим, а любое изменение - это кардинальная переделка - больше бабла" А есть где каждый день постоянное расширение функционала, а отсуствие эффективного контроля жизненого цикла во всей инфраструктуре - смерть. Так что "практика N лет в отрасли X" ничего не говорит. Что я не вижу и меня это расстраивает так это нормальные дебаты разрабов. Которые не просто еле успевают клепать говнокод, а озабочены правильными подходами, инструментами и их реализацией, направлением развития отрасли и т.п. и со всеми деталями. Мы должны не только досконально понимать как этим можно пользоваться, а как оно фунчиклирует и как должно быть построено в отрыве от существующего. А в итоге, или ты тупой птушник работающий в какой-то Митсубиши Банк Груп и плевать хотел на семантику языка, а сдругой прафффессор Принстона и плевать хотел как этой загогулиной будут пользоваться теже пэтэушники. Замкнутый круг идиотизма. Цирк абсурда. Всем пох, над пропастью во ржи |
||||||
14 май 13, 20:42 [14295429] Ответить | Цитировать Сообщить модератору |
Knyazev Alexey Member Откуда: Екб -> Мск Сообщений: 10234 Блог |
спасибо, прочитал с удовольствием...жаль, но так есть и будет ( |
||
14 май 13, 20:56 [14295476] Ответить | Цитировать Сообщить модератору |
locky Member Откуда: Харьков, Украина Сообщений: 62034 |
а я вот люблю тех, кто строит правильные предложения у них есть сущности, обобщенные представления, доступ к данным через них же - универсальных зачем писать стопицот запросов со сложными (временами) джойнами? Можно написать представление, которое собирает сущность из таблиц - и использовать в запросах уже его, а не возится каждый раз со структурой. Еще можно, скажем, разделять представления-сущности по "местам применения" например представление, предлоставляющее базовый (опорный) список идентификаторов сущностей, и второе представление - предоставляющее детализацию сущности. Естественно, оба этих представления должны базироваться на общем базовом представлении "сущность". |
14 май 13, 21:11 [14295553] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31780 |
Я (в те времена, когда имел какое то отношение к клиентским приложениям, сейчас я работаю только с сиквелом) использовал в проектах микрософтовские Enterprise Template Library (несколько модифицированные, как собственно всегда и происходит, это же темплейты, а не библиотека). Так там просто не было технической возможности что то сделать с СУБД, кроме как вызвать процедуру (это было осознанное ограничение нашей архиртектуры). Зато вот это (вызов процедуры и получение результата) делалось бескоспромиссно быстро, насколько это вообще возможно... И с очень, очень минимальными затратами труда программиста, при сохранении правильной обработки типов и т.п. ! Прямые обращения к таблицам помню только как использование Bulk или потоковой загрузки из приложения, это уже вынужденно, для скорости загрузки больших данных. Это исключения, и было далеко не во всех проектах.
"Декларативный подход" - это что подразумевается конкретно? Это лапша кода на императивном ЯП с вхреначаенными внутрь запросами, конструируемыми из кусочков строк? "Говнокод", "лапшекод", "тонны неподдерживаемого костылявого говна" можно написать на любом языке и пользуясь любой парадигмой программирования, я вас уверяю. Разделение приложения на слои, о котором я говорил, имеет хотя бы то неоспоримое преимущество, что код работы с данными на стороне СУБД может писать специалист, или хотя бы контролировать написание, или хотя бы поправить "после", хотя бы через годы. А вот с лапшекодом с прямым доступом к таблицам поделать будет что то сложно. И не забывайте - с лапшекодом на разных языках, написанными разными людьми. которых уже давно нету, потому что время жизни СУБД больше жизни клиентских приложений, да и приложений этих пишется на одну СУБД много. |
||||
14 май 13, 21:42 [14295687] Ответить | Цитировать Сообщить модератору |
Cammomile Member Откуда: Сообщений: 1214 |
От специалиста я ожидал ответ в другом ключе. Некую аналитику в виде: Задачи типа "а" решаются: 1... 2... 3 процедурами 4 представлениями Если мы используем процедуру то плюсы ... , а минусы ... поэтому такие задачи лучше решать через... Задачи типа "б" решаются: 1... 2... 3 процедурами 4 представлениями Если мы используем процедуру то плюсы ... , а минусы ... поэтому такие задачи лучше решать через... Задачи типа "икс" .... ИТОГО: на задачах ... лучше использовать ..., а на задачах ... лучше то , общи счет K-M в пользу представлений, победили представления! А что плохо писать плохой код и хорошо хороший все и так понимают. |
15 май 13, 00:29 [14296349] Ответить | Цитировать Сообщить модератору |
locky Member Откуда: Харьков, Украина Сообщений: 62034 |
Cammomile, серебряной пули - не бывает если задачу в принципе можно решить при помощи скуля, то решается это с использованием процедур, без использования процедур.... роли особой не имеет Имеет значение только радиус кривизны рук того человека, который решает оную задачу |
15 май 13, 02:35 [14296539] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
В принципе мы это всё вместе с присуствующими уже описывали. Но только размазано шо песец по постам разных тем. Ни у меня ни тем более у alexeyvg нет желания это искать заново. locky довольно внятно написал. А я обычно начинаю все детали перечислять - что превращается в каламбур и всех путает. Скажу лишь что по моим наблюдениям, если вы усидчивы и может дофига времени потратить на одну задачу и мусолить и обсасывать её до опупения, до вы сами придёте к тому что говорил locky-и. Из последнего можно добавить в копилку, что MS сильно расширило типы индексирования. И индекс на представлениях упрощают иногда жизнь при малых затратах. Это (виды индексировния) кстати дало сильное понимание что к чему. Более того, многие хотят им управлять в самих запросах (спулинг). PS: Спасибо что ответили, ибо накатывал довольно большой ответ на 14295687. Тролюсь легко. ![]() |
||
15 май 13, 02:41 [14296544] Ответить | Цитировать Сообщить модератору |
Cammomile Member Откуда: Сообщений: 1214 |
Да причем тут серебрянная пуля? Мне говорят что есть новая парадигма, я ее пытаюсь понять, но внятных ответов не вижу. Серебрянная это пуля или говенная вообще к вопросу отношения не имеет. Ладно, сузим рамки. Как вы уходите от процедур когда надо не давать данные, а СОЗДАВАТЬ. Любая бизнес логика. Завели сделку, посчтитали то, сё, пятое, десятое, нагенерили проводок, записали раскидали комиссии по счетам, вот это вот все? Функции вместо процедур? Какие-то магические вьюхи? Или предполагается что бизнес логика ТОЛЬКО на клиенте, а сервер только хранит и возвращает данные ? |
15 май 13, 10:00 [14297020] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Вас жестоко обманули, не ведитесь на троллинг.
|
||||||
15 май 13, 13:05 [14298638] Ответить | Цитировать Сообщить модератору |
Cammomile Member Откуда: Сообщений: 1214 |
Новая для меня! У мну всю дорогу бизнес логика делается на сервере эскуэль и я вижу этому стопицот логических обоснований. И непонятно как уйти от процедур и заменить их на вьюхи в подобном разрезе. Собственно это я и пытаюсь узнать. |
15 май 13, 13:18 [14298769] Ответить | Цитировать Сообщить модератору |
locky Member Откуда: Харьков, Украина Сообщений: 62034 |
3-tier, app server, Entity Framework, Linq2Sql, что там еще.... Полно вариантов не использовать SP |
||
15 май 13, 15:21 [14299840] Ответить | Цитировать Сообщить модератору |
Cammomile Member Откуда: Сообщений: 1214 |
Но ведь коллега Мниор не делал же заявлений что "меняем процки на линку" (линку кстати в топку сразу) |
15 май 13, 15:26 [14299875] Ответить | Цитировать Сообщить модератору |
locky Member Откуда: Харьков, Украина Сообщений: 62034 |
линку всего навсего "еще один способ сгенерировать скл запрос" я с таким же успехом могу продолжать писать запросы, оформляя их не процедурами на сервере, а, скажем, ресурсами в приложении - и приложение будет использовать эти запросы практически точно так же, как и SP |
||
15 май 13, 15:59 [14300220] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31780 |
Entity Framework и Linq2Sql да, архитектурно абсолютный эквивалент встраивания запросов к СУБД в код проги на обычном ЯП. |
||||
15 май 13, 18:07 [14301208] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |