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

Разве 1024 символа переменной строки не достаточно (поэмы пишем)???

Одни минусы(основные):

1) Нельзя использовать в запросах упорядочивание по этому полю(и куча других ограничений в запросах от 1С)

2) При чтении данных (при OBJECTPROPERTY 'TableTextInRowLimit' в off)
происходит обращение не только к страницам с данными, но и по указателю к страницам, хранящим эти BLOB данные, что не может не замедлять запросы.(В профайлере сначала не понял, что скуль пытается сделать)

"происходит обращение не только к страницам с данными, но и по указателю к страницам, хранящим эти BLOB данные, что не может не замедлять запросы"
А фирме 1с официально пох на это.
Покупайте крутое железо

А сам что думаешь :)

(2) я всегда считал что в 1с работатют не программисты, а кодеры + полукомпетентные руководители проектов в большом количестве.
У них токо "Аллоды" были не глюкавые, но тормозили круто для 2Д

:)

Нехрен использовать комментарий для упорядочивания и прочего в запросах!
Он не для этого создавался
В семерке строки неограниченной длины есть смысл использовать именно для каментов ибо они или хранятся или не хранятся вовсе, что положительно сказывается на объеме БД
Мегаспецы, пелять, только обсирать могут...

(5) Вполне можно сортировать по лимитированной строке переменной длинны, а использовать неограниченные строки вообще не есть хорошо.
Так же можно хранить статистику о неограниченных строках, что бы иметь представление о длительности операций с ними.
Но 1с это не волнует.

(5) Слушай ты, мегаспец, по твоему храние данные в разных страницах положительно сказывается на размерах БД ?

Комментарии я привел как типичный пример использования.
На вскидку:

РегистрыСведений.ДанныеНезарегистрированныхКонтрагентов.Ресурсы.НаименованиеКонтрагентаПолное
Справочники.Банки.Реквизиты.Адрес
Справочники.Банки.Реквизиты.Телефоны
Справочники.ХранилищеДополнительнойИнформации.Реквизиты.ИмяФайла
Справочники.Организации.Реквизиты.НаименованиеПлательщикаПриПеречисленииНалогов
Документы.АккредитивПереданный.Реквизиты.ДокументыКПредъявлению

Предлагаю жить мирно, и если есть конструктивные ответы, то выкладывать.
Всегда открыт к конструктивному диалогу.

а зачем вапще используется комментарий?

(8) с лимитированными строками переменной длинны упорядочит?
(9) для ручных операций полезно

для начала автору было бы неплохо научиться не писать в заголовках слова заглавными буквами без нужды.
А строка неограниченной длины лучше потому. что используется комментарий крайне редко, а хранится не в таблице объекта, нагружая ее, а в отдельной таблице.
Для тех, кому нужно использовать в запросах эти поля, советую использовать ВЫРАЗИТЬ(Поле КАК СТРОКА(1000)).

Забавно... )
(8) Конструктивно, могу сказать следующее: лично мне, никто не запрещает упорядочивать по строкам неограниченной длины, а также делать по ним условия и т.п.

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

(5) +1000000

(13) может бухи там делают пометку какую-то

Комментарий - это всего лишь флуд пользователя для пользователя... А не полезное поле для дел и т.п.

(16) это не исключает необходимости упорядочивать.

(11)
1)Вот именно, что при чтении (при любом обращении к элементу 1С считывает все данные) идет обращение (и чтение, и запись, и блокировка) и по указателю.
2) Тогда уж лучше ВЫРАЗИТЬ(Поле КАК СТРОКА), т.к. убираются не нужные пробелы

(12)Существуют некоторые ограничения, например нельзя напрямую ссылаться на столбцы типа ntext, text или image в предложении WHERE. Эти столбцы могут содержаться в предложении WHERE в качестве параметров функции, возвращающей другой тип данных, например ISNULL, SUBSTRING или PATINDEX, либо в выражениях IS NULL, IS NOT NULL или LIKE. (Электронная документация по SQL Server 2005 )

(14)А вас уважаемый, я уже давно за специалиста не считаю...

(17)Не обращай на него внимания, почти все его ответы пустозвонство.

(18) меня вот другое волнует... х.ли я делаю на работе в 21:30 в выходной за 40 км от города ? о_О

(10)Да, это строковый тип nvarchar(твоя длина), по которой можно полоноценно упорядочивать.

(19)А завтра потребуют без опозданий :) ?

(21) Надо просить отгул. Думал сегодня халтуру доделать, уже пообещал. Думал дома в 16:00 буду. Меньше думать надо

Steelvan , токо не уходи спать!! а то скучно

Думается мне, что и конкатенацией они все отс..., ой... не получится  у них ничего :)

До скольки думать собираешься ?

(24) ниче не понял про concat и неогр. строки
(25) пока не перестану

(0)относительно того что напортачили в 1с - полностью согласен.
з.ы. у себя в конфе урезал до 250 символов.
во всех документах и справочниках. Ибо нех.

(27) +1

(26)А чего не понятого,

Выразить (Номенклатура.Комментарий как строка(100)) + "к"

преобразуется в :

CAST(_Reference32_Q_000_T_001._Fld541 AS NCHAR(100)) + N'к' f_2

И получается :
трампарам            к
(офигенная конкат.)


А на код:
Выразить (Номенклатура.Комментарий как строка) + "к"
ругается.

(29) т.е. Конкат не катит для бесконечных строк?

Генератор случайных вопросов ?

:)

(31) черт, меня раскусили

Кончил... тьфу, ЗАкончил бы уже, да спать лег.

Смысл ВЫРАЗИТЬ(Поле КАК СТРОКА(1000)) имеено в числе 1000.
Если использовать ВЫРАЗИТЬ(Поле КАК СТРОКА), то как была строка неограниченной длины, так и останется.
А смысл действа в том, чтобы сделать из строки неограниченной длины строку ограниченной длины.

(34) Да уже кончать скоро... наделюсь. Совещание.
Ещё есть генератор случайных ответов....! коэф попадания 80%

(35) все равно природа "неограниченной" строки не ясна. Все в компе дискретно

(35) Ну, кому-то не ясна, а у кого-то и высшее образование по этому ;))

(38) Это не правильная типизация. СтрДлина() хоть вернет что-то от такой строки?

Думается мне, что смысл сего действа в том, что :

ВЫРАЗИТЬ(Поле КАК СТРОКА(1000))

меняет тип ntext на nchar через

CAST(_Reference32_Q_000_T_001._Fld541 AS NCHAR(1000)) f_2

которым вы дальше и оперируете (см 18)
а инструкция :

ВЫРАЗИТЬ(Поле КАК СТРОКА) так и остается

_Reference32_Q_000_T_001._Fld541 f_2 типом ntext

P.S. может имеет смысл ВЫРАЗИТЬ(Поле КАК СТРОКА(1024))

(39) Конечно вернет, двоечник.
СтрДлина возвращает не размерность типа, а размер конкретной строки.

(40) А при чем здесь 1024?

(38)Так, для справки.

Если значение данных типа ntext, text или image не длиннее, чем строка в Юникоде длиной 4 000 символов, символьная строка длиной 8 000 символов или двоичная строка длиной 8 000 байт соответственно, то на такое значение можно ссылаться в инструкциях SELECT, UPDATE и INSERT точно так же, как и на более короткие типы данных. Например, на столбец типа ntext с коротким значением можно ссылаться в списке выбора инструкции SELECT точно так же, как на столбец nvarchar

(41) и причем здесь двоечник? Будем пипками меряться?

(42)Получаем максимально возможную длину строки возвращаемую 1С (на всякий случай)
:)

(44)Для задора лучше кофе попей :)

(43) И что?
Лучше сделать реквизит размерностью 8000 символов, который будет заполняться раз в пятилетку, чем строку неограниченной длины, который будет храниться вообще в другой таблице?

Я спать.
А то и так болею, а с вами сейчас еще до реляционных таблиц и нормальных форм таблиц доберемся.

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

(49) К чему бы... ?
"По настоящему добродетельному человеку можно всё." :)

(47)Расслабься, чего так взьелся :), просто мне показалось что вам это будет нитересно.


Да не в другой таблице он храниться, а в другой странице в этой таблице:

Если параметр text in row не задан, строки типа text, ntext или image хранятся вне строки данных; в строки данных входят только текстовые указатели на значения. Текстовые указатели указывают на корневой узел дерева, состоящего из внутренних указателей, сопоставленный со страницами, из которых состоит строка, где хранятся данные типа text, ntext и image.

И еще :

Если в строке данных хранятся строки типа BLOB, считывание и запись строк типа text, ntext или image может производиться так же быстро, как считывание и запись символьных и двоичных строк. SQL Server не требуется получать доступ к отдельным страницам для считывания или записи строк типа BLOB.

Использование параметра text in row
В SQL Server 2005 пользователи могут применять параметр таблицы text in row для хранения данных типа text, ntext или image в строке данных.

Для включения этого параметра выполните хранимую процедуру sp_tableoption, задав text in row в качестве названия параметра, а в качестве значения — on. Установленный по умолчанию максимальный размер хранящихся в строке данных типа BLOB (большого двоичного объекта), например данных типа text, ntext или image, равен 256 байт, но допустимы значения в диапазоне от 24 до 7 000. Для определения максимального размера, отличного от установленного по умолчанию, задайте в качестве значения целое число из этого диапазона.

Строки типа text, ntext или image хранятся в строке данных при выполнении следующих условий:

Параметр text in row включен.


Длина строки не превышает максимального ограничения символов, указанного в @OptionValue.


В строке данных достаточно места.


Если в строке данных хранятся строки типа BLOB, считывание и запись строк типа text, ntext или image может производиться так же быстро, как считывание и запись символьных и двоичных строк. SQL Server не требуется получать доступ к отдельным страницам для считывания или записи строк типа BLOB.

Если строка типа text, ntext или image превышает максимальное ограничение символов или доступное место в строке, в строке сохраняются указатели. При этом условия для хранения строк типа BLOB в строке остаются действительными: для хранения указателей в строке данных должно быть достаточно места

Вы все страшные СУБДшники

Мдяяяя, вы еще предложите для картинок делать поля фиксированного размера. И индексировать их.

(54)В данном случае речь идет о комментарии, а не о Хран, Знач.

точнее о поле, где вряд ли будешь хранить данные больше 1024 символа.

(56) а если писать на иврите, то и 512 хватит. Там гласных букв нету

(0) этот вопрос нужно задать здесь http://partners.v8.1c.ru/forum/index.jsp

(58) а не пошлют?

(59) То есть подсознательно ты понимаешь, что вопрос тупой? ;-)

(60) не тупой, но пошлют