Дедушка... в табл. "Адреса" будут множественные записи по клиенту...
Как вы это собираетесь сделать ? В табл. "Адреса" завести текстовое поле "Список Клиентов" и записывать в него id клиентов через запятую ?
Недостатков такого подхода достаточно.
1. Как выяснить адрес клиента, зная его id ?
select IdCli from address where my_func(IdCli)=1
(в данном примере функция my_func возвращает 1 если в поле "Список Клиентов" есть id данного клиента, и 0 - если его там нет)
полный просмотр таблицы адресов с вызовом функции my_func для каждой записи
(я не знаю можно или нет строить идекс по функции в MSSQL2K)
2. Нельзя организовать ссылоную целосность.
2.1. В поле "Список Клиентов" можно добавить id несуществующего клиента (или писать триггер).
2.2. При удалении клиента необходимо пройтись по всей таблице "Адреса" и обновлять все поля "Список Клиентов" где присутствует данный id клиента.
2.3. При удалении записи из "Адреса" необходимо опять же обеспечить сохранение ссылочной целосности (чтобы не получить клиентов без адреса).

При создании таблицы связей и foreign key - всех этих проблем просто не будет.

Напишите пример.
так чтобы был клиент с одним адресом и клиент с тремя адресами
и так чтобы был адрес для по которому находиться один клиент и адрес по которому находиться три клиента.
И select-ы которыми вы получаете
Дедушка...желая получить все адреса клиента мы делаем выборку из "Адреса" по конкретному Клиент.id и получаем список адресов клиента, обратно работает для получения всех клиентов с этим адресом...

У вас неправильное представление о практической реализации связи "многие ко многим". Тут явно видна избыточность.

Адрес:
1*****1*****Москва*****Кремль
2*****1*****Моск.обл.*****Борвиха
3*****2*****Москва*****Кремль
4*****2*****Моск.обл.*****Борвиха
(Кстати, почему у [Моск.обл.*****Борвиха] два различных Адрес_ид - 2 и 4 ?)

Если будет 1000 клиентов из Борвихи надо будет писать (согласно вашему примеру):
2*****1*****Моск.обл.*****Борвиха
4*****2*****Моск.обл.*****Борвиха
5*****3*****Моск.обл.*****Борвиха
..............
1001*****1000*****Моск.обл.*****Борвиха

а в таблице Адрес кроме полей Город,Адрес1 может быть еще штук 30 полей.
В таблице Адрес должна быть только одна запись [Моск.обл.*****Борвиха]

Причем еще и второй пример нерабочий.
select Клиент.Имя, Адрес.Город, Адрес.Адрес1
from Клиент left outer join Адрес on Клиент.Адрес_ид=Адрес.Адрес_ид
where Адрес.Адрес1='Кремль'
В таблице Клиент у вас нет поля Адрес_ид. Если вы его туда вставите то получиться (опять же следуя вашей логике):
1*****1*****Путин
2*****1*****Иванов
3*****2*****Путин
4*****2*****Иванов
тоже самое что и с адресами.


Должно быть:
Клиенты:
1*****Путин
2*****Иванов

Адрес:
1*****Москва*****Кремль
2*****Моск.обл.*****Борвиха

Связь_Адрес_Клиент:
Адрес_ид
Клиент_ид

Наполнение:
1*****1
1*****2
2*****1
2*****2

ДедушкаВ данной системе не предполагается Клиента без адреса и Адреса без клиента... Т.е разделение связи многие ко многим через табл. связи актуально если необходимо независимость сущностей Клиент и Адрес??
ModelR сделал абсолютно верное замечание. Если удалить всех ваших клиентов из Борвихи - то и Борвиха прекратит свое существование. Если вы именно этого и добиваетесь - объединяйте таблицы "Адрес" и "Клиент". (Опять же - будет некоторая избыточность).
ДедушкаНу вот пример из pubs-а где табл. "Авторы" и "Названия книг". Везде говорится, что это многие ко многим и поэтому будем разделять через связку. Хотя очевидно, что не будет авторов без книг и книг без авторов...
Мне это не очевидно. Если у нас книжный склад - то имеем таблицу "Книга" в которой есть поля "Название книги" и "Автор". Потому что различных книг у которых один и тоже автор на книжном складе несколько штук. Но если мы говорим о библиотеке, в которой выделяются полки на конкретных авторов (классиков) - то уже имеет смысл говорить о разделении "Книга"/"Автор".

Дедушка
Ну хорошо... но ведь в табл. "Связь_Адрес_Клиент" тоже множественные записи
пусть 1000 клиентов из Борвихи тогда:
1*****1
.
.
.
1000*****1
И основная проблем в том, что в табл. "Адрес" есть ещё 30 полей... насколько я понял... но ведь поиск будет по индексу??
Т.е избыточность по айдишникам лучше чем по любым другим полям??
Основная проблема, на мой взгляд, в том что в приложении вы предлагаете человеку кроме клиента каждый раз вводить еще и реквизиты адреса. В итоге в вашей таблице адресов будет куча Борвих:
Моск.обл *****Борвиха
Моск обл *****Борвиха
Московская обл.*****Борвиха
Московская обл*****Борвиха
"Каша" в справочнике - это по-моему основная проблема. Привести все потом к единому виду очень тяжело.

Во-вторых тут нет никакой "избыточность по айдишникам". 1000 клиентов из Борвихи действительно имеют вид:
1*****1
.
.
.
1000*****1
но так и должно быть.

ДедушкаИ основная проблем в том, что в табл. "Адрес" есть ещё 30 полей... насколько я понял... но ведь поиск будет по индексу??
Хорошо, поиск по индексу. Таблица, в которой запись дублируется несколько десятков раз и занимать на диске будет в несколько десятков раз больше места.
100 Кб и 1Мб сейчас конечно несильно отличаются, но 1 Гб и 10 Гб отличаются существенно. И в запросе
select Клиент.Имя, Адрес.Город, Адрес.Адрес1
from Клиент left outer join Адрес on Клиент.Адрес_ид=Адрес.Адрес_ид
where Адрес.Адрес1='Кремль'
для тысячи "Кремлевских" клиентов будет в сотни раз больше чтений с жесткого диска (достаточно дорогая операция) если адрес дублируется тысячу раз, чем при обращении к таблице где только одна такая запись. Индекс тут помагает, но панацеей не является.
Таблица связи в свою очередь гораздо меньше чем таблица адресов. При доступе по индексу для тысячи клиетов "Кремлевских" будет пара чтений с диска для индекса и одино чтение для таблицы "Адрес".