Каков наилучший способ сохранить динамический объект «информация», C # /. Net MVC / SQL Server 2008?

Question

Это может звучать как несбыточная мечта, мне интересно, возможно ли это.Я хочу иметь возможность взять динамический объект C #, называемый info, и сохранить его в базе данных (сейчас я нахожусь в базе данных SQL Server 2008).

Объект info, будучи динамическим, может иметь любойколичество свойств: Id, Title, Content, DateExpires, DateAdded, Dateupdated, TypeOf и т. д. *

Каждый его экземпляр может / будет содержать различное количество свойств, в зависимости от того, для чего используется экземпляр: запись в блоге, объявление, событие и т. д...Однако, будет базовый набор свойств, которыми будет обладать каждый информационный объект: Id, MemberId, TypeOf ...

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

Например, сообщения в блоге.Они будут иметь: Id, MemberId, DateAdded, Title, Content, TypeOf, и т. Д. ... Событие будет иметь: Id, MemberId, Title, Content, TypeOf, DateOf, Recurrance, MinAge, MaxAge, и т. Д. *

Я бы хотел строить запросы на основе любого данного свойства информационного объекта.

Зачем?Гибкость.Если я могу заставить это работать, я могу использовать информационный объект для будущих случаев в моем веб-приложении.Если это очень плохая идея, пожалуйста, дайте мне знать (и почему), пожалуйста.Спасибо!

Answer 1

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

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

Когда вы идете по пути создания этой «общей базы данных», вы жертвуете другими известными технологиями, которые мы считаем само собой разумеющимся.Например, оптимизация баз данных в реляционных базах данных хорошо известна, и есть много инструментов, которые работают с ними практически без особых усилий.Если вы вдруг выберете другой путь, инструменты, к которым вы привыкли, могут не сработать, и в итоге вы либо создадите свой собственный, чтобы компенсировать вещи, которые не работают (либо купите / выберете некоторые эзотерические инструменты).

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

Answer 2

вы можете использовать «базовую» таблицу для общих свойств и таблицу «имя-значение» для других свойств. значение:

Table Info
  int Id (PK) (FK),
  int MemberId,
  Date DateAdded //etc...

Table Properties
  int InfoId (PK),
  varchar PropertyName (PK),
  varchar PropertyValue,
  string PropertyType //optionaly store information about the type of property

после запроса вы можете использовать отражение для перевода свойств из пар (имя, значение) в правильные свойства.

Тем не менее, я думаю, что - очень плохая идея по нескольким причинам:
1. это создает дополнительную сложность в вашей логике CRUD
2. у вас нет четко определенных сущностей в вашей доменной модели, что мне не нравится
3. проверка намного сложнее - вам нужно вручную проверить, что, например, Post не имеет свойства, называемого Recurrance field.

Я бы использовал этот метод, только если вам действительно нужна эта гибкость, например: если пользователь может выбрать сохранение пользовательских свойств, которые вы не знаете заранее.
в противном случае, если вы знаете, что ваши сущности ограничены Post, Event, Employee и т. д., я бы ограничился этим.