справочники с длинной кода =0
 

Пересматривая объекты типовой упп увидел справочники с длиной кода =0. Зачем такое программное решение?

Что-то смущает? Если Код не несет никакой смысловой нагрузки - зачем он в БД?
У меня есть справочники с длиной кода = 0 И длиной наименования = 0.

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

3-dvva >Чего сказать-то хотел?

Я не думаю, я знаю.
Поле в таблице не создается, соответственно, ряд индексов не строится

4-chief accountant >
Хотел выслушать мнение какой достигается эфект при отказе от рекизита который я считал предпоределенным.

6-dvva >"можно обойтись без лишней сущности, значит, обходимся без лишней сущности" © VZ

:) ок.
спасибо.
можно закрыть тему

3-dvva > искать по коду - моветон

(9) у ТТО это высший пик достижений

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

11-Sk0rp > можно же и "системный Код" из БД вытянуть, хотя это несколько "кустарно" и не "промышленно".

11-Sk0rp > Можно пример?
Если код не нужен в исходной ИБ, то с высокой степенью вероятности и поиск и идентификацию при обмене можно (а скорее всего даже нужно) проводить без его участия.

13-roma n> Можно и пример.
В типовой бухгалтерии есть подчиненный справочник ВычетыСотрудниковПоНДФЛ, с нулевыми длинами кода и наименования.
Что бы выгрузить его (и в дальнейшем иметь возможность догружать новые элементы) пришлось добавлять код.

14-Sk0rp > хм, навскидку, почему нельзя было использовать составной код - типа вид вычета + даты?

15 - не уникальный, может быть много одинаковых вычетов с одними и теми же датами.
Уже не говоря о том, что дату бухи потом и поправить могут.

9-Uho > я не собирался искать по коду, а просто заметил что при длинне 0 кода вообще нет как реквизита

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

17-dvva > тогда объясни свое высказывание:

"а вот подход программынй надо делать разный так как у этих объектов логического поля код вообще нет."

19-Uho > допустим надо напечатать содержимое нескольких справочников. для тех кто с кодом
логично выводить код+наименование, для безкодовых надо в запросе только наименование выбирать. это не рабочая ситуация, а просто пример требующий разной программной реализации для одинакового объекта метаданных "Справочник".
roma n отвечал что отказ от избыточных рекизитов позволяет сэкономить на размере базы и индексов

ИМХО выигрышь очень маленький, овчинка не стоит выделки

20-dvva > не путай следствие с причиной: экономия - не цель, а "побочный эффект"

21-roma n > если это не цель, тогда возвращаясь к началу
ЗАЧЕМ???

20-dvva >Может скажешь, что там за объект в УПП без кода

23-chief accountant > легко
бюджеты
номера гтд

24-dvva >Тогда для тебя (14) ниочём

25-chief accountant >ну почему :) как пример что отсутствия кода вызывает проблемы, вполне понимаю

Затем, что они не нужны. Никому. Они никем не заполняются, никто их не видит, они не влияют на поведение системы (не используются в алгоритмах)... Зачем они нужны?

27-roma n > не нужны просто сделай их невидимыми.

зато подход к обработке элемента метаданных справочник будет ЕДИНЫЙ

28-dvva > и напихать во все справочники реквизиты Строка1, Строка2, Строка3,... Дата1, Дата2, Дата3,...,
Пусть непонятно, зато как удобно: обращения к любому реквизиту будет происходить единообразно :)
Нужна грань между целесообразностью и маразмом. Ты видишь её в одном месте, я в другом. Только и всего

29-roma n > согласен что грань нужна
поэтому и спрашивал аргументы ЗА и ПРОТИВ. и единственный пока аргумент это "целесообразность", но так не бывает целесообразность ради самой себя. Так что БУДЕМ ИСКАТЬ с перламутровыми пуговицами т.е жда ть аргументов которые покажут физическую выгоду от этого(отказ от кода) решения

30-dvva >Тебя послушать, так надо в каждый док пихать кнопки "Записать","Провести","Печать","Ок" и "Закрыть"???
Ф топку такую логику

20-dvva > "для тех кто с кодом
логично выводить код+наименование, для безкодовых надо в запросе только наименование выбирать"

хочешь универсальности - составляй запрос с проверкой на существование того или иного реквизита.

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

[url]http://www.1cexpo.ru/informacziya/28-indeksy-tablicz-bazy-dannyx-1s-predpriyatie-82.html[/url]
Соответственно, при нулевом наименовании и коде таблица получает минус два индекса. Это ОЧЕНЬ хорошая прибавка к скорости записи

34-Lexusss > воооот "на 21-roma n >"не путай следствие с причиной: экономия - не цель, а "побочный эффект"

значит это не следствие а ПРИЧИНА !!! и тогда я согласен что это НАДО(возможно :) ьак как справочники которые я привел второстепенные и скорости не сыграют

(34)+
при ЛЮБОМ значении МИНУСА количества ИНДЕКСОВ прибавка к скорости растет минимум в линейном порядке от размера индексируемого объекта бд
ЗЫ
о чем речь то? пестики, тычинки...

14-Sk0rp >А зачем? Всегда доступен системный код объекта, который в отличие от реквизита Код нельзя изменить между сеансами обмена непутевыми пользователями.

37-victuan > системный код объекта

guid ?

В 7.7 ЗначениеИзСтрокуВнутр/ЗначениеВСтрокуВнутр(ТекСпр)
Про 8-ку не скажу, не знаю ее методов наизусть.

Хм.. Чем плох метод НайтиПоКОду?