powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Большое строковое поле (XML). Как лучше ?
24 сообщений из 24, страница 1 из 1
Большое строковое поле (XML). Как лучше ?
    #39066042
ProBiotek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет.

Строю схему БД. Я больше по C#, потому лучше задам вопрос профессионалам.

Проект обменивается данными с другими системами посредством XMLлок. Причем они могут быть довольно большие, но могут быть очень большими (под 10 Мб). Предположительно - половина будет маленькими (запрос информации) а другая половина большими(ответ)
Все эти XMLки нужно сохранять. Как исходящие, так и входящие. Для истории, для анализа ну и т.д.

Как лучше спроектировать БД?

1. Имеет ли смысл сделать такую вещь
MainTable
id XmlId MessageField1 MessageField2

XmlTable
Id Xml

Даст ли это какой либо выйгрышь, или не важно вообще и можно оставить все в одной таблице ?

2. Имеет ли смысл упаковывать эти XMLки в какой-то Blob, даст ли это сжатие ?

3. Стоит ли заморачиваться со столбцом типа XML, или оставить nvarchar(max) ?
Никогда с ним не работал, не знаю насколько он прост/сложен/удобен в целом, в функциях, применительно к C#.

4. Какие индексы стоит сделать - какой кластерны, покрывающий, с include ?

5. Еще какие-то идеи для оптимизации. Стоит ли делать секционирование ?

Спасибо )
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066060
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ProBiotek,

Вы задали много вопросов, но не представили требования к системе хранения XML данных. Требования являются основанием той или иной реализации.

Модератор: Тема перенесена из форума "Microsoft SQL Server".
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066086
ProBiotek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владислав Колосов,

Мне нужно создать базу MS SQL Server 2014. Создать в ней таблицу (или таблицы) для хранения XML сообщений и служебной, к ним, информации.

Будет приходить запрос в систему, в виде XMLки.
Программа будет сохранять пришедшее сообщение XML, с его служебной информацией, в таблицу. При отправке ответа его тоже нужно будет сохранить в эту таблицу.
Прямую работу с XML не предполагаю . Т.е. не понадобится делать полнотекстовый поиск. Для этого и будут созданы служебные поля (типа даты, имя отправителя).
Может быть сделаю какие-то процедуры, которые бы прямо на сервере извлекали какую-то информацию из XMLок, чтобы не гонять большой объем данных по сети на клиента. Но это уже предположения.

Думаю, что пригодятся и другие служебные таблицы, например для отображения того какое сообщение было ответом на какое.
Но этот вопрос не критичен, я его сам решу. Меня интересует как правильно подойти к проектированию таблицы с XMLками.

Поиск по таблице будет по ID сообщения, может быть дате. После чего программе нужно будет извлечь XML'ку и обработать ее.
Т.е. к XML'ке обращение должно идти в последнюю очередь.

Мне на ум приходит идея, что может оказаться выгодным хранить XMLки в отдельной таблице. Чтобы быстро фильтровать таблицу по служебной информации (ID, Дата, Имя отправителя и т.д.), и в последнюю очередь доставать уже саму XML.


Не знаю, что еще мне добавить. Я не понял вопроса про требования к системе :)
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066119
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ProBiotek,

Лучше не хранить файлы в БД.
Тем более, если вы не сможете гарантировать, что они не будут очень большие.
Но это общий принцип.

А так, в MS SQL есть специальный тип который позволяет хранить в поле файл.
Туда XML складывайте.
Лучше конечно для этого выделить отдельную/ные таблицу/цы (для запросов и ответов)
И по необходимости вытаскивать только нужный файл, а не тягать туда сюда BLOB'ы.

Еще правильнее, построить по запросам и ответам РМД и уже раскладывать XML по таблицам.
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066233
dma_caviar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulЛучше не хранить файлы в БД.
Тем более, если вы не сможете гарантировать, что они не будут очень большие.
Но это общий принцип.

Это с какого перепугу?
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066254
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulЛучше не хранить файлы в БД
Это не файлы. Это обращения к системе.

mad_nazgulЕще правильнее, построить по запросам и ответам РМД и уже раскладывать XML по таблицам.
Крайне сомневаюсь. Пришедший запрос может быть неверно сформирован, предназначен для другой версии софта, с побитой кодировкой или просто повреждён при передаче. Как правило, его нужно сохранить - хотя бы для ручного разбора ситуации. И в этот момент разработчик, привыкший полагаться на "всё отработает правильно, а об обработке ошибок я не думаю, не хочу думать и думать не буду" оказывается в очень глупом положении.
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066269
kva6513
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer, mad_nazgul

IMHO: совать или нет такую дрянь, как "большой XML" в БД, наверное сильно зависит от того, зачем его надо сохранить. Если только для ручного разбора ситуаций, когда полученные данные не удалось обработать штатно - может он в БД и нафиг не нужен ? Пусть лежит где-нить на NFS в лог-файлах, а БД ведет псевдо-индекс, как эти логи нарезались по времени. Особенно в ситуации, когда ожидаемое количество ошибок не велико.

PS: Естественно, случай с XML DB, когда формат XML делается основным не только для хранения но и для любой обработки входящих данных - это совсем другой случай, сколько бы там не ожидалось ошибок.
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066293
ProBiotek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kva6513,

XML планирую сохранять просто на всякий случай :)
Вы подали мне интересную идею !

После того как ответ пришел и был распарсен, RAW вариант более не нужен !
А что если архивировать пришедшую XML (например в zip) и хранить уже этот архив в БД ? Насколько я понимаю тестовая строка сожмется чуть ли не в десятки раз.

Мне нравится такой вариант.
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066298
dma_caviar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ProBiotekkva6513,

XML планирую сохранять просто на всякий случай :)
Вы подали мне интересную идею !

После того как ответ пришел и был распарсен, RAW вариант более не нужен !
А что если архивировать пришедшую XML (например в zip) и хранить уже этот архив в БД ? Насколько я понимаю тестовая строка сожмется чуть ли не в десятки раз.

Мне нравится такой вариант.
А вам в бекапах нужны все эти файлы?
Если нужны, то храните в базе, в FILESTREAM. Физически это обычные файлы на диске, но к ним можно делать запросы, как если бы файлы лежали в обычной таблице.
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066314
ProBiotek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dma_caviarА вам в бекапах нужны все эти файлы?
Если нужны, то храните в базе, в FILESTREAM. Физически это обычные файлы на диске, но к ним можно делать запросы, как если бы файлы лежали в обычной таблице.

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

Пожалуй сделаю через FILESTREAM.
Сжатие в архив должно существенно увеличить плотность записи.
К тому времени когда встанет вопрос слишком большого объема, можно будет подумать о секционированиях, архивирования. Пока сойдет и так.

Остается вопрос по индексам.
Опять же, я больше по C#. Поэтому задам, может быть наивный, вопрос. Какие индексы ?

Предположим структура таблицы будет такая:
id xml date SenderID еще_какое__важное_поле.

Какие индексы стоит сделать ?
Кластерный Первичный на ID ? А дальше что ? Стоит ли добавить столбец XML в Include ?

Могу представить ситуацию, когда появится желание получить "все запросы на дату для такого-то SenderId" и подобные.
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066321
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kva6513 IMHO: совать или нет такую дрянь, как "большой XML" в БД, наверное сильно зависит от того, зачем его надо сохранить. Если только для ручного разбора ситуаций, когда полученные данные не удалось обработать штатно - может он в БД и нафиг не нужен ?
Насколько я понял автора, в этом случае большого XML-я не будет - поскольку запрос маленький, а в ответе вместо мегабайт данных только сообщение об ошибке. Большие XML-и будут, если запрос обработан штатно - и тут уже вопрос к бизнес-логике, зачем хранить ответ и сколько времени. В моём случае, например, за эти ответы контора несла юридическую ответственность - поэтому они хранились, да ещё и подписанными-зашифрованными, дабы в любой момент времени ткнуть "мы вам послали вот это".

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

ProBiotekВы подали мне интересную идею !
После того как ответ пришел и был распарсен, RAW вариант более не нужен !
Насколько я понимаю, выгадаете Вы на этом несильно, а вот помочь они могут. Скажем, когда Вы обнаружите ошибку, из-за которой иногда неверно парсятся. Хранение первички в удобном для доступа виде резко облегчает жизнь, а терабайты нынче дёшевы. В конце концов, вынесите эти xml-ки на отдельный sata-шный диск и не парьтесь.
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066324
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ProBiotek[Опять же, я больше по C#. Поэтому задам, может быть наивный, вопрос. Какие индексы ?

Если Вы не очень разбираетесь в индексах - пользуйте майкрософтовский tuning advisor, он вам всяко насоветует не хуже, чем мы тут не зная Ваших запросов, данных, статистики и т.п.
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066354
kva6513
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerВ моём случае, например, за эти ответы контора несла юридическую ответственность
Это "немного" отличается от варианта "раз в месяц поискать ошибку". :)
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066598
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dma_caviarmad_nazgulЛучше не хранить файлы в БД.
Тем более, если вы не сможете гарантировать, что они не будут очень большие.
Но это общий принцип.

Это с какого перепугу?

С такого, прилетит тебе в ответ XML на пару гигов (реальный пример из моей практики). Потом таскай ее в запросах туда/сюда.
Так что в общем случае, как минимум XML-ответов должно быть в каком-нибудь файловом хранилище.

Для MS SQL в БД уже есть специальный тип для создания файловых хранилищ.
Они это используют в SharePoint.

Поэтому ТС настоятельно рекомендую почитать MSDN.
Думаю там есть примеры как правильно создавать файл-помойку на MS SQL :-)
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066781
ProBiotek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ну хз. может быть имеет смысл, подумаю еще.
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066803
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulС такого, прилетит тебе в ответ XML на пару гигов (реальный пример из моей практики). Потом таскай ее в запросах туда/сюда.

Извините, не совсем понял что такое "таскай ее в запросах туда сюда"?
Зачем выбирать само текстовое поле, если оно не нужно в результатах запроса?
Не уверен, как построена логика хранения блоба в МСе, но на Сайбезе в основной записи лежит только 16 байт (по моему 16) ссылки на начало блоба => пока вы явно не обратились к текстовому полю (ну или конструкция select * from) - сервер не будет "поднимать" текстовое поле и никуда "таскать" его.

На МСе все иначе?
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066856
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mikle83mad_nazgulС такого, прилетит тебе в ответ XML на пару гигов (реальный пример из моей практики). Потом таскай ее в запросах туда/сюда.

Извините, не совсем понял что такое "таскай ее в запросах туда сюда"?
Зачем выбирать само текстовое поле, если оно не нужно в результатах запроса?
Не уверен, как построена логика хранения блоба в МСе, но на Сайбезе в основной записи лежит только 16 байт (по моему 16) ссылки на начало блоба => пока вы явно не обратились к текстовому полю (ну или конструкция select * from) - сервер не будет "поднимать" текстовое поле и никуда "таскать" его.

На МСе все иначе?

Я не о субд, а ORM.
Обычно в ORM пытается вытащить в объект все, если не указано обратного.
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066861
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulЯ не о субд, а ORM. Обычно в ORM пытается вытащить в объект все, если не указано обратного.
Подлаживать структуру базы под кривизну ORM - это порочный путь, пример того, что я называю "эскалация кривизны". Вместо того, чтобы исправить существующую кривизну (нормально настроить этот ORM, выкинуть этот ORM и взять нормальный либо обойтись без кривых ORMов) делается другая кривизна, с целью дать работать с первой. Потом будет третья - чтобы работали первые две. А потом удивляемся, что архитектура из сплошных костылей, и если что-то тронуть - всё сыпется.
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066892
dma_caviar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazguldma_caviarпропущено...

Это с какого перепугу?

С такого, прилетит тебе в ответ XML на пару гигов (реальный пример из моей практики). Потом таскай ее в запросах туда/сюда.
Так что в общем случае, как минимум XML-ответов должно быть в каком-нибудь файловом хранилище.

Для MS SQL в БД уже есть специальный тип для создания файловых хранилищ.
Они это используют в SharePoint.

Поэтому ТС настоятельно рекомендую почитать MSDN.
Думаю там есть примеры как правильно создавать файл-помойку на MS SQL :-)
Сначала вы говорите "Лучше не хранить файлы в БД", теперь "Для MS SQL в БД уже есть специальный тип для создания файловых хранилищ".
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066984
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dma_caviarСначала вы говорите "Лучше не хранить файлы в БД", теперь "Для MS SQL в БД уже есть специальный тип для создания файловых хранилищ".

Помимо MS есть другие БД, в которых нет специальных "способов" хранения файлов в БД.
Если не боятся vendor lock, то у MS свой способ хранения, у Oracle свой.
Поэтому в общем случае - не надо, т.к. это может сказаться на производительности.
Но в данном конкретном случае есть решение, которое позволяет это сделать, без проседания по производительности.
Минус мне видится один, что решение специфично только для MS SQL.
Ничего плохого, просто возможно некоторое не удобство если вдруг вместо MS SQL захотят Oracle.
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39066992
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerПодлаживать структуру базы под кривизну ORM - это порочный путь, пример того, что я называю "эскалация кривизны". Вместо того, чтобы исправить существующую кривизну (нормально настроить этот ORM, выкинуть этот ORM и взять нормальный либо обойтись без кривых ORMов) делается другая кривизна, с целью дать работать с первой. Потом будет третья - чтобы работали первые две. А потом удивляемся, что архитектура из сплошных костылей, и если что-то тронуть - всё сыпется.

Я вообще-то сам против "универсальных" ORM.
Но увы для C# ORM вшит "by disign".
Поэтому это надо "иметь в виду".
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39067010
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulsoftwarerПодлаживать структуру базы под кривизну ORM - это порочный путь, пример того, что я называю "эскалация кривизны". Вместо того, чтобы исправить существующую кривизну (нормально настроить этот ORM, выкинуть этот ORM и взять нормальный либо обойтись без кривых ORMов) делается другая кривизна, с целью дать работать с первой. Потом будет третья - чтобы работали первые две. А потом удивляемся, что архитектура из сплошных костылей, и если что-то тронуть - всё сыпется.
Я вообще-то сам против "универсальных" ORM.
Но увы для C# ORM вшит "by disign".
Если он кривой и небходимый (в смысле "не обойти") - это повод выкинуть C#. А не распространять кривизну на остальные части системы.
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39067011
dma_caviar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulНо увы для C# ORM вшит "by disign"
А можно по подробнее?
...
Рейтинг: 0 / 0
Большое строковое поле (XML). Как лучше ?
    #39067051
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulsoftwarerПодлаживать структуру базы под кривизну ORM - это порочный путь, пример того, что я называю "эскалация кривизны". Вместо того, чтобы исправить существующую кривизну (нормально настроить этот ORM, выкинуть этот ORM и взять нормальный либо обойтись без кривых ORMов) делается другая кривизна, с целью дать работать с первой. Потом будет третья - чтобы работали первые две. А потом удивляемся, что архитектура из сплошных костылей, и если что-то тронуть - всё сыпется.

Я вообще-то сам против "универсальных" ORM.
Но увы для C# ORM вшит "by disign".
Поэтому это надо "иметь в виду".
что за чушь?
...
Рейтинг: 0 / 0
24 сообщений из 24, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Большое строковое поле (XML). Как лучше ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]