Где в SQL-сервере хранятся данные полей различных объектов с типом ХранилищеЗначения? #451509

Имеем различные объекты, пусть будут, к примеру справочники, с полями, имеющими тип "ХранилищеЗначения". Вопрос: данные этих полей ссылаются к одной таблице, или для каждого объекта такая таблица уникальна?

Все данные MSSQL хранятся на страницах по 8кб. Есть разные типы страниц: ROW_DATA, LOB_DATA, ROW_OWERFLOW_DATA (только на версии mssql >= 9). ROW_DATA - обычные данные используемые для хранения значений полей таблицы и хранения данных индексов. Эти данные ("ХранилищеЗначения", как и строки неограниченной длины) хранятся на специальных страницах базы: LOB_DATA, эти страницы относятся к основной таблице (в понятиях MSSQL) справочника. Страницы типа ROW_OWERFLOW_DATA используются для хранения данных обычных полей (не длинных) когда суммарный объем данных записи превышает размер страницы.

Мощно задвинул... Правда, перепутал "где" и "как" :)

в одной таблице все находится.

++как таковых отдельных таблиц для хранения длинных полей в MSSQL не существует. так лучше?

точнее не так (не сразу понял суть вопроса). нет такого понятия как отдельна таблица для хранилища значений. при создании реквизита типа "хранилище значения", в скульсервере создается колонка типа image, которая позволяет хранить данные до 2Гб информации.

прямые запросы к 8-ке хотите писать? По моему.  Нет жесткой привязки имен таблиц к метаданным. При очередном обновлении конфигурации 1С, в SQL базе таблицы могут удаляться и создаваться под другими именами. Это в 7-ке было. Добавил реквизит в 1С, написал запрос и он работает всегда и переживает обновления метаданных.

Нет. Хотим "разнести" данные с типом "ХранилищеЗначения". А отсюда вопрос - нужно ли вообще это делать?

не нужно

Это действительно так. Проверил только что. Но все эти данные типа image будут всё-таки находится в общей таблице?

а если нужно объект справочника прочитать, каждый раз будет переносится на клиента.

нет такого понятия как общая таблица для image. SQL сервер у себя выделяет место под данные типа image и в этом месте хранит всю информацию. в самой таблице хранится ссылка 8 байтная на конкретное место в файле.

может быть off но как вариант. Настроить такой хитрый план обмена, состав которого только те регистры и т.п., в которых те самые хранилища значений (ХЗ). При обмене из ЦБ в РБ передаются эти регистры и т.п. и при подтверждении того что они до РБ дошли, в ЦБ удаляются ХЗ, но в РБ этот факт удаления ХЗ не передаётся. В ЦБ при чтении данных ХЗ происходит подключение по COM к РБ и извлечение ХЗ... Всё равно если и городить огород, нужно для начала взвесить в чём.. ;)

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

Не понял, мог бы по-подробнее объяснить.

для начала что хотите добиться разнесением?

Не хотим все данные держать в одном физическом месте

Почему? О причине же спрашивали...

может организовать рейд и не париться?

Железо и всё, что с ним связано, будет последним средством достижения цели.

1с не та платформа, где я бы надеялся, что после махинаций над базой в самом SQL Server, все не вернется на круги своя после очередного обновления конфигурации..

Прикольно.. Вероятность отказа системы развернутой на двух физических местах вообще-то в два раза больше..

Я неправильно выразился. Под физическими местами имелись ввиду таблицы таблицы SQL-сервера

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

я специально не тестировал, но слышал высказывание специалиста из франчайзи... ;)  что например, фотографии номенклатуры практически не влияют на производительность SQL-ной базы, т.к. хранятся в разных таблицах. А вообще по моему во всех типовых 1С хранилища значений основных справочников, участвующих в учете, хранятся в регистрах сведений. Если делать две отдельные базы, то возникнет проблема синхронизации. Например, после аварии восстановили из бэкапа центральную базу, потеряли данных на сутки. А во второй базе остались зависшие "ссылки".

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

т.е. вы предполагаете, что в SQL Server есть отдельный объект - регистр сведений? =)

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

я имею ввиду что те же фотки в типовых 1С не реквизит справочника, а регистр. По моему желание чтобы всякие неосновные данные не составляли большую часть объема всей базы, т.к. чем меньше база, тем проще дешевле организовать её резервирование. Основные данные можно резервировать каждый день, а всякие ХЗ из другой базы раз в месяц. Вот поддерживала бы платформа 1с такие методы - регистр сведений с индивидуальными настройками на другую базу данных на другом сервере... ;) Было бы интересно.

о ДРУГОЙ БАЗЕ в этом топике вроде-бы говорите только вы.. А описанное в на MSSQL делается так: действительно данные разносятся по разным таблицам, и таблицы размещаются в разных файлах данных одной и той же базы. Бекапить можно и отдельные файлы данных. Файлы также можно размещать на разных носителях (возможно разной поизводительности). Вобщем-то и на 1С такое организовать не сложно, достаточно после каждой реструктуризации выполнять определенный SQL скрипт, всего-то делов.

ага, если он перелопатит в один файл, то каждая перемена файла хранения - все таки операция копирования и выделения места. делов-то.. =)

Интересно, у MS SQL Server 2008, который Enterprise, есть какие-то ограничения на размер одной таблицы

границу на размер таблицы вы даже и представить себе не можете.

поверьте, каждая реструктуризация в 1С это тоже самое, и ничего, все живы :)

Для 1С все-таки актуально хранить Хранилища в регистре сведений. Ибо в противном случае они будут гоняться туда-сюда

куда это: туда сюда? имеется в виду реструктуризация?

Ещё вопрос: возможен ли полнотекстовый поиск в случае ХранилищаЗначения?

нет.

я так понял, если пользователь будет выбирать данные из справочника номенклатуры через точку, тогда просто так будет гоняться и этот блоб объект. "и все таки я не люблю кошек! - ты просто не умеешь их готовить."

можно, но для очень ограниченного типа файлов (word, excel, pdf)

Провёл эксперимент: добавил запись в РС с ресурсом типа ХранилищеЗначения. Посмотрел размер SQL-таблицы, отвечающей за этот РС. Размер увеличился на величину размера записи. Т.е. если бы поле SQL-таблицы с типом image содержало лишь ссылку, размер таблицы бы практически не изменился.

еще раз. в поле строки таблицы хранится ссылка на место в файле, где хранится БЛОБ объект. т.е. ФИЗИЧЕСКИ не хранится сам БЛОБ объект в строке таблицы. когда учитывается размер таблицы, естественно суммируются все данные таблицы.

Как посмотреть, где же реально хранится BLOB-объект?

для вас это в одном месте. для сервера за пределами физического расположения страниц данных.

Так где же это место (для меня)?

Добавил в РС запись, значением ресурса которого является Word-файл. Полнотекстовый поиск ничего не нашёл по запросу.

Думаю обычным восмерочным запрсом ничего и не получиться. Я имел ввиду полнотекстовый поиск средствами ms sql.

Использовал обработку "Поиск данных"

оно не отделяемо и не будет механизмы разные

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