Подскажите пожалуйста.
Вот запрос с WHERE


как написать при помощи JOIN.
Получается, что address становится дважды алиасом.
Похоже, что JOIN намного неудобнее простого WHERE.
Чтото не пойму логики, как им пользоваться :(
Есть какой-то хороший туториалс?

То есть получается его можно написать вот так

если учитывать что address.id для employee и для enterprise - 2 разных ключа :(
И это наверное правильно - то есть еще один альяс сделать.
Но иногда ж пишут чтото типа 

Но во-первых так не работает, а во-вторых - когда и как надо писать?

Объединения через where это тоже объединения. 
С технической точки зрения ваш запрос переписанный на join эквивалентен запросу с объединением в where.
Преимущество использования синтаксиса join, в данном случае, с моей точки зрения, в том, что происходит явное отделение критериев объединения множеств от критериев отбора. Что повышает читабельность.


если вы внимательно подумаете, то поймете что в первом запросе тоже надо дважды соединяться с адресом. При условии конечно, что мы не желаем отобрать те employee  и те enterprise которые имеют общий адрес.

Дело в том, что это делается тулза, которая должна сделать JOIN выбранных таблиц для любой структуры базы данных. То есть человек выбрал 5 таблиц из базы - и эта тулза должна догадаться, как их связать между собой. Поэтому мне нужен алгоритм построения этих JOIN в целом, то есть чтобы написать код, который будет эти джойны строить.
Есть ктото, кто настолько ясно представляет себе этот механизм, чтобы сформулировать четко правило этих джойнов? Заранее благодарен.

либо объединять по одноименным полям(утопия, когда над БД работают несколько человек, без неких правил семантически одно поле в разных таблицах может называться по-разному), либо парсить foreign key для выявления связей(не каждая БД и не всегда поддерживает foreign key), либо просить человека указать поля для связывания.

При этом можно предлагать предворительно сопоставив столбцу одной таблицы те поля другой таблицы у которых такой тип данных, который бы допускал соединение. (А для тех которых тип "не подходящий" - Enabled=false).

Так же можно "приоритетно" предлагать пользователю выбрать вариант связи.
Сначала для полей Unique, primary key - мол "скорее всего это должно Вам подойти", 
а лишь потом всё остальное.

oson, неужели вы считаете что данный алгоритм можно реализовать за 1000 шагов или 10000000 шагов?
если бы все было так просто, то такое ПО было бы реализовано лет так 30 назад.

Чисто для справки Natural join 
На практике - абсолютно бесполезная вещь.