Attain. Сортировка по части поля

[Nik]

Подскажите, как в отчете осуществить сортировку по части поля таблицы. Например, поле даты, а сортировку сделать в порядке: месяц, день, год.

[Nik]

Как правило в других языках можно легко сделать сортировку по выражению. Неужели в Navision это непобедимо?

[mazzy]

Хм... то что вы хотите противоречит рекомендациям по нормализации реляционных баз данных. Противоречит даже первой форме. Заметьте даже не рекомендациям Аттейна, а самих баз данных.

Я не специалист по Аттейну, но, скорее всего, Аттейн не должен содрежать подобной функции даже из общих соображений.

Читайте теорию.
Начните поиск материалов по реляционным базам данных с www.sql.ru.
Например, ссылка которую дал яндекс http://citforum.ints.net/cfin/prcorp...istpr_08.shtml
Почитайте Book Online по поводу нормальных форм.
Возьмите любую книгу по поводу СУБД.

[mazzy]

Да, и еще одно. В каких языках "можно легко сделать сортировку по выражению"?
В Fox'е?

И еще. "Сортировка по выражению" - это не то же самое, что "сортировка по части поля"

[Grizzly]

Цитата:

Изначально опубликовано mazzy
Хм... то что вы хотите противоречит рекомендациям по нормализации реляционных баз данных. Противоречит даже первой форме. Заметьте даже не рекомендациям Аттейна, а самих баз данных.

Уважаемый mazzy! Вы не правы. Нормализация данных накладывает определенные ограничения на набор сущностей, ввиде которых может быть представлена информация, следовально, и определяет способ хранения данных, но никак не влияет на возможности языка запросов.

Цитата:

Изначально опубликовано mazzy
Да, и еще одно. В каких языках "можно легко сделать сортировку по выражению"?
В Fox'е?

Это любая реляционная СУБД (во всяком случае промышленная). Например, возьмите базу Attain в SQL server и выполните к ней запрос

SELECT 'val - '+No_,Name FROM "CRONUS Россия ЗАО$Customer" ORDER BY 1;

'val - '+No_ - есть ничто иное как выражение. И запрос сортирует результирующее множество по этому выражению.

Что казается NA, то он умеет сортировать только по ключу.

[Lazy_Tiger]

Угу. отсортирует. План этого запроса видели? я б пристрелил бы программера который эту фичу использует в боевую и на приличном объеме данных

Кроме того, Сергей (Mazzy) прав. Желание Ваше противоречит первой нормальной форме. Откройте учебник пожалуйста.

[Grizzly]

Цитата:

Изначально опубликовано Lazy_Tiger
Угу. отсортирует. План этого запроса видели? я б пристрелил бы программера который эту фичу использует в боевую и на приличном объеме данных

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

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

Цитата:

Изначально опубликовано Lazy_Tiger
Кроме того, Сергей (Mazzy) прав. Желание Ваше противоречит первой нормальной форме.

Во-первых, это не мое желание (см. историю).

Во-вторых, "Желание Наше" не противоречит 1NF. Напомню ее определение: "Схема отношений находится в первой нормальной форме тогда и только тогда, когда все входящие атрибуты являются атомарными". И где здесь противоречие с тем, что при выборке я могу сортировать записи по значению выражения?

Цитата:

Изначально опубликовано Lazy_Tiger
Откройте учебник пожалуйста.

Я думаю, это Вам пора повторить матчасть, или, по крайней мере, менее свободно ее трактовать.

[Lazy_Tiger]

угу. определение то правильное... но там есть слово "атомарными". Таким образом Вы пытаетесь атомарный атрибут поделить на части И использовать каждую часть по отдельности. Т.е. атрибут в контексте Вашей задачи атомарным не является
Противоречит?

P.S. И кто из нас более свободно трактует?

[Grizzly]

Цитата:

Изначально опубликовано Lazy_Tiger
угу. определение то правильное... но там есть слово "атомарными". Таким образом Вы пытаетесь атомарный атрибут поделить на части И использовать каждую часть по отдельности. Т.е. атрибут в контексте Вашей задачи атомарным не является
Противоречит?

P.S. И кто из нас более свободно трактует?

Уважаемый Lazy_Tiger! То ли Вы такой невнимательный, то ли на то существуют другие причины, из-за которых Вы меня постоянно путаете с Nik. Но я НИ РАЗУ не пытался использовать части атрибута по отдельности. Мой ответ был собственно на пост mazzy, в котором он утверждал что сортировка по выражению противоречит 1nf.

[Vadik]

Ничего, если я встряну?

Цитата:

Таким образом Вы пытаетесь атомарный атрибут поделить на части. И использовать каждую часть по отдельности

Странно, мне всегда казалось, что все НФ описывают хранение, но никак не сортировку записей при выборке. Если продолжить Вашу мысль, надо будет запретить операторы LIKE, DatePart() и их аналоги - они же возвращают части атомарного атрибута. Хранить дату, день, месяц и год - действительно денормализация, хотя и на нее идут при наличии веских причин, но ведь речь шла не об этом

[Lazy_Tiger]

ОЙ! сорри, вот ник то я как раз и не смотрел.

[dn]

Цитата:

Изначально опубликовано Nik
сортировку сделать в порядке: месяц, день, год.

Как в Attain к сожалению не знаю. В MS SQL можно, например, пойти таким путем:
преобразовать поле типа дата в строку в формате mm-dd-yyyy и сортировать по этой строке. Может быть это чем-нибудь поможет.

PHP код:

select  *  from t1
order by CONVERT (varchar(10), d1 , 110) 


[Grizzly]

Если это действительно ОЧЕНЬ нужно, то можно поступить так.

В отчете организовать вложенные циклы с помощью таблицы Целое. Первый цикл - месяцы (1..12), второй - дни (1..кол-во дней в месяце), третий - годы. Четвертый dataitem - нужная тебе таблица. Внутри третьего цикла устанавливать фильтр по дате, используя номер года, месяца и дня, на нужную тебе таблицу. Таким образом записи из твоей таблицы будут выводиться в нужном порядке.

Это конечно не сортировка, но конечный эффект будет таким же.

[Nik]

Grizzly, спасибо за идею. Попробую воспользоваться.
Со своей стороны хочу заметить:
1. Желание отсортировать, например, юбиляров не по возрасту а по дате рождения, естественно для ОК, когда списочный состав тысяча и более человек. Нелепо заставлять их делать выборку очередного юбиляра вручную из распечатки!
Сортировка по выражению снимала бы все проблемы, но ее в Attain нет. Нормализуя базу разработчики Персонала и Зарплаты почему-то не задумались, кому нужен список дней рождения, без нужной сортировки. Подскажите Grizzly, как эту проблему можно решить "через изменение потребностей пользователя"?
2. Подход к нормализации Персонала и Зарплаты у меня вызывает удивление. С какой целью разработчики ушли от третьей нормальной формы. Буквально везде в полях хранятся вычисляемые значения. Для быстродействия? А как быть с аномалией обновления? Ведь они ее не ослеживают! Изменение наименования подразделения или должности в справочнике, никак не отражается, скажем, в штатном расписании!

[Grizzly]

Цитата:

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

В данном конкретном случае, думаю, никак

В том же сообщении чуть ниже я сказал, что если:
1) объем результирующего множества невелик (не поставит систему "колом" во время выполнения запроса)
2) данный запрос выполняется не часто (не приведет к существенному снижению общей производительности системы)
3) требования к выходной информации изменить нельзя,
то "я бы пристрелил программера, который ради этого стал городить огород, а тем паче менять структуру БД"

Данная задача, как мне кажется, из этой категории

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

Цитата:

Изначально опубликовано Nik
2. Подход к нормализации Персонала и Зарплаты у меня вызывает удивление. С какой целью разработчики ушли от третьей нормальной формы. Буквально везде в полях хранятся вычисляемые значения. Для быстродействия?

Нормализация не догма, а руководство к действию

Иногда существует конфлик между соблюдением требований нормализации и требованиями, предъявляемыми к системе. А любая ИС создается не для того, чтобы демонстрировать свое соответствие математичекис теориям, а для решения конкретных задач. Крис Дейт в своем классическом труде "Руководство по реляционной СУБД DB2" на эту тему сказал: "Принципы нормализации рекомендуют руководствоваться критерием "один факт в одном месте"; но иногда есть существенные причины для того, чтобы иметь два факта в одном месте или один факт в двух местах". Использование принципов нормализации в РСУБД в некоторой степени было призвано оптимизировать операции по модификации (создание, обновление, удаление) за счет сокращения избыточности данных. Но иногда избыточность бывает полезна с точки зрения оптимизации операций по выборке.

Все относительно...

Кроме того, даже атомарность атрибута, о которой говорил Lazy_Tiger, вещь тоже достаточно относительная и определяется выполняемыми над ним операциями. Вот с одним из таких проявлений относительности атомарности атрибута Вы и столкнулись (иногда дату нужно рассматривать как набор из трех атрибутов, но чаще удобнее как единое целое). И, на мой взгляд, никакого противоречия с требованиями 1nf здесь нет.

[Nik]

Grizzly, возможно в общем плане Вы и правы. Но, в то же время, такой подход удобен, он позволяет "завуалировать" любые ошибки разработки. А ресурсы в системе не безграничны. Решая проблему, скажем, производительности , нужно предвидеть к каким отрицательным результатам это может привести. А в результате, забив таблицу Employee вычисляемыми полями, разработчики не оставили маневра для кастомизации. Мы, добавив необходимые для себя 20 полей, уткнулись в предельную длинну записи 4k. И теперь на "нашем кусочке" нормализация для нас догма.

[Grizzly]

Цитата:

Изначально опубликовано Nik
Grizzly, возможно в общем плане Вы и правы. Но, в то же время, такой подход удобен, он позволяет "завуалировать" любые ошибки разработки. А ресурсы в системе не безграничны. Решая проблему, скажем, производительности , нужно предвидеть к каким отрицательным результатам это может привести. А в результате, забив таблицу Employee вычисляемыми полями, разработчики не оставили маневра для кастомизации. Мы, добавив необходимые для себя 20 полей, уткнулись в предельную длинну записи 4k. И теперь на "нашем кусочке" нормализация для нас догма.

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

P.S. Я предложил Вам вариант как отсортировать записи по датам, предполагая, что они находятся на относительно небольшом временном расстояни друг от друга. Но если это касалось дней рождения, то я считаю что этот вариант неудачный. Для этого случая лучше использовать что-то подобное прилагаемому отчету.

[mazzy]

Хм... Grizzli, почти готов согласится.
Думаю, что об этом можно обсуждать в кругу специалистов.
Но вряд ли Nik спрашивал в этом смысле...


Это все равно, что утверждать, что "Водка полезна". Да, существует масса случаев, когда это утверждение истинно. Мало того, существует масса случаев, когда без нее невозможно обойтись. Но начинать с такого утверждения разговор с незнакомым человеком я бы не стал.

[Nik]

Здорово! Большое спасибо за решение. Только прошлось добавить проверку на незаполненные даты. Если можно, поясните подробнее, что это за несуществующая таблица Целое.

Цитата: Т.е. Вы ставите в вину разработчикам, что они разместили в системе столько функционала, что Вам некуда поместить свой?

Конечно не это. В реальной системе функционала всегда нехватает и система должна иметь ресурсы на его расширение. Расточительное использование ограниченного ресурса ведь не увеличило функционал, скорее, упростило работу разработчиков.

[Grizzly]

Цитата:

Изначально опубликовано Nik
[B]Если можно, поясните подробнее, что это за несуществующая таблица Целое.

Это специальный механизм в NA, который позволяет организовать цикл, используя синтаксис работы с таблицами.Существует также другие "спец" таблицы. Этот вопрос уже обсуждался в одной из веток этого форума (по-моему "События главного меню").