Formulario - Tag Select

Eu acho que é melhor deixar no HTML.

Depende muito do tipo de informação que será exibida no select, por exemplo:

1 - Se for um campo status onde temos opções "Ativo" e "Inativo" então fica no próprio HTML.

2 - Se você for trazer opções de um banco de dados aí a coisa muda, principalmente se estiver trabalhando com MVC onde o Controller chama um Model para consultar os dados e depois chama a View para exibir as informações.

Basicamente se for do banco de dados tem que ser o programador.

Por exemplo, esse campo mês que postei código, fica no banco?

William, não seria mais "trabalhoso" para a aplicação puxar do banco essas informações?

Pergunta clássica, esse tipo de informação muda constantemente, ou seja, os meses do ano mudam sempre?

Senão muda é constante então deixa o no HTML, eu nunca deixei meses do ano no banco de dados.

Marcelo citei "Depende muito do tipo de informação", em sistemas administrativos existem diversas situações em que você traz informações de clientes, produtos e etc. vindos do banco de dados, como respondi acima, a informação é alterada com frequência?

Nunca mudam! Devo penso sempre nesses requisitos, tipo, algum tipo de dado que não? exemplo, sexo: M H.

Entendi William!

Exatamente, não tem sentido em trazer do banco sexo M e F somente para preencher o select.

Pegando jeito e entendendo as coisas! Devagar mais vai dar certo, depois começo a estudar uma linguagem!

O que foi dito nos post procede, porém e sempre tem um porém gostaria de adicionar mais uma forma de ver a questão.

Como relação a criar os DropDownlist (combos) e outros controles via banco não acredito que isto vá pesar o banco de dados. Claro que vai haver a sempre o questionamento de que e se o site possuir milhares de acessos consecutivos vai pesar. Olha se você possuir milhares de acesso consecutivos vai ter que adquirir uma infra profissional e não seria o preenchimento dos combobobox que fariam tanta diferença. O que mata um banco de dados é o amadorismo dos projetista do mesmo. E desenvolvedores medíocres que desconhece boas práticas e lógica de programação. E hoje temos como usar AngularJs e knockoutJs mais serialização você pode literalmente trazer todo o processamento pesado para o lado do cliente, desonerando a rede e o servidor de banco de dados. Claro não é algo trivial e é preciso ser um desenvolvedor de verdade para adotar esta abordagem.


Tudo o que o William falou é correto e procede, só que como ele mesmo frisou depende do cenário. E por exemplo empresas de grande porte, principalmente bancos normalmente exigem que tudo que for carregado na página provenha do banco de dados. Bancos mesmo são neuróticos com relação a segurança, trilha de auditoria e criptografia dos dados e normalmente tudo é carregado dinamicamente via banco de dados.
Outro cenário em que a carga de qualquer controle deve ser feita via banco de dados é quando o site vai ser multi-idioma. Não tem como fugir a única forma de garantir um site escalonado e realmente dinâmico em relação ao idioma é tudo vir de um baco de dados. Já imaginou se a cada novo idioma adicionado, tivesse que altear o código, gera um deploy, homologar e depois publicar em produção.

Quando você trabalhe em um ambiente corporativo tudo é importante: qualidade dos artefatos gerados, arquitetura, codificação e funcionalidade, mas o que faz toda a diferença é o custo e prazos.

Então é importantíssimo seguir recomendações, porém não se prenda a elas, pois invariavelmente cada caso é um caso. Só pra você ter uma ideia a na empresa em que trabalho hoje, por atuar no mundo todo, já recomenda usar banco de dados para preencher combos de sexo, pois em alguns países já é usual usar a opção "transgênero" ou similar.

Sua resposta foi precisa apesar de "cheia", não achei ruim, muito pelo contrario e só tenho a agradecer Jothaz.