Поясните если заводить регистры сведений у которых измерение будет иметь тип "строка" длиной 500-750, то будет ли это считаться плохим стилем?

да

(1)можете пояснить подробнее?

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

(2) такие штуки ведут к увеличению размера базы и падению производительности

Это будет ужасным стилем.
Обрекающим тебя на....

(3)то есть измерениями нельзя делать такие длинные строки а только справочники?

уволят ...
а в остальном будет все нормально
это хрень не индексируестся

(5) ссылки в измерениях хороши

Измерения - индексируются.
"индекс может быть создан на основании нескольких полей. В этом случае существует только одно ограничение – длина ключа индекса не должна превышать 900 байтов."
http://www.sql.ru/articles/mssql/03013101indexes.shtml#5

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

а ты попробуй сделай еще

(0) это не правильно.

Тогда уж неограниченная длина

если найдешь спопсоб как неограниченную в измерения втиснуть = отпишись
там защита от дураков стоит

Лучше всего сделать справочник с этими строками патом они будут как ссылки везде. Если как строка регистра то она будет дублироваться везде. Неограниченную патом придется приводить к строке чтоб сравнить.

Хотя... попробовал, SQL съел и > 900.

(13) это же так сложно да? привести к строке ? целых пара слов

(0) яйца бы резать у этих людей, в мире бы не было меди звончей (с)

А если в ресурс поставить поле типа "строка" то это будет некорректно?
У нас примерно такие причины заведения регистров.
в документе руководители пишут в текстовое поле задачи для пользователей. А при проведении это пишется в регистр. только почему то в измерение. а измерение примерно такие
"Инициатор", "ВидМероприятия". И вот "Задача" как раз текстовое поле.

(17) Жесть

(18)решится ведь если в ресурс это поставить?

(19) не надо эту хню в регистр пихать

(17) зачем "Задача" делать текстовым полем, это ж объект ?

(17) Руки и ноги оторвать тому неучу, что эту фигню породил. Срочно - в школу , за парту, учить базовые основы. Если строка не типизирована - она нафиг нужна как измерение в регистре.

понапридумывают себе мигреней, потом по аптекам бегают..

(21)в данном случае это не объект. это просто формулировка.

(19) Конечно. От головы еще топор помогает.

(23) Уже наказан :) v8: В процессе обновления информационной базы произошла критическая что это?

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

вот интересно, а кто то из присутствующих посмотрел РС Штрихкоды в УТ11

запросы будут валиться в некоторых случаях ... в режиме 8.2

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

(24) ежели текстовая формулировка, то как собираетесь делать отчет по задачам? Тут понапишут туеву кучу разных формулировок по одинаковой задаче, с разницей в запятых или пробелах. Тогда уж надо справочник "Задачи" делать, тогда и вопрос сам по себе решится

(31) документ и он в системе уже есть

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

(33)Какой смысл тебе еще надо? Тебе люди дело говорят.

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

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

(35)ну и что что она может быть общей для нескольких исполнителей. у нас есть подчиненная таблица исполнителей для каждой задачи. им всем рассылается задача.

(37) Вы неучи. Для всего это существует объект задача.

(36)(37) ну так, тогда, зачем текстовое измерение, ежели происходит создание объекта "задача" ?

(38)в (36) я об этом уже написал что задачи отправляются из документа. Но пока этот механизм не был реализован с задачами, приходилось просто в регистр запихивать формулировки и отчет из этого регистра формировать.

(39)а пока с задачами не реализовано было, приходилось так делать. для отчета.

(40) то есть, у тебя в двух разных местах базы жила одна и та же длинная строка?

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

(42) + С каждым исполнителем строка дублировалась.

(42)получается да. ну смотрите. она и так и  так жила бы еслиб мы даже сразу через задачи реализовали всё это. получается, что документ в этом случае тоже лишнее звено в цепочке.

(44)нет. не дублировалась. исполнители в подчиненной табличной части жили. одна задача - несколько исполнителей.

(45) да нет, просто в документе вместо ввода текстового поля "Задача" нужно открывать форму выбора/создания задачи

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

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

Ну да, архитектуру можно набросать на бумажке, а можно выстраивать из разного рода написанной ахинеи постепенно переделывая, вырезая и из неё откровенно лютый п-ц. Только на это могут уйти годы.

(50)ну что. зато теперь есть что оптимизировать. и эта формулировка будет жить только в объекте "бизнес процесс"

(49) необязательно из бизнес-процесса, можно и как у Вас, из документа. См. типовую ЗУП, там есть "Задача исполнителя", а бизнес-процессов нет.

(52)ну а если много-этапная задача, то в бизнес процессе.

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

В данном случае скорее всего имеет место быть троллинг со стороны Еврейчик -а (Cerera)
Ладно там в Оффе, пусть с ним.
Но тематику трогать не стоит.
Еврейчик, какие ваши доказательства, что вы просто тупите, а не троллите?

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

(55)и эту ветку я создал чтоб узнать веские причины почему нельзя так делать. я сам конечно же знал что нельзя строчками измерения делать но мне нужно было грамотное объяснение, которое я сам не мог сделать. теперь нам придется базу переделывать.