Como gerar SELECTs com INNER JOIN em relacionamentos 1:N no EF

[maransi]

Caros

Seria possível tirar uma dúvida? Quais configurações são necessárias no EF para que os SELECTs gerados sejam criados com INNER JOIN em um relacionamento de 1:N? Fiz as mesmas configurações do curso "Fundamentos Entity Framework" e elas estão saindo no log com LEFT JOIN, abaixo a configuração utilizada entre as tabelas "Category" e "Post":

public class CategoryMap : IEntityTypeConfiguration<Category>
{
    // public void Configure(EntityTypeBuilder<Category> builder)

    public void Configure(EntityTypeBuilder<Category> builder)
    {
            builder.ToTable("Category");

            builder.HasKey( x => x.Id );

            builder.Property( x => x.Id )
                    .ValueGeneratedOnAdd()
                    .UseIdentityColumn();

            builder.Property( x => x.Name )
                    .IsRequired()
                    .HasColumnName("Name")
                    .HasColumnType("NVARCHAR")
                    .HasMaxLength(80);

            builder.Property( x => x.Slug )
                    .IsRequired()
                    .HasColumnName("Slug")
                    .HasColumnType("VARCHAR")
                    .HasMaxLength(80);

/*
builder.HasMany( x => x.Posts )
.WithOne( c => c.Category)
.HasForeignKey( x => x.CategoryId )
.IsRequired( false );
*/
builder.HasIndex( x => x.Slug, "IX_Category_Slug")
.IsUnique();
}
}

e

public class PostMap : IEntityTypeConfiguration<Post>
{
    public void Configure(EntityTypeBuilder<Post> builder)
    {
        builder.ToTable("Post");

        builder.HasKey(x => x.Id);

        builder.Property( x => x.Id )
                .ValueGeneratedOnAdd()
                .UseIdentityColumn();

        builder.Property( x => x.LastUpdateDate )
                .IsRequired()
                .HasColumnName("LastUpdateDate")
                .HasColumnType("SMALLDATETIME")
                .HasMaxLength(60)
                .HasDefaultValueSql("GETDATE()");

        builder.HasIndex( x => x.Slug, "IX_Post_Slug")
                // .HasName("IX_Post_Slug")
                .IsUnique();

        builder.HasOne( x => x.Author )
                .WithMany( x => x.Posts )
                .HasConstraintName("FK_Post_Author")
                .OnDelete( DeleteBehavior.Cascade );

        builder.HasOne(x => x.Category)
                .WithMany(x => x.Posts)
                .HasConstraintName("FK_Post_Category")
                .OnDelete(DeleteBehavior.Cascade);

        builder.HasMany( x => x.Tags )
                .WithMany( x => x.Posts )
                .UsingEntity<Dictionary<string, object>>(      
                    "PostTag",
                    post => post
                        .HasOne<Tag>()
                        .WithMany()
                        .HasForeignKey("PostId")
                        .HasConstraintName("FK_PostRole_PostId")
                        .OnDelete(DeleteBehavior.Cascade),
                    tag => tag
                        .HasOne<Post>()
                        .WithMany()
                        .HasForeignKey("TagId")
                        .HasConstraintName("FK_PostTag_TagId")
                        .OnDelete(DeleteBehavior.Cascade));

    }
}

[andrebaltieri]

@maransi você não tem controle sobre isso, o EF que "manda". Até onde sei, ele olha para o relacionamento e determinal qual melhor "JOIN" utilizar, por isto em determinados momentos ele força o INNER e em outros o LEFT.

Qual query você tentou executar que não teve o retorno como esperado?

[maransi]

Oi Balta

Antes de mais nada obrigado pela resposta. As classes que apresentei acima estão de acordo com as configurações do curso, ao executar o código abaixo o SELECT construído pelo EF veio com LEFT JOIN e não com INNER JOIN:

using( var context = new BlogDataContext()){
var categories = await context
.Categories
.Include( x => x.Posts )
.ToList();

            categories.ForEach( item => { 
                System.Console.WriteLine($"{item.Id} - {item.Name} - {item.Slug}");
            } );

Log:

SELECT [c].[Id], [c].[Name], [c].[Slug], [p].[Id], [p].[AuthorId], [p].[Body], [p].[CategoryId], [p].[CreateDate], [p].[LastUpdateDate], [p].[Slug],
[p].[Summary], [p].[Title]
FROM [Category] AS [c]
LEFT JOIN [Post] AS [p] // <--- LEFT JOIN
ON [c].[Id] = [p].[CategoryId]
WHERE [c].[Id] = 5
ORDER BY [c].[Id], [p].[Id]

[andrebaltieri]

Exatamente, como te expliquei acima, este é o comportamento padrão do EF e não temos como mudar.
Se você criar uma terceira classe, chamada EntidadeC para relacionar EntidadeA e EntidadeB e fizer um select na EntidadeC, aí ele entende como Inner Join.

[maransi]

Obrigado pela informação. tentarei simular uma terceira tabela para entender essa situação. Esse cenário que o EF oferece não é bom, pode acarretar em erros de informações indevidas e performance.

[maransi]

Ah, já ia me esquecendo. Segundo o que li no site da Microsoft, se colocarmos ".IsRequired()" na classe "CategoriaMap" era pra deixar opcional o objeto e aceitar nulo. Na prática, o "INNER JOIN" era pra funcionar; funcionou quando era pra um relacionamento 1:1, mas não funcionou para 1:N. Acho que estamos diante de um "Bugzinho", não acha?

builder.HasMany( x => x.Posts )
.WithOne( c => c.Category)
.HasForeignKey( x => x.CategoryId )
.IsRequired(); -- <----------------------------------- Dessa forma.

[andrebaltieri]

@maransi como vai?

Como te falei, na relação 1xN não faz sentido ter um INNER join, já que o lado esquerdo (O 1) sempre será preenchido, sempre terá valores. Logo o EF entende isto e usa o LEFT JOIN.

Até onde sei o INNER JOIN é mais rápido que o LEFT ou RIGHT JOIN, exceto nos casos onde a tabela da esquerda tem menos registros. Neste caso o SQL Server não precisa fazer hash match e otimiza muito as coisas.

Sendo assim acredito que o EF se beneficia deste comportamento, visto que no 1xN a tabela da esquerda sempre terá menos registros. Mas estou chutando... não fiz nenhuma pesquisa a fundo...

De qualquer forma é uma ótima observação, inclusive vale a penas dar uma fuçada no repositório do EF no GitHub e ver se já não perguntaram isto lá... se for o caso, podemos perguntar :)