Всем привет.
Есть вопрос один, чувствую, что он глупый будет, но тем не менее я как-то запутался.
Объясню на банальном примере: допустим, хочу сделать БД для хранения данных о телефонных номерах друзей (просто телефонная книжка).
У каждого друга может же быть несколько телефонов. Как мне в базе это реализовать? Пока ничего не приходит в голову кроме как сделать текстовое поле "phone" и записывать туда строку с телефонами разделенными каким-то символом, а при доступе к номерам — парсить. Может можно это как-то более умно сделать? Чувствую, что можно, но что-то не могу придумать никак.
Спасибо.

"vit0s" <45872@users.rsdn.ru> wrote in message news:3670348@news.rsdn.ru...
> Есть вопрос один, чувствую, что он глупый будет, но тем не менее я как-то запутался.
> Объясню на банальном примере: допустим, хочу сделать БД для хранения данных о телефонных номерах друзей (просто телефонная книжка).

Это называется отношение один-ко-многим, реализуется двумя таблицами. В одну идет имя человека, в другую телефонные номера. Эти таблицы связаны через foreign key.

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

Ну и для ясности можно добавить пример

CREATE TABLE Persons (
     PersonID integer PRIMARY KEY,
     PersonName text
);
CREATE TABLE PhoneNumbers (
     PhoneNumberID integer PRIMARY KEY,
     PersonID integer,
     PhoneNumber text,
     FOREIGN KEY (PersonID) REFERENCES Persons ( PersonID )
);

Здравствуйте, vit0s, Вы писали:

V>Всем привет.
V>Есть вопрос один, чувствую, что он глупый будет, но тем не менее я как-то запутался.
V>Объясню на банальном примере: допустим, хочу сделать БД для хранения данных о телефонных номерах друзей (просто телефонная книжка).
V>У каждого друга может же быть несколько телефонов. Как мне в базе это реализовать? Пока ничего не приходит в голову кроме как сделать текстовое поле "phone" и записывать туда строку с телефонами разделенными каким-то символом, а при доступе к номерам — парсить. Может можно это как-то более умно сделать? Чувствую, что можно, но что-то не могу придумать никак.
V>Спасибо.

Как уже было сказано, для телефонов нужно завести отдельную таблицу.

Но можно пойти дальше и разработать более гибкую структуру, в которой вводится понятие "Канал коммуникации" — способ, которым можно связаться с кем-нибудь, например телефон, факс, ICQ, email и т.д. Причем в будущем можно добавлять новые каналы, например "голубиная почта" или "дымовые сигналы", добавляя их по мере необходимости без изменения существующей структуры базы данных.

Если интересует, как разработать такую базу данных на профессиональном уровне, можно почитать Силверстона. В первом томе в главе 2 есть описание БД с гибкой структурой для хранения адресов и телефонов.

vit0s wrote:

> Объясню на банальном примере: допустим, хочу сделать БД для хранения
> данных о телефонных номерах друзей (просто телефонная книжка).
> У каждого друга может же быть несколько телефонов. Как мне в базе это
> реализовать? Пока ничего не приходит в голову кроме как сделать
> текстовое поле "phone" и записывать туда строку с телефонами
> разделенными каким-то символом, а при доступе к номерам — парсить. Может
> можно это как-то более умно сделать? Чувствую, что можно, но что-то не

То, что ты хочешь сделать -- типичная для начинающих и грубейшая ошибка
проектирования Рел. БД -- нарушение 1-ой нормальной формы. Каждое поле
дожно содержать только атомарные атрибуты (ты хочешь положить туда список).

То, что тебе надо сделать -- это создать две таблицы, связанные
Master — Detail. Люди -- будет master , Detail -- будут телефоны.

MZ>То, что тебе надо сделать -- это создать две таблицы, связанные
MZ>Master — Detail. Люди -- будет master , Detail -- будут телефоны.

Я бы не был бы так категоричен. Сколько раз я предпочитал решение Мастер-Детали и потом жалел.

Для разумного числа телефонов предпочтительнее иметь несколько полей — phone1, phone2 и т.д.

Поиск, экспорт, построение отчетов, биндинг на форму — во что не ткни, насколько проще несколько колонок по сравнению со строками.

Здравствуйте, avpavlov, Вы писали:

A>Для разумного числа телефонов предпочтительнее иметь несколько полей — phone1, phone2 и т.д.

A>Поиск, экспорт, построение отчетов, биндинг на форму — во что не ткни, насколько проще несколько колонок по сравнению со строками.

Зато c master/detail получается корректная модель. А с ограниченным количеством полей — когда-нибудь их не хватит и юзер всё равно запишет два телефона в одно поле. Которые потом не получится набрать в линию.

Здравствуйте, Centaur, Вы писали:

C>Зато c master/detail получается корректная модель. А с ограниченным количеством полей — когда-нибудь их не хватит и юзер всё равно запишет два телефона в одно поле. Которые потом не получится набрать в линию.

Юзер и в master|detail иногда такое умудряется писать, что ни в какие ворота не втиснуть. Так что, в случае именно контактов для персоны, ИМХО, лучше иметь строго фиксированное число полей. Причем каждое со своим форматированием и маской.

avpavlov wrote:
> Я бы не был бы так категоричен. Сколько раз я предпочитал решение
> Мастер-Детали и потом жалел.

Значит ты ещё не дорос до проектирования нормальных реляционных БД.

Centaur wrote:

> Зато c master/detail получается корректная модель. А с ограниченным
> количеством полей — когда-нибудь их не хватит и юзер всё равно запишет
> два телефона в одно поле. Которые потом не получится набрать в линию.

Не обязательно ждать этого. Наличие полей phone1, phone2, phone3, phone4 ... --
это уже криминал. Например, как в таком раскладе написать запрос
для поиска человека с заданным телефоном ? А потом ещё веселее
будет, когда понадобится добавить N+1 -ый телефон в таблицу, даже если
места под него хватает (хотя обычно во всех РСУБД допустимое кол-во
полей в таблице конечно). Прощай все запросы по поиску телефонов ...

1НФ не дураки придумали, поверьте уж программисту БД с хрен
знает каким стажем. Не делайте хуже себе самому, делайте ваши таблицы
с атомарными полями.

Приветствую, avpavlov, вы писали:

a> Я бы не был бы так категоричен. Сколько раз я предпочитал решение Мастер-Детали и потом жалел.

А как ты будешь решать к примеру такое?

Здравствуйте, MasterZiv, Вы писали:
MZ>То, что ты хочешь сделать -- типичная для начинающих и грубейшая ошибка
MZ>проектирования Рел. БД -- нарушение 1-ой нормальной формы. Каждое поле
MZ>дожно содержать только атомарные атрибуты (ты хочешь положить туда список).

MZ>То, что тебе надо сделать -- это создать две таблицы, связанные
MZ>Master — Detail. Люди -- будет master , Detail -- будут телефоны.
Хотелось бы уточнить: это грубая ошибка только до тех пор, пока существует необходимость "лезть" внутрь этого атрибута.
Тут вот упоминали проблему — как найти хозяина некоторого телефона.
Если таких запросов нет и не предвидится, то решения со списком номеров в одном атрибуте более чем достаточно. Оно упрощает многие вещи.

Коллеги!

Первая нормальная форма (и все последующие) это не священная корова. Денормализация базы данных это такой же приём из арсенала разработчика БД как и нормализация.

Ваши упрёки (МастерЗив, Шеридан и прочие), что я там до чего-то недорос, для меня звучат как слова религиозных фанатиков, которые отрицают здравый смысл в угоду вере.

Обращаю ваше внимание, что я не ставлю под сомнение необходимость схемы Мастер-Детали вообще, а только для случая с телефонами/емайлами.

Особенно смешно выглядит ремарка, "а что если понадобится 4й, 5й и т.д. телефон?" Задайте этот вопрос себе!

4й и все последующие телефоны не нужны просто чтобы были, в 90% (хотел поставить 99%, ну да Бог с вами) случаев, этот телефон потребуется показать как отдельную колонку в результатах поиска или отчёта. В вашей идеальной схеме придётся каким-либо образом поддерживать порядок строк, чтобы иметь возможность показать в колонках или отчёте с помощью джойнов или вложенных запросов. Тогда как в денормализованной нужно просто отобразить ещё одно поле.

При биндинге на форму ваша идеальная схема не позволяет показать 1й телефон на видном месте, а остальные где-то в доп. секции, вам всегда придётся таскать за собой этот дурацкий список. Что вы ответите заказчику на такую невинную просьбу? "Чувак, данные находятся в первой нормальной форме, поэтому твоё требование невыполнимо" ???

Поиск по телефону — вообщем это единственное место где денормализация мешает. Но я подозреваю, что там где есть поиск по телефону, там обычно есть всего один телефон, ну да ладно, настаивать не буду.

Здравствуйте, avpavlov, Вы писали:

MZ>>То, что тебе надо сделать -- это создать две таблицы, связанные
MZ>>Master — Detail. Люди -- будет master , Detail -- будут телефоны.

A>Я бы не был бы так категоричен. Сколько раз я предпочитал решение Мастер-Детали и потом жалел.

A>Для разумного числа телефонов предпочтительнее иметь несколько полей — phone1, phone2 и т.д.

A>Поиск, экспорт, построение отчетов, биндинг на форму — во что не ткни, насколько проще несколько колонок по сравнению со строками.

Чушь порите батенька. Если уж две таблички не весть какая сложность... Но гемороя я вижу больше с одной таблицей и опыту моему поверить стоит.

Биндинг на форму мля

Здравствуйте, avpavlov, Вы писали:

A>Коллеги!

A>Первая нормальная форма (и все последующие) это не священная корова. Денормализация базы данных это такой же приём из арсенала разработчика БД как и нормализация.

Ну да. Только здесь как раз оно самое то.

A>Особенно смешно выглядит ремарка, "а что если понадобится 4й, 5й и т.д. телефон?" Задайте этот вопрос себе!

И таки как все-таки ответить на этот вопрос?

A>4й и все последующие телефоны не нужны просто чтобы были, в 90% (хотел поставить 99%, ну да Бог с вами) случаев, этот телефон потребуется показать как отдельную колонку в результатах поиска или отчёта. В вашей идеальной схеме придётся каким-либо образом поддерживать порядок строк, чтобы иметь возможность показать в колонках или отчёте с помощью джойнов или вложенных запросов. Тогда как в денормализованной нужно просто отобразить ещё одно поле.

"Поддерживать порядок строк" — что это?
И таки в чем проблема с джойнами и подзапросами?

A>При биндинге на форму ваша идеальная схема не позволяет показать 1й телефон на видном месте, а остальные где-то в доп. секции, вам всегда придётся таскать за собой этот дурацкий список. Что вы ответите заказчику на такую невинную просьбу? "Чувак, данные находятся в первой нормальной форме, поэтому твоё требование невыполнимо" ???

А в чем проблема этого биндинга — что ты на нем зациклился?

A>Поиск по телефону — вообщем это единственное место где денормализация мешает. Но я подозреваю, что там где есть поиск по телефону, там обычно есть всего один телефон, ну да ладно, настаивать не буду.

Всего один телефон. Чушь. Ей больно.

___>"Поддерживать порядок строк" — что это?

Если где-то выводится колонка "Телефон 1", то здесь всегда должен быть 1й телефон, а не как СКЛ сервер решит в очередной момент (иначе говоря, без упорядочивания хранения не будет воспроизводимости результатов).

___>И таки в чем проблема с джойнами и подзапросами?

Ну кое-кто был уверен, что схема Мастер-Детали позволяет написать запрос один раз и использовать его всю оставшуюся жизнь программы. А это не так. А если всё равно запрос дописывать до поддержки 4го-5го телефонов, так почему бы не дописать наиболее простым способом?

A>>При биндинге на форму ваша идеальная схема не позволяет показать 1й телефон на видном месте, а остальные где-то в доп. секции, вам всегда придётся таскать за собой этот дурацкий список. Что вы ответите заказчику на такую невинную просьбу? "Чувак, данные находятся в первой нормальной форме, поэтому твоё требование невыполнимо" ???

___>А в чем проблема этого биндинга — что ты на нем зациклился?

Я так понимаю, это то что ты ответишь заказчику, "Какой-такой 1й телефон телефон на видном месте, что ты на нем зациклился"

Схема хранения данных — это не сферический конь в вакууме. Данные надо не только хранить, но и обрабатывать. И лёгкость обработки очень важный фактор, который почему-то полностью игнорируется теоретиками. А биндинг часть лёгкой обработки данных.

A>>Поиск по телефону — вообщем это единственное место где денормализация мешает. Но я подозреваю, что там где есть поиск по телефону, там обычно есть всего один телефон, ну да ладно, настаивать не буду.

___>Всего один телефон. Чушь. Ей больно.
Вообщем-то я и не настаивал, но уровень твоей аргументации всё равно поражает.

Sinclair wrote:

> Хотелось бы уточнить: это грубая ошибка только до тех пор, пока
> существует необходимость "лезть" внутрь этого атрибута.

Да, безусловно.

avpavlov wrote:

> Первая нормальная форма (и все последующие) *это не священная корова*.

Да нет, не священная. Это просто мудрость старших.
Не один год назад это придумали.

> Денормализация базы данных это такой же приём из арсенала разработчика
> БД как и нормализация.

Денормализация -- это конда сначала БД нормализована, а потом денормализована.
Тут случай другой -- ненормализованность.

> Ваши упрёки (МастерЗив, Шеридан и прочие), что я там до чего-то недорос,
> для меня звучат как слова религиозных фанатиков, которые отрицают
> здравый смысл в угоду вере.

Гы, ну я вроде бы как только и пытался до всех донести именно здравый
смысл.

> Особенно смешно выглядит ремарка, "а что если понадобится 4й, 5й и т.д.
> телефон?" *Задайте этот вопрос себе!*

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

> показать как отдельную колонку в результатах поиска или отчёта. В вашей
> идеальной схеме придётся каким-либо образом поддерживать порядок строк,
> чтобы иметь возможность показать в колонках или отчёте с помощью джойнов
> или вложенных запросов.

Ой, нашёл проблему. Ну, поддерживаем.

> При биндинге на форму ваша идеальная схема не позволяет показать 1й
> телефон на видном месте, а остальные где-то в доп. секции, вам всегда
> придётся таскать за собой этот дурацкий список. Что вы ответите
> заказчику на такую невинную просьбу? "Чувак, данные находятся в первой
> нормальной форме, поэтому твоё требование невыполнимо" ???

Это извини никак не связано. Данные и представление данных -- разные
вещи.

В общем, мне-то уговаривать кого-то надоело.

avpavlov wrote:

> Схема хранения данных — это не сферический конь в вакууме. Данные надо
> не только хранить, но и обрабатывать. И лёгкость обработки очень важный
> фактор, который почему-то полностью игнорируется теоретиками. А биндинг
> часть лёгкой обработки данных.
>
> A>>Поиск по телефону — вообщем это единственное место где денормализация
> мешает. Но я подозреваю, что там где есть поиск по телефону, там обычно
> есть всего один телефон, ну да ладно, настаивать не буду.

Ну так как с поиском по телефону ? Напиши справочник Yellow Pages
в уме. попробуй.

MZ>Ну так как с поиском по телефону ? Напиши справочник Yellow Pages
MZ>в уме. попробуй.

Ну так он в тех 10%, потому что реально это фактически база адресов и телефонов, там больше нет ничего.