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

История человечества знает миллионы случаев, когда придуманные много лет назад решения выкидывались/пересматривались. И теперь я понимаю, с каким трудом это давалось людям, кто смотрел дальше и шире тех, кто отказывается думать своим умом и считал, что всё уже продумано за нас.

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

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

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

Ну так и не начинал бы, тоже мне, одолжение сделал.

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

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

A>История человечества знает миллионы случаев, когда придуманные много лет назад решения выкидывались/пересматривались. И теперь я понимаю, с каким трудом это давалось людям, кто смотрел дальше и шире тех, кто отказывается думать своим умом и считал, что всё уже продумано за нас.

Здесь твой пафос напоминает попытку преподнести деревянный велосипед как божественное откровение и спасение человечества.

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

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

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

Ну открой для себя оператор order by что ли

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

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

Если схема Мастер-Детали, то один и тот же запрос работает как для 1-го телефона, так и для 4,5 ... тыща питсот мульонов.

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

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

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


Бу-га-га! То же мне Проблема. Если заказчику нужно видеть там какой-либо главный телефон или порядок их сортировки, то это легко решается в той же мастре-детали при помощи дополнительного поля и неведомого тебе order by.

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

Поверь мне, я далеко не теоретик.

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

Таки да, сам уже усомнился в своей схеме.

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

Мне нарвится поражать.

___>Ну открой для себя оператор order by что ли
___>Если схема Мастер-Детали, то один и тот же запрос работает как для 1-го телефона, так и для 4,5 ... тыща питсот мульонов.
___>Бу-га-га! То же мне Проблема. Если заказчику нужно видеть там какой-либо главный телефон или порядок их сортировки, то это легко решается в той же мастре-детали при помощи дополнительного поля и неведомого тебе order by.

Все твои ответы об одном — "если применить здесь схему Мастер-Детали, которая тут как корове седло, то для всех возникших проблем можно найти решение"

Моя позиция — не надо искать решение проблем, возникших из-за слепого применения Мастер-Детали, лучше устранить причину этих проблем.

___> неведомого тебе order by.

Хамство — это прибежище невежества.

avpavlov пишет:

> Хамство — это прибежище невежества.

Странно, ты вроде бы не хамил особенно сильно.

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

___>>Ну открой для себя оператор order by что ли
___>>Если схема Мастер-Детали, то один и тот же запрос работает как для 1-го телефона, так и для 4,5 ... тыща питсот мульонов.
___>>Бу-га-га! То же мне Проблема. Если заказчику нужно видеть там какой-либо главный телефон или порядок их сортировки, то это легко решается в той же мастре-детали при помощи дополнительного поля и неведомого тебе order by.

A>Все твои ответы об одном — "если применить здесь схему Мастер-Детали, которая тут как корове седло, то для всех возникших проблем можно найти решение"

В данном случае данной корове данное седло очень кстати.

A>Моя позиция — не надо искать решение проблем, возникших из-за слепого применения Мастер-Детали, лучше устранить причину этих проблем.

Слепого ли...

___>> неведомого тебе order by.

A>Хамство — это прибежище невежества.

Спасибо буду знать от оно как...
Прости если ранил твою нежную психику, улыбайся и горе пройдет.

Подскажите, как в случае 1НФ, когда в одной таблице хранятся люди, а в другой один-ко-многим их телефоны, написать запрос, который в первом поле выводит имя, а во втором — все/первые N телефонов человека, разделенных через запятую? Ну вот так например:

Name        Phones
Иванов И.И.    127-09-94, 983-99-92
Петров П.П.    958-15-45

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

I>Подскажите, как в случае 1НФ, когда в одной таблице хранятся люди, а в другой один-ко-многим их телефоны, написать запрос, который в первом поле выводит имя, а во втором — все/первые N телефонов человека, разделенных через запятую? Ну вот так например:

I>

I>Name        Phones
I>Иванов И.И.    127-09-94, 983-99-92
I>Петров П.П.    958-15-45
I>

В случае с MS SQL можно написать свой аггрегат. Но порядок телефонов будет зависить от фазы луны.

Здравствуйте, 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) и на клиенте уже их
склеивать.

MZ>Главное, что тебе нужно знать -- это что такой запрос НЕ НУЖНО
MZ>писать. Это нужно делать на клиенте. Вывести два набора данных
MZ>(либо один, JOIN master и detail) и на клиенте уже их
MZ>склеивать.

А если бизнес-слоя нет, например, если строится отчёт в каком-нибудь КристаллРепорт?

А если этот запрос часть большой обработки данных и не результаты отображаются, а подаются на вход другому запросу? Курсоры приляпать? (припоминаю, у нас тут есть на форуме любитель курсоров

Вообщем, повторюсь ещё раз — ваши с ДМ'ом ответы в основном о "если применить здесь схему Мастер-Детали, которая тут как корове седло, то для всех возникших проблем можно найти решение". Тогда как в некоторых случаях, например с телефонами, разумно провести денормализацию и избавить себя от кучи всяких костылей и верёвочек, позволяющих программисту оседлать корову (в то время, когда её просто можно отвести за веревку в нужное место).

G>В случае с MS SQL можно написать свой аггрегат. Но порядок телефонов будет зависить от фазы луны.

Согласен, количество способов, которыми можно укрепить на корове седло, достаточно велико

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

I>Подскажите, как в случае 1НФ, когда в одной таблице хранятся люди, а в другой один-ко-многим их телефоны, написать запрос, который в первом поле выводит имя, а во втором — все/первые N телефонов человека, разделенных через запятую? Ну вот так например:

I>

I>Name        Phones
I>Иванов И.И.    127-09-94, 983-99-92
I>Петров П.П.    958-15-45
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) Разделитель (через запятую, пробел, и т.д.).

Я даже не поленился посмотреть в документации, хак или не хак — и ведь документированное поведение, надо будет взять на вооружение

ПС

Но телефоны всё равно считаю лучше денормализвано хранить. Тем более красивые решения проблемы не в каждом сервере БД существуют, даже вышеуказанное только МССКЛ2005+.

Здравствуйте, 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, по которому к нему можно цеплять что угодно. А в твоем случае как быть?

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

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

G>В случае с MS SQL можно написать свой аггрегат. Но порядок телефонов будет зависить от фазы луны.

Зачем агрегат? Данная задача легко решается штатными средствами T-SQL.

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

I>Подскажите, как в случае 1НФ, когда в одной таблице хранятся люди, а в другой один-ко-многим их телефоны, написать запрос, который в первом поле выводит имя, а во втором — все/первые N телефонов человека, разделенных через запятую? Ну вот так например:

I>

I>Name        Phones
I>Иванов И.И.    127-09-94, 983-99-92
I>Петров П.П.    958-15-45
I>

А зачем этой фигней заниматься серверу? Работай с проджойненым результатом на клиенте.

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

A>А если этот запрос часть большой обработки данных и не результаты отображаются, а подаются на вход другому запросу? Курсоры приляпать? (припоминаю, у нас тут есть на форуме любитель курсоров

А если бы у бабушки был бы х..., то она была бы дедушкой. Если у тебя что-то не будет получаться, ты пиши сюда — мы подскажем.

A>Вообщем, повторюсь ещё раз — ваши с ДМ'ом ответы в основном о "если применить здесь схему Мастер-Детали, которая тут как корове седло, то для всех возникших проблем можно найти решение". Тогда как в некоторых случаях, например с телефонами, разумно провести денормализацию и избавить себя от кучи всяких костылей и верёвочек, позволяющих программисту оседлать корову (в то время, когда её просто можно отвести за веревку в нужное место).

Тебя так послушать, так нормализация это просто невообразимый геморой неопредолимых препятствий. Как же мы до сих пор с тем MasterZiv с СУБД работаем? На самом деле с правильной красивой схемой работать легко и приятно. Денормализация нужна лишь в случае оптимизации и применяется редко и в специфичных случаях, но не как в элементарном телефонном справочнике — эдаком хелоу волд для СУБД.

PS: Твои аналогии с коровами вообще не пришей к п... рукав.

PPS: На сам деле, то что ты предлагаешь это вовсе не денормализация.

avpavlov wrote:
> А если бизнес-слоя нет, например, если строится отчёт в каком-нибудь
> КристаллРепорт?

А я что-то говорил про бизнес-слой ?

Crystall замечательно умеет это делать.
Я знаю целых два способа. Нет, три.

> А если этот запрос часть большой обработки данных и не результаты
> отображаются, а подаются на вход другому запросу? Курсоры приляпать?

Это значит бредовый запрос. Данные надо выдавать в последнюю очередь,
и клиенту.

> случаях, например с телефонами, разумно провести денормализацию и
> избавить себя от кучи всяких костылей и верёвочек, позволяющих
> программисту оседлать корову (в то время, когда её просто можно отвести

Дело твоё. Я предупредил.