добавить описание источника в Фин книгу операций

[Fordewind]

Цитата:

Сообщение от Igor_A

Дело в том что это действительно нужно для отчетов, но каждый отчет переделывать более сложно, чем одну таблицу. Я так думаю. Поправте меня если я чего-то не допонимаю.
Спасибо.

Не надо хранить дубликаты информации. Это одно из первых правил. Просто напишите функцию в одном месте и вызывайте ее из разных

[Галина]

Цитата:

Сообщение от Igor_A

Дело в том что это действительно нужно для отчетов, но каждый отчет переделывать более сложно, чем одну таблицу. Я так думаю. Поправте меня если я чего-то не допонимаю.
Спасибо.

Игорь еще раз. Не делается так ни в каких системах. Если вы начнете добавлять Описание для Источника Номер, то за этим вас попросят-еще добавить Описание Фин.счета, а после Описание Кода Отдела и т.д. И в результате будет нарушено одно из важных правил-целостность данных. Потому что при изменении Описания в любой таблице - вам придется отслеживать это изменение во всех остальных таблицах, где запомнено это значение. Это неправильно.
Вы готовы поменять ВСЮ систему и принципы?
Если готовы-то вперед, только не забывайте, что после Вас кому то придется работать с таким исправленным Навижиным. Лично я бы не хотела. Итог - не создавайте проблем ни себе, ни тем кто придет после вас.
ЗЫ. И в любом случае отчет переделать ГОРАЗДО проще, чем лезть в учет

[i.andrievsky]

А если в TableRelation моего поля "описание" создать условие
IF (Source Type=CONST(Vendor)) Vendor.Name WHERE (No.=FIELD(Source No.))
можно чтоб он по умолчанию сразу по открытию таблицы выводил значения, без выбора каждого?
Спасибо.

[Yoil]

Цитата:

Не надо хранить дубликаты информации. Это одно из первых правил. Просто напишите функцию в одном месте и вызывайте ее из разных

А как насчет поля Description, которое протянуто в дикое количество таблиц? (строки заказов, накладных, счет-фактур и т.д. и т.п.)

[Галина]

Яков-ты не прав. Поле Description- это не дублирование операций. Приведи хоть какой нибудь пример?

[Yoil]

Причем тут операции? Fordewind говорил про дубликаты информации.
И, по идее, перенос поля description из карточки товара (счета, услуги...) в строку заказа продажи, например - это и есть то самое дублирование информации.

[Галина]

Fordewind говорил не про такое дублирование, которое ты говоришь. То что ты говоришь не дублирование информации-это описание операции по определенным правилам.
Объясню про дублирование-про которое здесь говорилось. Например-есть таблица 18 Клиент-в которой поля Но(ключевое поле=коду клиента в системе) и Название (Название клиента).
Так вот в 21 Cust. Ledger Entry - запоминается только КодКлиента(который берется из таблицы 18 и связан с этой таблицей) и , а вот если мы еще в 21 будем писать и Название (из этой же таблицы 18). Вот тогда это и называется дублированием. Конкретно мы дублируем поле Название. Это делать не надо.

[Yoil]

Ситуация с 37-й таблицей отличается лишь тем, что в поле "Но." может стоять не обязательно код именно товара, а может быть номер счета или чего-нибудь еще (в зависимости от типа). Больше ничем вообще. Поэтому я не понимаю, почему ты различаешь "мое дублирование" и "дублирование Fordewind'а"

[DA_NEAL]

Цитата:

Сообщение от Дуд

Ситуация с 37-й таблицей отличается лишь тем, что в поле "Но." может стоять не обязательно код именно товара, а может быть номер счета или чего-нибудь еще (в зависимости от типа). Больше ничем вообще. Поэтому я не понимаю, почему ты различаешь "мое дублирование" и "дублирование Fordewind'а"

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

[Yoil]

Ах речь о том, что это поле доступно для редактирования
Тогда да, тогда я не о том

[Галина]

Яков-ты опускаешь наиважнейшую деталь-связка поля с подчиненным справочником.
Причем здесь редактирование???

[Sancho]

вставлю пару копеек
дублирования в навижн полно, например зачем писать код товара в 5802, когда там есть уже ссылка на товар книгу операций, в которой этот код товара есть?
именно затем, чтобы потом было проще строить запросы (для отчетов, форм, вычисляемых полей), т.е. это дублирование, обычно, ОПРАВДАНО.
одно хочется сказать, что дублируются обычно поля типа Коде, которые полегче и побыстрее текстов.
есть еще одно "дублирование", которое выражается в полях типа флоуфилд лукап, это для того, чтобы формы было попроще делать, но оно не хранится. к сожалению, условный флоуфилд создать нельзя, а так бы именно он решил сразу все проблемы: если источник Клиент, то лукап на клиента, если поставщик, то лукап на поставщика.

предлагаю отсутствие условного лукапа считать недоработкой движка Navision!

[Галина]

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

[Kirvisniemi]

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

В тех же книгах по проектированию БД пишут, что ненормализованные базы - это плохо.

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

[Галина]

Цитата:

Сообщение от tyrex

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

Отлично-теперь знаю как это называется по правильному

[DA_NEAL]

Насколько я помню из институтского курса БД может быть аж в 5 нормальных формах, причем хорошей является третья нормальная форма - вот только работать в navision без встроеной возможности писать запросы практически невозможно

[Kirvisniemi]

Каждое решение - делать дублирование или не делать бывает хорошим в определенный момент времени.

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

А через год этому клиенту счет выставили уже за поддержку и за синхронизацию :-)

[Fordewind]

Вот это страсти!
Есть понятие "идеал" и "реальность". Так вот надо стремиться к идеалу по мере возможности.

[Konstantin I]

Еще можно добавить просто вычисляемое поле.