Identificador do tenant

Olá, Davisson!
Tudo bem?

No model single database é assim que funciona, porque você precisa ter a coluna "tenant_id" para identificar o tenant.

Por isso usamos uma trait de tenant para centralizar ao máximo as responsabilidades repetidas nela.

Qualquer dúvida amigo, me retorne.

Abs;

Entendi a necessidade de ser feito assim, mas no final teriamos uma tabela de tenat com 700 indices de relacionamentos, isso não seria uma má pratica? Teria alguma outra abordagem? Isso poderia ser feito usando a coluna de tenant_id apenas como um sinalizador ao invés de uma chave estrangeira ou realmente não há nenhum problema uma tabela com centenas de ligamentos?

Tenho essa duvida para casos de sistemas muito grandes e complexos com centenas de tabelas, se não ha problema em seguir com esse fluxo ou se teria alguma outra abordadgem

Olá, Davisson!

Sinceramente não vejo má prática, uma tabela ter N relacionamentos não é algo incomum... esse modelo é muito usado, inclusive em sistemas gigantes como o Conta Azul (e milhares de outros).

Agora sobre ter o relacionamento (foreign key) já é uma discussão interessante. Existem profissionais que defendem o não uso, já existem outros que defendem o uso para manter a integridade dos dados.

Vou te palpitar no meu caso, na maioria dos projetos que fiz sempre usei foreign key, e sempre atendeu bem.

Agora, para casos que achei complicado relacionar os dados procurei utilizar um banco de dados não relacional, como o MongoDB.