Banco de Dados SQL
comentada em 12/08/2020 12:49

Provavelmente não. As chaves possuem index, então não deve ser um problema. Ainda mais se o seu sistema não tiver na casa dos milhões de registros.

Uma coisa é como você modela o banco de dados, outra coisa é como você faz as buscas no banco. Você tá misturando as duas coisas. Modelando as tabelas seguindo as boas práticas de modelagem de dados você só precisa saber como montar a query correta. 

Pode buscar só pelas properties de um user, pode buscar todas as properties, pode buscar de acordo com uma ou mais condições. 

Se preocupa em modelar bem o banco. E se não sabe bem modelar um banco recomendo este curso Curso de Modelagem de Dados - YouTube

Valeu pessoal

Bom dia. Pelo que entendi seria isso:

 

Users (userid, username, usersurname) e Properties(propertieid, userid, propertiessize) etc.

Se você colocar o userid como chave estrangeira dento de Properties e esta for indexada, não terá problemas de performance (isso para banco de dados relacional).

 

Mas se o imóvel foi adquirido em sociedade (mais de uma pessoa) suas tabelas não atenderão, tendo que fazer o seguinte método.

 

Users (userid, username, usersurname) e Properties(propertieid, propertiessize)

Users_Properties(userid, propertieid).

 

Na filosofia do site somos orientados a ensinar a pescar, sendo assim segue uma referência excelente para bancos de dados relacionais.

https://www.amazon.com.br/Introdu%C3%A7%C3%A3o-Sistemas-Bancos-Dados-Date/dp/8535212736/ref=sr_1_2?__mk_pt_BR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=banco+de+dados+relacionais+autor%3A+date&qid=1597239771&sr=8-2

Tudo que sei de banco aprendi com este livro, evidente que existem outros. Antes que venham os mimimis que é muito caro (e talvez desatualizado o que pode ser verdade) eu já antecipo: Acha caro o conhecimento? Espera até chegar o preço da ignorância.

A resposta do Thiago está adequada, já que tu tem a relação, tu não precisa se preocupar com isso. E mesmo se houver milhões de registro, isso de colocar um campo em formato de "array", não é uma boa prática.

É bem simples de tu buscar um registro, baseado ou na propriedade o no user.

Um exemplo prático, seria:

Pegar propriedades de um user:

select * from properties where user_id = x;

Pegar usuários com alguma propriedade:
select * from users inner join properties on properties.user_id = users.id where properties.id = x;

Basicamente isso que tu pode fazer (essas queries são totalmente ilustrativas), só para demonstrar que não irá ter problemas caso tenha uma relação

Essa relação de um usuário para várias propriedades é bem modelada usando uma chave estrangeira user_id na tabela de propriedades. Vc vai conseguir fazer qualquer busca, filtro e agregação que imaginar envolvendo essa relação usando somente a chave estrangeira.

Mas a ideia de colocar um array na tabela de usuários não é boa. Você esta reinventado o conceito de índice de banco de dados. Trata-se de uma otimização que pode acelerar as queries, mas tem custos também e nem sempre é necessário.

Foca no modelo do banco de dados. Mais para frente, quando estiver tudo redondo, vc vai ver se e quais queries precisam ser mais rápidas e vai otimizar o SQL e/ou acrescentar os índices somente onde precisa.

"A otimização prematura é a raiz de todo mal" - Donald Knuth

Pois é, sempre tendo a achar que quem quer armazenar um array no banco de dados não tá sabendo fazer o relacionamento corretamente. Não vi até agora uma necessidade real de armazenar arrays em banco, embora seja possível. Quando eu pensava em armazenar arrays era quando eu não sabia modelar banco de dados.

Tem sim alguns motivos para se armazenar um "array", embora o tipo de dados mais aceito seja JSON (pelo menos por alguns bancos de dados, como MySql, Postgres etc). Dá para adicionar campos assim, para registros que tu pode ter muita adaptação ou imprecisão no dado, como um campo "extra", que irá conter dados não regulares etc.

@SEJA sim, tem razão. O que quis dizer na verdade é que muitas vezes o pessoal quer armazenar array quando na verdade não precisa de um array, por não estar sabendo fazer o relacionamento da forma correta. 

Além do que o pessoal já falou, eu adicionaria um index no properties.created_at(data de criação).

Bebe o leite esquece a vaca....

E tendo PK e FK e o model está configurado corretamente, é só deixar o FRAMEWORK trabalhar. Ele fará os relacionamentos para você sem ter que esquentar a cabeça.

Se for em PHP, vale cada segundo gasto aprendendo o laravel.

Não se preocupe com esse modelo simples que você descreveu. Faça a modelagem seguindo os padrões das boas práticas (nesse caso com a FK de user na tabela property) e seja feliz. Banco de dados hoje é commodity, pra você ter problema de performance você vai precisar de uma combinação nefasta de: a. estar rodando seu servidor em ambiente muito obsoleto b. ter uma massa de dados descomunal sem nenhum tipo de tuning c. estar rodando queries extremamente mal escritas. 

Os SGBDs hoje conseguem rodar muito bem até bancos mal modelados e query mal escritas. Você vai precisar de muita força pra ter má performance por causa de uma FK.

Laravel fazendo o que você precisa:

// Buscar pela data de criação
$properties = Property::orderBy('created_at')->desc()->get();
foreach($properties as $property);

// O nome da property
$property->name;

// o nome do usuário da property
$property->user->name;

endforeach;
----------------------

// Buscando pelo usuário Id 1
$users = User::whereId(1)->get();

// Listando as properties dele
foreach($users->properties as $property);

// Nome da property
$property->name;

endforeach;

Valeu galera pelos comentários.

Eu vou seguir como estava antes, mantendo somente um campo de user_id nós properties entao.

Aproveitando o gancho, eu tenho um array tambem em properties mas é para armazenar a URL com as fotos do imóvel. Estou fazendo correto? Pois vai ficar em uma db diferente.

@cyrptobeen valeu, mas não existe a possibilidade de ter mais de um usuário por imóvel

foreign key não gera índice, até onde sei. Só primary key.

essa questão do desempenho, são 2 coisas que afetam mais:
full table scan - quando o banco tem que percorrer todos os registros para filtrar
join - quando você tem que juntar tabelas para obter a informação.

Em ambas haverá degradação.
full table scan é a mais evitável. Em geral se evita com um índice.
create index 'ix_nome_qq' on tabela(campo1, campo2, campo3...);



O índice deve conter, no mínimo, os campos do where.

Ex: select a,b,c from tabela where campo1 = x and campo2 = y

join:

você evita join melhor dimensionando suas tabelas.

Às vezes repetindo dado, às vezes criando umas tabelas sumarizadas. Depende muito do negócio.

Aqui não tem segredo: quanto mais normalizado for o banco, menos espaço consome, mais fácil é manter tudo atualizado PORÉM, mais lento será, pra tudo. Select, insert, update... tudo. 

Quanto mais desnormalizado é o banco, mas rápido, porém consome mais espaço e demanda mais trabalho pra manter.

Ex: dado normalizado
Tabela Pessoa:
id
nome
cpf

Tabela Departamento
id_depto
nome_depto

Tabela empregado
id_depto
id_pessoa

Como obter os nomes dos empregados do depto X?

Select Pessoa.nome from Pessoa, Departamento, Empregado where
Departamento.id_depto = empregado.id_depto and
Pessoa.id_pessoa = empregado.id_pessoa and
Departamento.id_depto = x

3 joins!

dado desnormalizado:
Tabela empregado
id_depto
nome_depto
id_pessoa
nome_pessoa

Select Pessoa.nome from empregado where
Departamento.id_depto = x

0 joins!