Вот есть справочник "ГруппыСобытий". В Нём наименование 50 символов. Попросили увеличить. Вопрос - будет это правильно или в таком случае лучше оставить 50 символов и завести ещё одно поле "ПолнНаименование" ? как для базы будет оптимальнее?

(0) Увеличь, раз попросили.
ПолнНаименование - для печати.
Наименование - для поиска.
Назначения разные.
А базе - по барабану.

Это творческий вопрос. Лучше всего на него ответить с 23 до 7.

(1)база ведь будет пухнуть если ещё одно строковое поле завести длинное и по сути это будет дублирование информации. для печати ведь не используется оно в этом справочнике.

(3) Помедитируй на досуге над тем, чем отличается представление строк в базе 7-ки и 8-ки.

(5)так чем же интересно?

(6) А не поленись, поройся в документации.

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

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

(8) Я в то время уже работал. Насчёт экономии каждого бита - это тебе кто-то неправду сказал.

(8) хочешь сказать, в америках байты не считали?

(9) историю одного байта читал? она, правда, совсем-совсем о другом

(9)у меня же есть высшее образование. я учился на кафедре ЭВМ. там очень наглядно нам всё объясняли про оптимизацию.

(11) Именно что о другом. В embedded и сейчас байты экономят.

(12) Купи себе за это деревянную медаль.

2(12) а про пушку и воробьев и бритву оккама вам на этой копрокафедре не рассказывали?

В стандартах разработки есть рекомендация по длине наименований

JOB: Как стать сверх разработчиком и на какой должности такое можно получить? сверх разработчики не спрашивают о таких вещах, а смотрят как это физически устроено...

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

идем дальше, про "пухнуть", база на 100000 номенклатуры имеет например 1 гиг размера, 50 байт * 100000 - примерно 4,7 мегабайта, плюс немного индекс может увеличится, ну хорошо пусть будет 10 метров.... это примерно 0,1% от веса базы....

(17)про блобы и стринги я вкурсе. и про индексирование. а про то как на размер что влияет - собираюсь проверить сам.

Но начал как обычно с самого правильного - задал вопрос на Мисте.

(18) зачем это тебе? ты знаешь что в файловой базе примерно 50% места не используется??? и в скульной базе то-же много места просто "зарезервиравано".

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

(20)а почему такая дорогая конфигурация и настолько неоптимизированная?

(21) в УТ все торговые операции можно вести на одном регистре "ПартииТоваровНаСкладах", а там еще есть регистры "ТоварыНаСкладах", "ТоварыКСписанию", "Продажи", "Закупки" и т.д.