Estás mirando las cosas como programador, y debes analizarlo desde la visión del DBA o de arquitectura de datos. Son lógicas diferentes.
Vamos a hacer algunas aclaraciones para evitar confusiones:
Cita:
Iniciado por skanskan 
1
¿Pero se podría hacer esa misma consulta, con el mismo resultado, sin haber usado la FK?
¿Sólo afectará entonces al rendimiento y a la hora de poblar las tablas?
En mi ejemplo de hijos y padres por ejemplo, Puedo hacer todo tipo de consultas sin haber definido FK, y saber cosas como que padres tiene un hijo.
Poderse, se puede, como ya te dijeron. La pregunta es si esa query será eficiente ("performante" se suele decir), o si al menos segura. Y la respuesta es
no mucho.
La idea de una FK es que se pueda, por medio de un atributo de una entidad, establecer de forma unívoca una relación. Esto quiere decir que la información que se devuelva sea consistente e íntegra, y para ello los datos a relacionar deben ser seguros.
¿Puedes hacer una relación entre dos instancias de una tabla, si los datos no son seguros? ¿Si pueden darse ambigüedades en cuanto a alguna respuesta?
No. Por definición de lo que es una PK, sólo debe identificar a un único registro en todo el universo de representaciones, y siendo la FK una referencia a una PK, esa relación debe existir, ser válida y única.
¿Con qué otra cosa que no sea una relación de FK/PK lo haces en este modelo?
Simple: Con ninguna.
Ahora bien, si puedes relacionar dos instancias de dos entidades sin usar las FK, pero esa identificación es
segura y consistente, te comento que no estás ante otra forma de relacionar ambas tablas. Estás ante la misma forma de relacionarlas, pero eso se denomina "clave alternativa", y está dentro del modelo.
El hecho concreto es que una instancia de na entidad puede tener N formas de ser identificada unívocamente, pero sólo una se define como PK. Las otras podrían ser usadas como claves UNIQUE, que en algunos DBMS se admiten para uso como FK (MySQL, por ejemplo), porque cumplen la premisa de ser identificadores únicos no nulos.
¿Se entiende?
Lo que sí se puede asegurar es que usar otros campos no claves, pero de valor único, como relación en un JOIN no es eficiente, pero dependerá de lo que se esté consultando.
Cita:
Iniciado por skanskan 2
En tu ejemplo has puesto:
WHERE t1.nombre IN ('pepe','maria')
pero para eso tengo que escribir esos nombres en la propia consulta.
¿Cómo hago para que los vaya cogiendo "en tiempo de ejecución" de una lista o de los generados de otro sitio?
Por ejemplo, ¿Cómo generas una tabla en la que apareza para cada niño todos los hermanos que tiene, sin que aparezca su propio nombre?
Para eso existen las subconsultas en el WHERE, los auto-JOIN y otros recursos que aparecen en los manuales, y se aprenden con la experiencia. Escribir consultas no es poner "SELECT * FROM ... WHERE...". Trabajar con SQL es muchísimo más complejo que eso.
Cita:
Iniciado por skanskan Usando elementos de batch de DOS sería algo así
for %f in hijos do SELECT hijos.nombre AS s1 WHERE s1 <> %f
¿como hago algo así con sql?.
O hablando de otros lenguajes de programación habría que usar dos bucles o foreach...
No razones como programador cuando estés trabajando con BBDD. La lógica que se usa para resolver las consultas no es la misma que para resolver un proceso.
Esto no es una fantasía ni una exageración, sino las primeras palabras que los profesores de BBDD en la universidad te dicen, y la experiencia me ha enseñado que tienen razon.
Trabajar con estructuras de datos, y esquemas de BBDD,
no es lo mismo que trabajar con procesos y programación en lenguajes.
Tienes que aprender a dejar de lado lo que haces programando para entender la lógica de datos, y no pretender "adaptar" algo de un lenguaje en SQL.
No aplica.
En cualquier caso, lo que preguntas es perfectamente posible... pero no se escribe con esos recursos, y la sintaxis puede cambiar según uses SQL Server, MySQL, Oracle u otro DBMS.
Oracle, por ejemplo, tiene consultas recursivas donde encontrar el árbol completo de relaciones padre/hijo de múltiples niveles, excluyendo al propio usuario, es una única query, de no más de cuatro o cinco lineas. En cambio MySQL no lo tiene, y hay que hacerlo de otra forma.