Estudo para escalabilidade do cadastro de instituiçoes ensino about guardioes-api

[RenatoBrittoAraujo]

A solução que considerei melhor por agora é dividir a seleção por País -> Estado/Província -> Cidade -> Instituição -> Departamento. Uma tabela mostrando a média de escolhas para cada um dos casos:

Categoria	Número de opções
País	+- 200
Estado	+- 15
Cidade	+- 100
Instutuição	+- 10
Departamento	+- 10

Ao invés de colocar todos os possíveis departamentos de todas as possíveis instuições do mundo, o servidor web pode servir como plataforma para se inserir um estado/cidade/instuição/departamento novo de forma preguiçosa na base de dados, sob demanda, assim não sobrecarregando o usuário final com muitas escolhas mas permitindo escalada global. Apenas administradores são capazer de inserir uma entrada nova nessas categorias.

[RenatoBrittoAraujo]

Outra possibilidade, discutida com o @gabrieldouurado foi a de fazer um sistema recursivo parecido com o anterior mas com diferenças fundamentais: não existem insituição nem departamentos. Os administradores podem adicionar e remover categorias de seleções ad infinitum. Isso conserta certos problemas que poderiam surgir devido à rigidez do sistema anterior:

• Um escola por exemplo, pode escolher por não dividir sua instituição em departamentos para categorizar alunos.
• Uma universidade pode escolher não apenas se dividir em instiuições e departamentos, mas também cursos para categorizar discentes.

Claramente pela flexibidlidade ele vai ser mais difícil de implementar e também terá muitas considerações de design para que seja fácil a sua utilização para o usuário final, além de tornar o processo de lidar com a base de dados possívelmente mais difícil, bem como os níveis de acesso dos administradores e outras considerações...

[RenatoBrittoAraujo]

Levando em conta as consequências do que foi sugerido anteriormente, considerei como fazer a base de dados suportar essa flexibilidade, em especial nas buscas. Cheguei em uma solução que pode suportar simples buscas de maneira instuitiva. Preferi explicar usando um exemplo de um tabela ficçional de usuários:

User ID	Country	State	City	Category
1	Brazil	DF	Brasília	universidade: UnB, departamento: FGA, curso: Eletrônica
2	Brazil	DF	Brasília	universidade: UnB, tecnico: eletricista
3	Brazil	DF	Brasília	universidade: IFB
4	Brazil	DF	Brasília	escola: CEF 404
5	Brazil	RJ	Rio de Janeiro	empresa: VTEX, escritorio: RH
6	United States	CA	Los Angeles	school: escolaqualquer, building: A-12

Vamos supor que vários administradores tenham diferentes níveis de permissão:

• Um administrador cujas permissões seja apenas a universidade de Brasília teria acesso apenas aos indices da tabela que dão match com Brazil -> DF -> Brasília -> universidade: UnB*.

• Um administrador do curso de eletrônica da UnB teria Brazil -> DF -> Brasília -> universidade: UnB, departamento: FGA, curso: Eletrônica*.

• Um administrador com acesso apenas aos funcionários técnicos da UnB teria Brazil -> DF -> Brasília -> universidade: UnB, técnico*.

• Todas as escolas de Belo Horizonte Brazil -> MG -> Belo Horizonte -> escolas:*.

• Todos os alunos de uma escola em um prédio X United States -> CA -> Los Angeles -> school: escolaqualquer, building: A-12*.

• Todos os usuários registrados de Brasília Brazil -> DF -> Brasília -> *

Se guardados assim na base dados, pelo próprio prefixo é possível acessar qualquer categoria de usuário levando em conta outros filtros relevantes (como data), além de guardar na base de dados de forma mais simples e compreensível.

A escolha de como seria a estrutura da(as) categoria(s) seria à critério da própria instituição em questão, isso sendo manualmente adicionado no pelo servidor web quando necessário.