Sql + estrutura

O conceito dessa modelagem não está errado… Precisa apenas ter bem entendido qual a finalidade desses dados. Veja uma situação por exemplo: se você tiver um casal trabalhando nessa empresa. O mesmo filho vai ser cadastrado para os dois (pai e mãe) ? Aí depende. Se for para fins de abater dependendes no Imposto de Renda nem pode. Mas pra outras coisas (plano de saúde, por exemplo) talvez possa - o que vai fazer com que o mesmo filho tenha que ser cadastrado duas vezes. Se for esse o caso melhor pensar em uma tabela só com dados do filho e uma outra onde relacione os id’s de filhos x pais.
Não guarde a idade. Guarde a data de nascimento. Quando precisar saber a idade é uma continha básica.
Lentidão é coisa que você pode resolver com a criação de índices apropriados. Mas essa estimativa aí eu não acho preocupante não.
Fotos podem ser armazenadas no banco como tipo BLOB, por exemplo. Ou você pode guardá-las num diretório, cada uma nomeada com o ID do funcionário por exemplo. E na aplicação você pode colocar o caminho deste diretório concatenado com o ID do funcionário que vai conseguir carregar beleza também. Novamente, escolher a abordagem depende dos problemas que vocÊ quer resolver. Deixar tudo no banco pode ser uma boa, mas cuidado com a dimensão dessas fotos que pode fazer o tamanho da base subir rapidamente. Usar esse esquema de deixar num diretório possibilita que a foto seja usada por outros sistemas se for o caso.