vit0s wrote:
> Объясню на банальном примере: допустим, хочу сделать БД для хранения > данных о телефонных номерах друзей (просто телефонная книжка). > У каждого друга может же быть несколько телефонов. Как мне в базе это > реализовать? Пока ничего не приходит в голову кроме как сделать > текстовое поле "phone" и записывать туда строку с телефонами > разделенными каким-то символом, а при доступе к номерам — парсить. Может > можно это как-то более умно сделать? Чувствую, что можно, но что-то не
То, что ты хочешь сделать -- типичная для начинающих и грубейшая ошибка
проектирования Рел. БД -- нарушение 1-ой нормальной формы. Каждое поле
дожно содержать только атомарные атрибуты (ты хочешь положить туда список).
То, что тебе надо сделать -- это создать две таблицы, связанные
Master — Detail. Люди -- будет master , Detail -- будут телефоны.
Здравствуйте, MasterZiv, Вы писали: MZ>То, что ты хочешь сделать -- типичная для начинающих и грубейшая ошибка MZ>проектирования Рел. БД -- нарушение 1-ой нормальной формы. Каждое поле MZ>дожно содержать только атомарные атрибуты (ты хочешь положить туда список).
MZ>То, что тебе надо сделать -- это создать две таблицы, связанные MZ>Master — Detail. Люди -- будет master , Detail -- будут телефоны.
Хотелось бы уточнить: это грубая ошибка только до тех пор, пока существует необходимость "лезть" внутрь этого атрибута.
Тут вот упоминали проблему — как найти хозяина некоторого телефона.
Если таких запросов нет и не предвидится, то решения со списком номеров в одном атрибуте более чем достаточно. Оно упрощает многие вещи.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
"vit0s" <45872@users.rsdn.ru> wrote in message news:3670348@news.rsdn.ru... > Есть вопрос один, чувствую, что он глупый будет, но тем не менее я как-то запутался. > Объясню на банальном примере: допустим, хочу сделать БД для хранения данных о телефонных номерах друзей (просто телефонная книжка).
Это называется отношение один-ко-многим, реализуется двумя таблицами. В одну идет имя человека, в другую телефонные номера. Эти таблицы связаны через foreign key.
На самом деле задача транспонирования столбца в строку встречающается > довольно часто.
Если у тебя она встречается довольно часто, значит ты что-то очень не
так делаешь. Проблемы с проектированием у тебя значит. Или у твоих
коллег, конечно.
Здравствуйте, vit0s, Вы писали:
V>Всем привет. V>Есть вопрос один, чувствую, что он глупый будет, но тем не менее я как-то запутался. V>Объясню на банальном примере: допустим, хочу сделать БД для хранения данных о телефонных номерах друзей (просто телефонная книжка). V>У каждого друга может же быть несколько телефонов. Как мне в базе это реализовать? Пока ничего не приходит в голову кроме как сделать текстовое поле "phone" и записывать туда строку с телефонами разделенными каким-то символом, а при доступе к номерам — парсить. Может можно это как-то более умно сделать? Чувствую, что можно, но что-то не могу придумать никак. V>Спасибо.
Как уже было сказано, для телефонов нужно завести отдельную таблицу.
Но можно пойти дальше и разработать более гибкую структуру, в которой вводится понятие "Канал коммуникации" — способ, которым можно связаться с кем-нибудь, например телефон, факс, ICQ, email и т.д. Причем в будущем можно добавлять новые каналы, например "голубиная почта" или "дымовые сигналы", добавляя их по мере необходимости без изменения существующей структуры базы данных.
Если интересует, как разработать такую базу данных на профессиональном уровне, можно почитать Силверстона. В первом томе в главе 2 есть описание БД с гибкой структурой для хранения адресов и телефонов.
Здравствуйте, i1yich, Вы писали:
I>Подскажите, как в случае 1НФ, когда в одной таблице хранятся люди, а в другой один-ко-многим их телефоны, написать запрос, который в первом поле выводит имя, а во втором — все/первые N телефонов человека, разделенных через запятую? Ну вот так например:
I>
На самом деле задача транспонирования столбца в строку встречающается довольно часто.
Сделать можно например так:
-- create table PEOPLE (id int primary key, name varchar(200))
-- create table PHONES (id int primary key, people_id int, phone varchar(200))select Name,
STUFF((
SELECT [TOP 2] ', ' + p.PHONE
FROM PHONES p
WHERE p.people_id = PEOPLE.ID
[ORDER BY p.PHONE]
FOR XML PATH('')), 1, 2, '') Phones
from PEOPLE
Опционально можно задать 1) все/первые N, 2) Порядок строк при конкатенации, 3) Разделитель (через запятую, пробел, и т.д.).
Всем привет.
Есть вопрос один, чувствую, что он глупый будет, но тем не менее я как-то запутался.
Объясню на банальном примере: допустим, хочу сделать БД для хранения данных о телефонных номерах друзей (просто телефонная книжка).
У каждого друга может же быть несколько телефонов. Как мне в базе это реализовать? Пока ничего не приходит в голову кроме как сделать текстовое поле "phone" и записывать туда строку с телефонами разделенными каким-то символом, а при доступе к номерам — парсить. Может можно это как-то более умно сделать? Чувствую, что можно, но что-то не могу придумать никак.
Спасибо.
MZ>Да нет, не священная. Это просто мудрость старших. MZ>Не один год назад это придумали.
История человечества знает миллионы случаев, когда придуманные много лет назад решения выкидывались/пересматривались. И теперь я понимаю, с каким трудом это давалось людям, кто смотрел дальше и шире тех, кто отказывается думать своим умом и считал, что всё уже продумано за нас.
MZ>Это извини никак не связано. Данные и представление данных -- разные MZ>вещи.
Вот решение их каждой по отдельности и является признаком теоретика, который выливает из чайника воду, чтобы свести решение задачи к уже существующему решению.
MZ>В общем, мне-то уговаривать кого-то надоело.
Ну так и не начинал бы, тоже мне, одолжение сделал.
>> Есть вопрос один, чувствую, что он глупый будет, но тем не менее я > как-то запутался. >> Объясню на банальном примере: допустим, хочу сделать БД для хранения > данных о телефонных номерах друзей (просто телефонная книжка). > > Это называется отношение один-ко-многим, реализуется двумя таблицами. В > одну идет имя человека, в другую телефонные номера. Эти таблицы связаны > через foreign key.
Здравствуйте, avpavlov, Вы писали:
A>Для разумного числа телефонов предпочтительнее иметь несколько полей — phone1, phone2 и т.д.
A>Поиск, экспорт, построение отчетов, биндинг на форму — во что не ткни, насколько проще несколько колонок по сравнению со строками.
Зато c master/detail получается корректная модель. А с ограниченным количеством полей — когда-нибудь их не хватит и юзер всё равно запишет два телефона в одно поле. Которые потом не получится набрать в линию.
Здравствуйте, Centaur, Вы писали:
C>Зато c master/detail получается корректная модель. А с ограниченным количеством полей — когда-нибудь их не хватит и юзер всё равно запишет два телефона в одно поле. Которые потом не получится набрать в линию.
Юзер и в master|detail иногда такое умудряется писать, что ни в какие ворота не втиснуть. Так что, в случае именно контактов для персоны, ИМХО, лучше иметь строго фиксированное число полей. Причем каждое со своим форматированием и маской.
Centaur wrote:
> Зато c master/detail получается корректная модель. А с ограниченным > количеством полей — когда-нибудь их не хватит и юзер всё равно запишет > два телефона в одно поле. Которые потом не получится набрать в линию.
Не обязательно ждать этого. Наличие полей phone1, phone2, phone3, phone4 ... --
это уже криминал. Например, как в таком раскладе написать запрос
для поиска человека с заданным телефоном ? А потом ещё веселее
будет, когда понадобится добавить N+1 -ый телефон в таблицу, даже если
места под него хватает (хотя обычно во всех РСУБД допустимое кол-во
полей в таблице конечно). Прощай все запросы по поиску телефонов ...
1НФ не дураки придумали, поверьте уж программисту БД с хрен
знает каким стажем. Не делайте хуже себе самому, делайте ваши таблицы
с атомарными полями.
Здравствуйте, avpavlov, Вы писали:
MZ>>Да нет, не священная. Это просто мудрость старших. MZ>>Не один год назад это придумали.
A>История человечества знает миллионы случаев, когда придуманные много лет назад решения выкидывались/пересматривались. И теперь я понимаю, с каким трудом это давалось людям, кто смотрел дальше и шире тех, кто отказывается думать своим умом и считал, что всё уже продумано за нас.
Здесь твой пафос напоминает попытку преподнести деревянный велосипед как божественное откровение и спасение человечества.
___>Ну открой для себя оператор order by что ли ___>Если схема Мастер-Детали, то один и тот же запрос работает как для 1-го телефона, так и для 4,5 ... тыща питсот мульонов. ___>Бу-га-га! То же мне Проблема. Если заказчику нужно видеть там какой-либо главный телефон или порядок их сортировки, то это легко решается в той же мастре-детали при помощи дополнительного поля и неведомого тебе order by.
Все твои ответы об одном — "если применить здесь схему Мастер-Детали, которая тут как корове седло, то для всех возникших проблем можно найти решение"
Моя позиция — не надо искать решение проблем, возникших из-за слепого применения Мастер-Детали, лучше устранить причину этих проблем.
___> неведомого тебе order by.
Подскажите, как в случае 1НФ, когда в одной таблице хранятся люди, а в другой один-ко-многим их телефоны, написать запрос, который в первом поле выводит имя, а во втором — все/первые N телефонов человека, разделенных через запятую? Ну вот так например:
Name Phones
Иванов И.И. 127-09-94, 983-99-92
Петров П.П. 958-15-45
MZ>Главное, что тебе нужно знать -- это что такой запрос НЕ НУЖНО MZ>писать. Это нужно делать на клиенте. Вывести два набора данных MZ>(либо один, JOIN master и detail) и на клиенте уже их MZ>склеивать.
А если бизнес-слоя нет, например, если строится отчёт в каком-нибудь КристаллРепорт?
А если этот запрос часть большой обработки данных и не результаты отображаются, а подаются на вход другому запросу? Курсоры приляпать? (припоминаю, у нас тут есть на форуме любитель курсоров
Вообщем, повторюсь ещё раз — ваши с ДМ'ом ответы в основном о "если применить здесь схему Мастер-Детали, которая тут как корове седло, то для всех возникших проблем можно найти решение". Тогда как в некоторых случаях, например с телефонами, разумно провести денормализацию и избавить себя от кучи всяких костылей и верёвочек, позволяющих программисту оседлать корову (в то время, когда её просто можно отвести за веревку в нужное место).
Я даже не поленился посмотреть в документации, хак или не хак — и ведь документированное поведение, надо будет взять на вооружение
ПС
Но телефоны всё равно считаю лучше денормализвано хранить. Тем более красивые решения проблемы не в каждом сервере БД существуют, даже вышеуказанное только МССКЛ2005+.
Здравствуйте, avpavlov, Вы писали:
A>А если этот запрос часть большой обработки данных и не результаты отображаются, а подаются на вход другому запросу? Курсоры приляпать? (припоминаю, у нас тут есть на форуме любитель курсоров
А если бы у бабушки был бы х..., то она была бы дедушкой. Если у тебя что-то не будет получаться, ты пиши сюда — мы подскажем.
A>Вообщем, повторюсь ещё раз — ваши с ДМ'ом ответы в основном о "если применить здесь схему Мастер-Детали, которая тут как корове седло, то для всех возникших проблем можно найти решение". Тогда как в некоторых случаях, например с телефонами, разумно провести денормализацию и избавить себя от кучи всяких костылей и верёвочек, позволяющих программисту оседлать корову (в то время, когда её просто можно отвести за веревку в нужное место).
Тебя так послушать, так нормализация это просто невообразимый геморой неопредолимых препятствий. Как же мы до сих пор с тем MasterZiv с СУБД работаем? На самом деле с правильной красивой схемой работать легко и приятно. Денормализация нужна лишь в случае оптимизации и применяется редко и в специфичных случаях, но не как в элементарном телефонном справочнике — эдаком хелоу волд для СУБД.
PS: Твои аналогии с коровами вообще не пришей к п... рукав.
PPS: На сам деле, то что ты предлагаешь это вовсе не денормализация.
Первая нормальная форма (и все последующие) это не священная корова. Денормализация базы данных это такой же приём из арсенала разработчика БД как и нормализация.
Ваши упрёки (МастерЗив, Шеридан и прочие), что я там до чего-то недорос, для меня звучат как слова религиозных фанатиков, которые отрицают здравый смысл в угоду вере.
Обращаю ваше внимание, что я не ставлю под сомнение необходимость схемы Мастер-Детали вообще, а только для случая с телефонами/емайлами.
Особенно смешно выглядит ремарка, "а что если понадобится 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>>Поиск по телефону — вообщем это единственное место где денормализация мешает. Но я подозреваю, что там где есть поиск по телефону, там обычно есть всего один телефон, ну да ладно, настаивать не буду.
___>Всего один телефон. Чушь. Ей больно.
Вообщем-то я и не настаивал, но уровень твоей аргументации всё равно поражает.
avpavlov wrote:
> Первая нормальная форма (и все последующие) *это не священная корова*.
Да нет, не священная. Это просто мудрость старших.
Не один год назад это придумали.
> Денормализация базы данных это такой же приём из арсенала разработчика > БД как и нормализация.
Денормализация -- это конда сначала БД нормализована, а потом денормализована.
Тут случай другой -- ненормализованность.
> Ваши упрёки (МастерЗив, Шеридан и прочие), что я там до чего-то недорос, > для меня звучат как слова религиозных фанатиков, которые отрицают > здравый смысл в угоду вере.
Гы, ну я вроде бы как только и пытался до всех донести именно здравый
смысл.
> Особенно смешно выглядит ремарка, "а что если понадобится 4й, 5й и т.д. > телефон?" *Задайте этот вопрос себе!*
Так у нас контакты в отдельной таблице. чего нам парица то ?
> показать как отдельную колонку в результатах поиска или отчёта. В вашей > идеальной схеме придётся каким-либо образом поддерживать порядок строк, > чтобы иметь возможность показать в колонках или отчёте с помощью джойнов > или вложенных запросов.
Ой, нашёл проблему. Ну, поддерживаем.
> При биндинге на форму ваша идеальная схема не позволяет показать 1й > телефон на видном месте, а остальные где-то в доп. секции, вам всегда > придётся таскать за собой этот дурацкий список. Что вы ответите > заказчику на такую невинную просьбу? "Чувак, данные находятся в первой > нормальной форме, поэтому твоё требование невыполнимо" ???
Это извини никак не связано. Данные и представление данных -- разные
вещи.
avpavlov wrote:
> Схема хранения данных — это не сферический конь в вакууме. Данные надо > не только хранить, но и обрабатывать. И лёгкость обработки очень важный > фактор, который почему-то полностью игнорируется теоретиками. А биндинг > часть лёгкой обработки данных. > > A>>Поиск по телефону — вообщем это единственное место где денормализация > мешает. Но я подозреваю, что там где есть поиск по телефону, там обычно > есть всего один телефон, ну да ладно, настаивать не буду.
Ну так как с поиском по телефону ? Напиши справочник Yellow Pages
в уме. попробуй.
Здравствуйте, avpavlov, Вы писали:
___>>"Поддерживать порядок строк" — что это?
A>Если где-то выводится колонка "Телефон 1", то здесь всегда должен быть 1й телефон, а не как СКЛ сервер решит в очередной момент (иначе говоря, без упорядочивания хранения не будет воспроизводимости результатов).
Ну открой для себя оператор order by что ли
___>>И таки в чем проблема с джойнами и подзапросами?
A>Ну кое-кто был уверен, что схема Мастер-Детали позволяет написать запрос один раз и использовать его всю оставшуюся жизнь программы. А это не так. А если всё равно запрос дописывать до поддержки 4го-5го телефонов, так почему бы не дописать наиболее простым способом?
Если схема Мастер-Детали, то один и тот же запрос работает как для 1-го телефона, так и для 4,5 ... тыща питсот мульонов.
A>>>При биндинге на форму ваша идеальная схема не позволяет показать 1й телефон на видном месте, а остальные где-то в доп. секции, вам всегда придётся таскать за собой этот дурацкий список. Что вы ответите заказчику на такую невинную просьбу? "Чувак, данные находятся в первой нормальной форме, поэтому твоё требование невыполнимо" ???
___>>А в чем проблема этого биндинга — что ты на нем зациклился?
A>Я так понимаю, это то что ты ответишь заказчику, "Какой-такой 1й телефон телефон на видном месте, что ты на нем зациклился"
Бу-га-га! То же мне Проблема. Если заказчику нужно видеть там какой-либо главный телефон или порядок их сортировки, то это легко решается в той же мастре-детали при помощи дополнительного поля и неведомого тебе order by.
A>Схема хранения данных — это не сферический конь в вакууме. Данные надо не только хранить, но и обрабатывать. И лёгкость обработки очень важный фактор, который почему-то полностью игнорируется теоретиками. А биндинг часть лёгкой обработки данных.
Поверь мне, я далеко не теоретик.
A>>>Поиск по телефону — вообщем это единственное место где денормализация мешает. Но я подозреваю, что там где есть поиск по телефону, там обычно есть всего один телефон, ну да ладно, настаивать не буду.
Таки да, сам уже усомнился в своей схеме.
___>>Всего один телефон. Чушь. Ей больно. A>Вообщем-то я и не настаивал, но уровень твоей аргументации всё равно поражает.
Здравствуйте, avpavlov, Вы писали:
___>>Ну открой для себя оператор order by что ли ___>>Если схема Мастер-Детали, то один и тот же запрос работает как для 1-го телефона, так и для 4,5 ... тыща питсот мульонов. ___>>Бу-га-га! То же мне Проблема. Если заказчику нужно видеть там какой-либо главный телефон или порядок их сортировки, то это легко решается в той же мастре-детали при помощи дополнительного поля и неведомого тебе order by.
A>Все твои ответы об одном — "если применить здесь схему Мастер-Детали, которая тут как корове седло, то для всех возникших проблем можно найти решение"
В данном случае данной корове данное седло очень кстати.
A>Моя позиция — не надо искать решение проблем, возникших из-за слепого применения Мастер-Детали, лучше устранить причину этих проблем.
Слепого ли...
___>> неведомого тебе order by.
A>Хамство — это прибежище невежества.
Спасибо буду знать от оно как...
Прости если ранил твою нежную психику, улыбайся и горе пройдет.
Здравствуйте, i1yich, Вы писали:
I>Подскажите, как в случае 1НФ, когда в одной таблице хранятся люди, а в другой один-ко-многим их телефоны, написать запрос, который в первом поле выводит имя, а во втором — все/первые N телефонов человека, разделенных через запятую? Ну вот так например:
I>
Здравствуйте, gandjustas, Вы писали:
G>В случае с MS SQL можно написать свой аггрегат. Но порядок телефонов будет зависить от фазы луны.
Да, конечно жаль, что обработчик запросов кладет на атрибут IsInvariantToOrder=false.
С другой стороны, если можно писать агрегаты с двумя параметрами, то вторым параметром можно передавать порядок для сортировки и промежуточный результат внутри агрегата хранить в виде сортированного списка, а объединять в строку в функции Terminate. Это правда увеличивает размер агрегата в сериализованном виде.
i1yich wrote:
> Подскажите, как в случае 1НФ, когда в одной таблице хранятся люди, а в > другой один-ко-многим их телефоны, написать запрос, который в первом > поле выводит имя, а во втором — все/первые N телефонов человека, > разделенных через запятую? Ну вот так например: > > Name Phones > Иванов И.И. 127-09-94, 983-99-92 > Петров П.П. 958-15-45
Главное, что тебе нужно знать -- это что такой запрос НЕ НУЖНО
писать. Это нужно делать на клиенте. Вывести два набора данных
(либо один, JOIN master и detail) и на клиенте уже их
склеивать.
Здравствуйте, avpavlov, Вы писали:
MZ>>Главное, что тебе нужно знать -- это что такой запрос НЕ НУЖНО MZ>>писать. Это нужно делать на клиенте. Вывести два набора данных MZ>>(либо один, JOIN master и detail) и на клиенте уже их MZ>>склеивать.
A>А если бизнес-слоя нет, например, если строится отчёт в каком-нибудь КристаллРепорт?
A>А если этот запрос часть большой обработки данных и не результаты отображаются, а подаются на вход другому запросу? Курсоры приляпать? (припоминаю, у нас тут есть на форуме любитель курсоров
A>Вообщем, повторюсь ещё раз — ваши с ДМ'ом ответы в основном о "если применить здесь схему Мастер-Детали, которая тут как корове седло, то для всех возникших проблем можно найти решение". Тогда как в некоторых случаях, например с телефонами, разумно провести денормализацию и избавить себя от кучи всяких костылей и верёвочек, позволяющих программисту оседлать корову (в то время, когда её просто можно отвести за веревку в нужное место).
А если нужны не просто номера телефонов, а еще и типизатор (мобильный,домашний etc), то как ты будешь это делать? На каждый из N столбцов с телефонами сделаешь еще столец phone_type_N? Как в таком случае будет выглядеть запрос на выборку телефонов определенного типа?
А если в процессе развития системы понадобится к телефонам привязывать информацию (ну, например, текстовый коммент, что по конкретному телефону не звонить после 21:00, или например потребуется история звонков)? В случае схемы мастер-детали у каждого телефона есть PK, по которому к нему можно цеплять что угодно. А в твоем случае как быть?
Y>А если нужны не просто номера телефонов, а еще и типизатор (мобильный,домашний etc), то как ты будешь это делать? На каждый из N столбцов с телефонами сделаешь еще столец phone_type_N?
Скорее уж будет homePhone, mobilePhone1, mobilePhone2, workPhone1, workPhone2.
Y> Как в таком случае будет выглядеть запрос на выборку телефонов определенного типа?
select workPhone1, workPhone2
или (смотря по задаче)
select workPhone1
union select workPhone2
Но если честно, до сих пор не видал такого требования (а вот выводить через запятую — сплошь и рядом).
Y>А если в процессе развития системы понадобится к телефонам привязывать информацию (ну, например, текстовый коммент, что по конкретному телефону не звонить после 21:00, или например потребуется история звонков)?
Просто будет одно единственное поле phoneComments, куда можно будет вписать что угодно. И не факт, что такая схема хуже, вдруг комментарий удобнее иметь один на человека, чем один на телефон (например "ни в коем случае не звонить по выходным" или "если занято, связаться Мастером Зивом, он умный и всё знает").
Y> или например потребуется история звонков
Это вообще я бы не стал к конкретному телефону привязывать, ты же не с телефоном говоришь, а с человеком
Y> В случае схемы мастер-детали у каждого телефона есть PK, по которому к нему можно цеплять что угодно. А в твоем случае как быть?
Я вообщем с тобой согласен, поднятые тобой задачи возможно стоило бы решать и с Мастер-Детали. Да только вот до сих пор такие задачи не поднимались, а вывод телефонов в колонки, через запятую, определенного телефона в определённом месте — встречается куда как чаще, поэтому и решать проще без Мастер-Детали.
Здравствуйте, i1yich, Вы писали:
I>Подскажите, как в случае 1НФ, когда в одной таблице хранятся люди, а в другой один-ко-многим их телефоны, написать запрос, который в первом поле выводит имя, а во втором — все/первые N телефонов человека, разделенных через запятую? Ну вот так например:
I>
avpavlov wrote: > А если бизнес-слоя нет, например, если строится отчёт в каком-нибудь > КристаллРепорт?
А я что-то говорил про бизнес-слой ?
Crystall замечательно умеет это делать.
Я знаю целых два способа. Нет, три.
> А если этот запрос часть большой обработки данных и не результаты > отображаются, а подаются на вход другому запросу? Курсоры приляпать?
Это значит бредовый запрос. Данные надо выдавать в последнюю очередь,
и клиенту.
> случаях, например с телефонами, разумно провести денормализацию и > избавить себя от кучи всяких костылей и верёвочек, позволяющих > программисту оседлать корову (в то время, когда её просто можно отвести
Подловил ты меня. Ты говорил про "на клиенте". Видать у тебя клиент кроме бизнес-слоя имеет ещё один слой: "костылей и верёвочек".
MZ>Crystall замечательно умеет это делать. MZ>Я знаю целых два способа. Нет, три.
Я знаю только один — встроенные скрипты. Использовать их никому не порекомендую: отладки нет, документация отвратительная, поддержка ещё более отвратительная. И самое главное — это просто ещё один способ укрепить седло на корове
Другие 2 способа огласи.
>> А если этот запрос часть большой обработки данных и не результаты >> отображаются, а подаются на вход другому запросу? Курсоры приляпать?
MZ>Это значит бредовый запрос. Данные надо выдавать в последнюю очередь, MZ>и клиенту.
Странный ты, Мастер Зив. Тебя послушать, так получается, что любые способы обработки данных, которые тебе до сих пор не понадобились ни разу, являются не нужными и используют их только еретики.
avpavlov wrote:
> Странный ты, Мастер Зив. Тебя послушать, так получается, что любые > способы обработки данных, которые тебе до сих пор не понадобились ни > разу, являются не нужными и используют их только еретики.
Я где-то говорил про то, что я не делал никогда cross-report или
никогда не мёржил в одно поле список ?
Так что, в случае именно контактов для персоны, ИМХО, лучше иметь строго фиксированное число полей. Причем каждое со своим форматированием и маской.
