Возникла необходимость добавить реквизит в самый большой справочник - справочник Партий товаров. В реквизите должна быть фиксированная инфа, типа, "Брак", "Бывшее в употреблении", "Образец" и т.п.
Как оптимальнее сделать реквизит: строковым с неопределенной длинной, или числовым и использовать таблицу соответствия?
Мне так кажется, что даже пустая строка должна занимать минимум 4 байта - типа, пустой указатель. Не? Да, и еще сразу вопрос: в 1С юникодовые символы или нет? То есть, по одному байту занимают или по два? Я где-то читал давно, что юникодовые, но могу ошибаться. Может это тоже было лишь предположение, а у меня отложилось в памяти, как истина...

народ не проснулся еще, что ли? Как-то крайне сомнительно, что никто не знает таких вещей... По-любому ведь каждый второй знает, но молчит :(

Сделай и посмотри таблицу на скуле

wiki:UTF-8

справочник Партий товаров

Это че у тебя за дедовские поделки?

Времен 7.7

(0)ПЕРЕЧИСЛЕНИЕ !!!

(3) не понял к чему ссылку кинул.
(4) У нас собственная конфа, которая изначально разрабатывалась на 1С7.х, позже, с доработками была перенесена на 8.0, потом на 8.2

(6) В этом поле может быть сразу несколько значений. Например, и брак и б/у

(7) Ну почитаю, сколько там байт на символ.

+(8) А может не быть ни одного :)

(8) Значение перечисления - брак и бу.

(10) Значение перечисления - пусто.

(9) Так в 1С UTF-8? Меня этот вопрос интересует, а не что такое UTF-8 - это мне объяснять не надо =)
(11) Идею с перечислением на заметку взял, но пока мне кажется, что этот вариант не подойдет.
А чем вообще перечисление выиграет у предложенных выше вариантов? Суть ведь то же соответствие, не?

(13) Минимизация секса у последующих программистов. И проклятий на твою голову.

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

Строка неограниченной длины - это ntext

ntext

   Данные переменной длины в Юникоде с максимальной длиной строки 2^30 - 1 (1 073 741 823) байт. Размер памяти в байтах вдвое превышает длину введенной строки. Синонимом по стандарту ISO для типа ntext является national text.

Datalenght() для текста
тестtest
выдал мне значение 8. Все верно.

Пардон, 16.

(16) Отлично! Спасибо! А можно ссылку откуда инфа?

http://technet.microsoft.com/ru-ru/library/ms173486.aspx

Что за день сегодня такой...

http://technet.microsoft.com/ru-ru/library/ms187993.aspx

(21) Хотел привести ссылку, как доказательство своим коллегам, но не увидел связи с 1С...

будь мужиком, вычисли размер NULL

(22) Посмотри табличку SQL

(23) :D По логике вещей должен быть 4 байта

(23) Изыди, не то прокляну.

(26) чей то ты сразу пижаму надел? я же не про Неопределено ))

http://v8.1c.ru/overview/Term_000000293.htm#1

+ (28) это я нашел про то, что в 1С символы в юникоде хранятся

(0) Если нужно максимально меньшего размера, я бы число сделал.
1 - "Брак", 2 - "Бывшее в употреблении", 3 - "Образец".
Запрограммировать легко (можно даже использовать другой справочник).

Перечисление скорее всего будет много места занимать: тип + ссылка.

(30) просто ссылка, зато ограничение на вводимое значение

(30) Я вот тоже за числовое представление. Если даже будет "брак" и "образец", например, то будет число "13", где каждый символ нужно будет рассматривать по отдельности и подставлять соответствие. Только для отчетов это слишком геморно будет.
Но такое решение мне подсказывает мой опыт в обычном программировании, а коллеги, программировавшие только на 1С, не соглашаются со мной. Пытаюсь найти либо свою правоту, либо свою не правоту...

(31) Значения итак будут ограничены. Это поле нельзя будет менять. Только мы, разработчики, будем иметь к нему доступ. Реализация этого пока обсуждается.

(30) А потом кто-то вводит необрабатываемое значение и все имеют длительные противоестветсвнные отношения.
И запрос будет выглядеть забавно
Где Реквизит = 1 // брак

(32) Принципы корректно применимые в классических среднеуровневых языках не вполне удачно переносить в 1с.

(33) а потом расширите, но всем разработчикам об этом забудете сказать

(34) Знаю. Поэтому и обратился сюда. Прекрасно понимаю, что могу ошибаться.

(35) Мы и есть все разработчики :D

(34) (35) Разработка не сложнее чем с обычным перечислением.


   |    ВЫБОР
   |        КОГДА БольничныйЛист.ПричинаНетрудоспособности = ЗНАЧЕНИЕ(Перечисление.ПричиныНетрудоспособности.ПоБеременностиИРодам)
   |            ТОГДА ЗНАЧЕНИЕ(Перечисление.СостоянияРаботникаОрганизации.ОтпускПоБеременностиИРодам)
   |        КОГДА БольничныйЛист.ПричинаНетрудоспособности = ЗНАЧЕНИЕ(Перечисление.ПричиныНетрудоспособности.ТравмаНаПроизводстве)
   |            ТОГДА ЗНАЧЕНИЕ(Перечисление.СостоянияРаботникаОрганизации.ТравмаНаПроизводстве)
   |        КОГДА БольничныйЛист.ПричинаНетрудоспособности = ЗНАЧЕНИЕ(Перечисление.ПричиныНетрудоспособности.ПоУходуЗаРебенком)
   |            ТОГДА ЗНАЧЕНИЕ(Перечисление.СостоянияРаботникаОрганизации.ПоУходуЗаРебенком)
   |        КОГДА БольничныйЛист.ПричинаНетрудоспособности = ЗНАЧЕНИЕ(Перечисление.ПричиныНетрудоспособности.ПоУходуЗаВзрослым)
   |            ТОГДА ЗНАЧЕНИЕ(Перечисление.СостоянияРаботникаОрганизации.ПоУходуЗаВзрослым)
   |        КОГДА БольничныйЛист.ПричинаНетрудоспособности = ЗНАЧЕНИЕ(Перечисление.ПричиныНетрудоспособности.Карантин)
   |            ТОГДА ЗНАЧЕНИЕ(Перечисление.СостоянияРаботникаОрганизации.Карантин)
   |        КОГДА БольничныйЛист.ПричинаНетрудоспособности = ЗНАЧЕНИЕ(Перечисление.ПричиныНетрудоспособности.Протезирование)
   |            ТОГДА ЗНАЧЕНИЕ(Перечисление.СостоянияРаботникаОрганизации.Протезирование)
   |        КОГДА БольничныйЛист.ПричинаНетрудоспособности = ЗНАЧЕНИЕ(Перечисление.ПричиныНетрудоспособности.ПособиеПриДолечивании)
   |            ТОГДА ЗНАЧЕНИЕ(Перечисление.СостоянияРаботникаОрганизации.ПособиеПриДолечивании)
   |        ИНАЧЕ ЗНАЧЕНИЕ(Перечисление.СостоянияРаботникаОрганизации.Заболевание)
   |    КОНЕЦ КАК Состояние,



(38) пясец

(36) охота вам ломать голову над всякой фигней? Это же не регистр, а справочник. Какая принципиальная разница, сколько там байт?

SQL разве будет намного сильнее тормозить от того 5 или 25 байт в строке?

a:=1;
b:=1;
c:=0;
res:=a*3+b*2+c*1;

(40) Большой очень справочник. Я боюсь, что если мы увеличим его поле, скажем, на 100 байт, то это скажется на производительности работы с ним. Может ошибаюсь.

А - брак
Б - б/у
C - образец

Для брака и Б/у записываем число 5

(43) производительность зависит от индексов, а не от размеров полей. Если неиндексируемое поле, можете хоть 1000 байт добавлять.

(0) ты же свой реквизит индексировать захочешь? подумай над индексом для нстроки, для числа и для перечисления
(32) расстреляй себя вчера!

(43) херней маешься, ИМХО. Сколько там щас элементов в твоем большом справочнике?

Ну и восстанавливаем

a:= round(res div 3);
res:= Round(res mod 3);
b:=round (res div 2);
res:= Round(res mod 2);
c:=round (res div 1);

Но вообще автор мается херней, но по сравнению с null/неопределено, это цветуечки...

Ненавижу 1С, я правильно все сложил/разложил?

Че, никто уже не помнит штоле, как старший/младший байт из двухбайтового получать?

(49) непонятно почему
res:=a*3+b*2+c*1;
а не
res:=a*4+b*2+c*1; //по степеням двойки

(51) Нафига? 3 варианта же..

(43) Блин, тогда сделайте через РС. Это вам даст возможность вести 1 к n
49 +1 (про автора)

(52) потому что 3=2+1 и 3=3 неоднозначно жеж
или я туплю, ну да и ладно ))

(52) ну и по байтам более православно

(49) можно убрать округление после взятия модуля, это съэекономит несколько тактов, ведь 1с однопоточное приложение. для экономии памяти можно а б ц в одну переменную засунуть д = а + б*16 + в*256. цифры прописать в тз, все равно никто, них кроме разработчиков, править не будет

(54) Дааа, ты чертовски прав.

(56) Это чтобы синтаксис контроль Дельфи не ругался.

(56) Так и предполагается - в одну переменную. Я писал об этом выше

но, по ходу, большинством голосов (2 против 1), было решено делать строковое поле.

Херней - не херней я страдаю, а вопрос оптимизации меня всегда волновал. Еще когда обычное ПО делал, мне частенько говорили, что не надо экономить на спичках. Но это мой бзик, видимо. Мои тараканы...

(59) выборку по твоей самоделке движок будет делать курсором, по всему твоему регистру. если вариант "135" то на клиенте, что конечно разгрузит бд, это тебе плюс

(60) >> Но это мой бзик, видимо.
в таком случае заведи себе еще один бзик, рефакторинг называется, а то перед поиском новой работы придется сначала порчу снимать...

(0)"Бывшее в употреблении" - 21 символ = 42 байта данных, не считая накладных. Поле с ссылкой на перечисление будет всего 16 байт. Зато потенциальных граблей в будущем не будет.

(63) "Бывшее в употреблении" скорее всего заменится на "БУ"

(60) Скажи где это. Чтобы туда не идти...

(64) дарю идею
бРак
бЫвшее в употреблении
обраЗец

(66) Предлагаешь выделить по одной букве? Чем это существенно отличается от числового поля по наглядности? Сокращать названия будем, разумеется, но не до одной буквы. Должно быть наглядно. "Б/у" - все знают, что такое.
Но спасибо за совет =)

еще вариант есть РС использовать, как доп.свойства в БСП.

(68) тут оптимизацией особо и не пахнет, имхо

(67) это путь стать незаменимым

сорри не внимательно читал, вчитался
>>...справочник партий ...

тогда уже не важно число это будет или строка и ХЗ что