Select de de tres tablas.

[gnzsoloyo]

Básicamente está bien, aunque hay tres consideraciones:
- Por un lado, si el NIF es obligatorio (no sé lo que es, pero supongo que se parece a nuestro CUIT), eso podría ser suficiente para establecer una PK, con lo que hacerla numérica y autoincremental puede terminar siendo redundante. En todo caso es una decisión de diseño. Depende de lo que quieras hacer.
- Si un usuario puede tener 0 a N teléfonos, los teléfonos no van en la tabla. Poner una cantidad fija puede ser demasiado o muy poco, dependiendo del caso, y desperdiciar espacio jamás es buena idea, aunque te sobre. Además, si pones un campo por teléfono también estás complicando las consultas, porque el teléfono lo deberás buscar en cada uno de los campos, mientras que ponerlos en otra tabla relacionada por el num_usuario te permitirá consultar siempre el mismo, y la consulta será más simple.
- Son demasiados índices. Los índices siempre tienen impacto en la performance con los INSERT/UPDATE, por lo que si se esperan muchas entradas, tantos indices conspiran en contra. Es preferible la cantidad de indices justa y con buena selectividad.

Respecto a lo de la tabla dir_usuarios, en realidad tiene ciertos defectos.
Una tabla que contiene direcciones no conviene que tenga campos VARCHAR para poner manualmente los nombres de ciudades, provincias, países, y cosas así. Eso es preferible manejarlos en tablas independientes, y que sean relacionados a la tabla de direcciones por su PK. Es decir: Lo que van son campos numéricos, que sean las FK de las Localidades, Paises, Provincias o Departamentos (o como se llamen las subdivisiones provinciales).
Así es como se hace usualmente.

Hay al menos un par de razones para hacerlo así:

1) No necesitas desperdiciar espacio para almacenar N veces la misma localidad, departamento, provincia y país.

2) Evitas que el usuario meta la pata y de pongan Cba., Cord., Cordova, Córdova o Córdoba como ciudad, lo que terminaría interpretándose como cinco ciudades distintas, cuando en realidad es una sola.

Nunca te olvides que al usuario hay que dejarle el menor dominio posible sobre cosas que son estandarizadas, ya que la mayor fuente de errores es... la interfase silla-teclado, como decía un amigo mío (el usuario).

En definitiva, es mejor que separes esos datos en otras tablas (relacionadas entre sí a su vez para que cada ciudad corresponda con su provincia y cada provincia con su país), y no dejarlos así.

Finalmente, la tercera tabla tiene un defecto primario: Si el gestionante es un usuario, y el usuario tiene siempre al menos una dirección, a menos que la transacción deba ser entregada en otra parte no declarada, no tiene sentido ni utilidad que los datos de dirección estén allí. Son redundantes, bastaría con el id del usuario y de la direccion que usará.
Y aún así, si la dirección de entrega es diferente a las declaradas, eso sería un caso opcional y no obligatorio, por tanto esos datos deberían estar en una tabla específica relacionada con la tercera tabla, donde sólo se consultarían si un campo dir_usuario_id (la dirección destino a usar) fuese NULL.
Es decir: Lo que tendría más sentido es que el usuario que hace la gestión declare en cuál dirección registrada será entregado lo que sea, y en caso de definir otra dirección no declarada, que ese conjunto de datos sea o una dirección declarada nueva, o una dirección de destino de la transacción. En el segundo caso esos datos deberían ir en una tabla separada y relacionados con el ID de la tercera tabla.

Es posible que esto te resulte algo pesado, y un poco engorroso por la falta de experiencia en el diseño de bases de datos, pero te puedo asegurar con conocimiento de causa, que normalizar las tablas mas o menos como te describo hará que a la larga no tengas tantos problemas al construir las consultas, y posiblemente no te veas obligado a modificar la base, cuando esta ya esté productiva.
Modificar bases en trabajo es la pesadilla de los DBA.