H>Так в том и вопрос. Что именно? H>Мне интересен визуал, графика и симуляции физики. Потому что это красиво, вау-эффектно и прочее. Сразу виден результат. H>Мне НЕ интересно, но я могу понять в чем интерес, например, у безопасников и сетевиков.
и чего там интересного ? тупо настукивать формулы в виде кода — так там и денег не платят, т.к. переложить формула на код и миды за скромную зп справляются.
H>Но я в упор не могу понять что может быть интересно в этих идиотских огромных таблицах
там хотя бы бигдата кластера, распределенные вычисления, те же ML модели гонять — там и архитектуру не каждый сдюжит и зарплаты ответствуют сложности задачи. а простите физ процесс нажмякать в постсовковом институте небойсь и на пиво не заработать.
Блин.
Мартин Фаулер писал про рефакторинг, писал и переписывал...
И все псу под хвост.
Простой сермяжный программер поклал на все...
А тебе теперь разгребать!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, gandjustas, Вы писали:
H>>Блин, трындец. БАЗЫ ДАННЫХ!!! Люди, КАК это может быть интересно??! Единсивенный предмет в вузе который еле смог
G>Платят денег не за то, чтобы тебе было интересно. И есть люди, которые смогли.
Я их люблю бескорыстно и непрофессионально. Может, потому что бойсами и коддами в детстве не насиловали, а нормализация представлялась мне просто интересной головоломкой.
LVV>Простой сермяжный программер поклал на все... LVV>А тебе теперь разгребать!
прикол в том, что на линкью2секвил посложили задачу разрулить селект. на сиквеле я бы сделал одним. он же по сути в цикле хреначит. да. селекты дешевые. но их до жопы )
Здравствуйте, Sharov, Вы писали:
S>Ну как бэ основа -- без бд ни банки, ни интернет сайты не работали бы. В сущности все нагруженные приложения, а это тоже очень интересно, S>каким-то образом используют бд. Это может быть стандартные реляционные бд (acid) и их тюнинг, это могут быть eventual consistency nosql S>бд и умение их использовать и настраивать. Т.е. миллионы людей ежедневно пользуются результатом твоего труда. И там куча нюансов S>и при взаимодействии с железом, чтобы все это делалось эффективно. Т.е. по сути, бд -- это основа практически всех компьютерных программ, S>за исключением, разве что, игр. Да и тот же steam без бд никуда. Опять же облака -- это масштабируемые бд, спец. хранилища типа s3 со S>своими свойствами и т.п. Короче, все с чем люди каждодневно взаимодействует в интернете и на мобиле имеют свою бд, т.е. по сути S>взаимодействие с бд + какая-то бизнес логика.
А еще в БД применяются те самые алгоритмы, на которых дрочат FAANG и их адепты. там тебе и деревья всех видов, и сортировки, и хэши, синтаксические деревья и их переписывание, алгоритмы выбора, асинхронщина, параллельность и конкурентность. По сути современные РСУБД это венец развития всего computer science.
Здравствуйте, gandjustas, Вы писали:
G>Лучше уж такой код, чем эквивалентные простыни SQL.
Разумеется, это не так. (Обычно такие утвеждения делают люди, которые не работали с "серьезными" (по объему, по структуре и т.д.) БД. без обид.)
При работе сконкретной БД, любой, главная — это эта самая любая БД.
Все эти ОРМ — весчь опосредованная. По другому и быть не может.
В каких то ситуациях они да — берут на себя часть рутинной работы (например сгерерировать селект в целевом языке из 100 полей),
но главным остается все равно — движек конкретной БД.
(Это все следствие того, что все мало-мальски используемые движки БД на всем, что чуть сложнее прямого селекта из таблицы,
начинают иметь свои собственные особенности, и естеснно ни какой "волшебный" ОРМ не сможет это учесть, а главное — и не должен.
у него функция другая — просто сгенерировать че-то рутинное, где это можно. Что б руками это не писать.)
Здравствуйте, Igorxz, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>Лучше уж такой код, чем эквивалентные простыни SQL. I>Разумеется, это не так. (Обычно такие утвеждения делают люди, которые не работали с "серьезными" (по объему, по структуре и т.д.) БД. без обид.) I>При работе сконкретной БД, любой, главная — это эта самая любая БД. I>Все эти ОРМ — весчь опосредованная. По другому и быть не может. I>В каких то ситуациях они да — берут на себя часть рутинной работы (например сгерерировать селект в целевом языке из 100 полей), I>но главным остается все равно — движек конкретной БД. I>(Это все следствие того, что все мало-мальски используемые движки БД на всем, что чуть сложнее прямого селекта из таблицы, I>начинают иметь свои собственные особенности, и естеснно ни какой "волшебный" ОРМ не сможет это учесть, а главное — и не должен. I>у него функция другая — просто сгенерировать че-то рутинное, где это можно. Что б руками это не писать.)
И что ты предлагаешь? переписать простыни linq на рукопашный SQL?
Я предлагаю посмотреть запрос, который генеируется, поправить linq, чтобы он не генерировал то, что мешает оптимизации и создать подходящие индексы.
Разница в затратах примерно на два порядка в пользу второго варианта. Возможно по итогу будет не так оптимально для конкретного варианта запроса, но в целом можно быстродействие довести до приемлемого без переписывания всего.
Здравствуйте, gandjustas, Вы писали:
G>И что ты предлагаешь? переписать простыни linq на рукопашный SQL? G>Я предлагаю посмотреть запрос, который генеируется, поправить linq, чтобы он не генерировал то, что мешает оптимизации и создать подходящие индексы.
G>Разница в затратах примерно на два порядка в пользу второго варианта. Возможно по итогу будет не так оптимально для конкретного варианта запроса, но в целом можно быстродействие довести до приемлемого без переписывания всего.
Что я предлагаю где/для чего? Для конкретной ситуации? — я её не знаю. Может там база из трех таблиц и этот приведенный кусок — полприложения))
Моя реплика была на твое утверждение "Лучше уж такой код, чем эквивалентные простыни SQL.".
С моей точки зрения, в общем случае — это зло.
G>И что ты предлагаешь? переписать простыни linq на рукопашный SQL? G>Я предлагаю посмотреть запрос, который генеируется, поправить linq, чтобы он не генерировал то, что мешает оптимизации и создать подходящие индексы.
G>Разница в затратах примерно на два порядка в пользу второго варианта. Возможно по итогу будет не так оптимально для конкретного варианта запроса, но в целом можно быстродействие довести до приемлемого без переписывания всего.
как ты предлагаешь поправиль линкью? чтоб он здесь тебе грамотный запрос построил с минимумом джойнов и вхере?
ты погляди — тут в цикле к базе обращения идут!
H>Бугага. Ага. Кто-то просто больше по матану и дифурам, а эти говно-алгоритмики ага, ниасилил
сказал матанщик наасилифший элементарную реалиционню алгебру... это те не поклоны бить, понятно
H>>Бугага. Ага. Кто-то просто больше по матану и дифурам, а эти говно-алгоритмики ага, ниасилил U>сказал матанщик наасилифший элементарную реалиционню алгебру... это те не поклоны бить, понятно
Ну ты большого о себе мнения
Я сказал — что это максимально уныло — и все.
H>Ну ты большого о себе мнения H>Я сказал — что это максимально уныло — и все.
я не кичусь матано. нет никакой разницы кроме паттернов
как к задаче подходить.
скучнее задача? возможно. только все они давно решены и гуглятся при желании
разнообразие только в человеческой тупости. как тут. но и это наскучивает. и кроме раздражения эмоций не вызывает.
H>Куда ж без упоминания поклонов-то, ага.
Gt_>и чего там интересного ? тупо настукивать формулы в виде кода — так там и денег не платят, т.к. переложить формула на код и миды за скромную зп справляются.
на пхп их кстати настукивать — занятие сильно на любителя...
Gt_>там хотя бы бигдата кластера, распределенные вычисления, те же ML модели гонять — там и архитектуру не каждый сдюжит и зарплаты ответствуют сложности задачи. а простите физ процесс нажмякать в постсовковом институте небойсь и на пиво не заработать.
уверен, что тут тоже больше страшных слов, чем содержания...
G>>И что ты предлагаешь? переписать простыни linq на рукопашный SQL? G>>Я предлагаю посмотреть запрос, который генеируется, поправить linq, чтобы он не генерировал то, что мешает оптимизации и создать подходящие индексы.
G>>Разница в затратах примерно на два порядка в пользу второго варианта. Возможно по итогу будет не так оптимально для конкретного варианта запроса, но в целом можно быстродействие довести до приемлемого без переписывания всего.
U>как ты предлагаешь поправиль линкью? чтоб он здесь тебе грамотный запрос построил с минимумом джойнов и вхере?
Минимум джоинов он и так сделает.
Меня смущают:
— лишние инклуды, скорее всего их выкинет и так
— вложенные коллекции в select, возможно их стоит отдельными запросами собрать
— посмотреть во что превращаются in с учетом конкретной субд
— очевидно проверить планы на популярных вариантах запросов, индексы и настройки движка (если это не mssql)
— заменить ToArrayAsync на ToAsyncEnumerable, чтобы не ждать втягивания всех данных до начала отображения
— посмотреть зачем нужен странный where после ToArrayAsync, почему его нельзя в запрос включить, если можно, то goto пункт про планы
— если уж совсем linq не справляется с запросами, то переписать на функции\представления в SQL и опиратьсяв первую очередь на них
U>ты погляди — тут в цикле к базе обращения идут!
Я не увидел, может не очень внимательно смотрел
С>У меня ощущение, что вы либо пьяны, либо не высыпались месяц.
еще по ходу один... складывается ощущение, вникать в бд ща не камильфо.
если честно несколько шокирует... хотя че удивляюсь. вон лид у меня сиквел даже в стандарте дальше лефт джойна не знает. и не хочет знать ну у меня с джава скрипт та же хрень. угнетает
