Расширение бизнес-модели и сохранение ее в базе данных. - PullRequest
Новая
       0

Расширение бизнес-модели и сохранение ее в базе данных.

0 голосов
/ 28 июня 2010

У меня (довольно общий) вопрос о C # 4.0, MS SQL и бизнес-объектах, сгенерированных с помощью модели данных сущностей ADO.NET.

Допустим, я получил таблицу MS SQL Foo со строками:

  • ID уникальный идентификатор
  • НАЗВАНИЕ nvarchar (20)
  • ОПИСАНИЕ текст
  • ADDITIONALDATA image

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

Но теперь вопрос - где я могу указать эти дополнительные свойства?Внутри файла конфигурации (т.е. web.config)?Или есть какой-то другой / стандартный способ добиться этого?

Ответы [ 2 ]

1 голос
/ 28 июня 2010

Итак, пара вещей, на которые стоит обратить внимание, прежде всего, если вы планируете сериализовать некоторые Данные и поместить их в столбец (ADDITIONALDATA), столбец не должен иметь тип изображения. Если вы используете тип XML, вы сможете хранить данные и сможете запрашивать их, хотя запрашивать их будет немного сложно.

Как отметил Том Х., у вашего дизайна есть некоторые недостатки. Вы обнаружите, что большую часть времени вы увидите 3 таблицы, используемые для достижения ваших целей.

  1. Стол для хранения Foo.
  2. Таблица для хранения типов атрибутов Foo. Foo_Att_ID, Foo_Att_Name
  3. Таблица для хранения значений для дополнительного типа атрибута Foo. Foo_ID, Foo_Att_ID, Value
1 голос
/ 28 июня 2010

Можете ли вы предоставить более подробную информацию о том, что именно вы пытаетесь хранить здесь? Если у вас есть какой-либо сериализованный объект в «ADDITIONALDATA», то практически невозможно будет использовать любой другой инструмент для доступа к вашим данным, например, инструмент отчетности.

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

EDIT:

Вы можете использовать модель Entity-Attribute-Value, хотя при таком подходе есть много потенциальных подводных камней. Другая возможность - хранить данные в виде XML в столбце. Опять же, это не без проблем. Хотя вы можете, по крайней мере, искать в XML с использованием функций XML в SQL, производительность будет невелика. Проблема в том, что вы пытаетесь найти общее решение для проблемы, которая не до конца проработана. Любой подход, который вы выберете, будет иметь проблемы из-за этого. Если бы мне пришлось выбирать, я бы, вероятно, выбрал модель EAV, настолько, насколько я ее ненавижу, с секундой XML.

...