Проектирование общего неструктурированного хранилища данных - PullRequest
0 голосов
/ 17 декабря 2010

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

Некоторые из этих элементов могут быть связаны, например, у многих пользователей есть изображение.Мне не нужно проверять содержимое данных, так как мое решение для хранения получит данные в виде XML и отправит их в виде XML.Получатель может преобразовать XML обратно в файл изображения или звуковой файл и т. Д. Получатель может запросить всех пользователей, поэтому мне нужно иметь возможность найти записи пользователя и связанные с ними «дочерние» элементы, такие как рисунки и т. Д., Или получатель можетпросто хочу картинки и т. д.

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

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


Для тех, кто дал свои комментарии:

Проблема, которую ялицо - это соединение объектов.Пользовательский объект может быть добавлен в хранилище данных, после чего может быть добавлена ​​картинка пользователя.При запросе пользователя мне нужно будет вернуть как объект User, так и связанный с ним рисунок.Пользователь может обновить свою картинку, чтобы вы могли видеть, что мне нужно сохранять отношения между объектами.Это то, что я пытался донести до второго абзаца.У меня проблема в том, что мое решение должно быть очень общим, так как я должен иметь возможность хранить что угодно и связывать эти объекты в соответствии с требованиями конечных пользователей.Например: пользователь, изображения и электронные письма или рабочие элементы, список деталей и т. Д. Я вижу, что Microsoft разработала ZEntity, который выглядит как полезный, но мне не нужно углубляться в содержимое данных, так что, вероятно, это больше, чем нужно..

Ответы [ 5 ]

1 голос
/ 30 декабря 2010

Я использую Microsoft Zentity начиная с версии 1, и, несмотря на то, что он отлично хранит огромные объемы структурированных данных и обеспечивает (относительно) простой доступ к данным, если ваша структура данных может измениться затем воссоздание «модели данных» (и регрессионное тестирование), вероятно, устранит преимущества использования такой системы.

Еще один момент, на который стоит обратить внимание, заключается в том, что Zentity требуется хранилище файлового потока, поэтому вам необходимо установить правильную версию SQL Server (думаю, 2008) и включить хранилище файлового потока.

1 голос
/ 17 декабря 2010

Поскольку вы имеете дело с XML, это не неструктурированные данные.Microsoft SQL Server 2005 или более поздняя версия имеет тип столбца XML, который вы можете использовать.

Теперь, если вам не нужен доступ к узлам XML, и вы думаете, что вам это никогда не понадобится, используйте простой varbinary(max).Для вашей информации, хранение содержимого XML в столбце типа XML позволяет вам не только извлекать узлы XML непосредственно через запросы к базе данных, но также проверять данные XML по схемам, что может быть полезно для обеспечения того, что содержимое выХранилище действительно.

Не забудьте использовать FILESTREAM s (SQL Server 2008 или более поздняя версия), если ваши данные XML увеличиваются в размере (2 МБ +).Вероятно, это ваш случай, поскольку голосовая почта или изображения могут легко превышать 2 МБ, особенно если они закодированы в Base64 внутри файла XML.

1 голос
/ 17 декабря 2010

Поскольку ваши данные достаточно произвольны и изменяемы, лучше всего поместить их в старую файловую систему, а не в реляционную базу данных. Во что бы то ни стало храните некоторую мета-информацию в SQL, где имеет смысл искать структурированные отношения данных, но если ваш основной контент данных не структурирован отношениями данных, то вы оказываете себе медвежью услугу, используя базу данных SQL.

Файловая система невероятно быстр для поиска файлов и их потоковой передачи, особенно если это приложение для внутренней сети. Все, что вам нужно сделать, это предоставить общий доступ к папке и применить разумные права доступа к файлам, и большая часть ненужных разработок исчезнет. Если вам нужно доставить это через Интернет, рассмотрите возможность использования WebDAV с IIS.

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

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

0 голосов
/ 21 декабря 2010

Значит, я прав, если скажу, что все, что вам нужно хранить, это блоб xml с какой-либо двоичной информацией, содержащейся внутри? Почему у вас не может быть таблицы пользователей, а затем связанной таблицы (внешнего ключа) с объектами пользователя, связанными с помощью userId?

0 голосов
/ 17 декабря 2010

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

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

Может быть, я не понимаю проблему ясно.

...