Дилема. Есть главная таблица и завищясие от нее 15, из

кауждой нужно вытащить все данные по внешнему ключу из главной таблицы. Т е на одну строку из главной таблицы нажно залезть во все зависимые и найти все имеющиеся данные по внешнему ключу. Проблема в том, что когда в главной таблице 170_000 записей, то все происходит не быстро. На данный момент приложение обращается к каждой зависимой таблице отдельным запросом на выборку. Это, конечно медленнее, чем одним запросом. Однако, если выбирать все одним запросом черз join, то база вернет кучу лишних данных из-за дубликатов выборки, что тоже может повлиять на производительность. Так вот какой вариант лучше выбрать мне? Возможно есть способы заставить базу не дублировать данные при выборке через join?

сделать все те запросы, что делаются отдельно, в один запрос переписать.

Не факт. Иногда много мелких запросов лучше одного медленного. Всё по ситуации

Замени джоины на apply, это поможет тебе от дублей избавиться, там уже сам решай как тебе надо или distinct или top 1 какой-нибудь. А вообще надо тестировать и сравнить результаты, ну и планы смотреть.

именно, что иногда

нет, почему это неизбежно?

SELECT A.name, B.car_number FROM A JOIN B ON A.id=B.parent_id В таблице B на каждый внешний ключ по 30 записей, а это значит, что в выходной таблице будет в первом столбце 30 раз одно и тоже имя

для этого есть cross apply и outer apply

Ну мне по сути нужно вернуть одну запись на группу значений без потери через distinct, они это могут реализовать.. Точно это можно реализовать в документных базах, но у нас реляционная

вы там можете сделать чего пожелаете, хоть 1, хоть 10

Потери значений из зависимой таблицы не будет?

как захотите так и будет

Ладно, ознакомлюсь, спасибо)

Спасибо, попробую применить)

NIX
Я не совсем понял, как мне может помочь apply из е...

https://dba.stackexchange.com/questions/173831/convert-right-side-of-join-of-many-to-many-into-array

Вот, это похоже на решение моей проблемы, надо только посмотреть, что выводит)

NIX
Я не совсем понял, как мне может помочь apply из е...

телепатов здесь нет, про json вы не говорили. все можно сделать и через apply как я писал выше, но лучше посмотреть функционал работы с json в sql

Я уже писал, что мне не обязателен на выходе json, это лишь пример без дубликатов

вы понимаете что никто полностью один стандарт sql не поддерживает на 100%, и конструкция apply в pg это LATERAL, т.е. синтаксис ВСЕ РАВНО отличается. на больших объемах маршаллинг у вас будет очень дорог вместо того, чтобы из пг или ms sql получать готовый сформированный json.

Эту проблему уже решили, конкретными пакетами для ef core

вам еще много предстоит узнать про волшебный мир ORM.

нет, он хочет унифицированый запрос - на языке стандарт скуель, это невозможно

теоретически возможно

Ну почему вы такие упрямые, при чем тут sql ,я использую orm. Ну если вы не разбираетесь в теме, то что говорить?

Так и используй возможности ОРМ раз ты не понимаешь SQL

орм по твоему твои линкю запросы во что превращает?

судя по твоим речам, тут многие работать начали до того как ты родился %) уж поверь, не в теме пока что ты, а не мы %)

когда ты тянешь context.Users.Include(u => u.Orders) это парсится в обычный лефт джойн скуель. и соответсвтенно уже твой клиент убирает так нызываемые"дубли"

Ну так он их превращает, взависимости от базы, так при чем тут запрос на sql под все субд? Ты сам-то подусай что пишешь

в том что в ефе не реализованы ВСЕ МЕТОДЫ ВСЕХ БАЗ парсится только то что общее, в стандарт-скуель. Все остальное на стороне клиента.

чувак, у тебя на 170 тыщах строк уже все раком встало так что это тебе надо подумать что в твоей архитектуре не так и что ты не так в книжках прочитал %)

Так я и хочу на этом общем найти решение, понимаешь? А тут мне рассказывают, что приложение всегда зависит от базы

Вот, этого я и хочу избежать, их можно разделить, как сделано сейчас, но это отдельные запросы

Да, спасибо, я уже насмотрелся на опытных говнокодеров со смешанными слоями данных, незнаем автомаппера , упаковок и встроенных через строку скл запросов на 100 строк, идите делайте боль другим