我正在处理许多需要存储在数据库中的类似Event类。
它们都继承自AbstractEvent并实现接口IEvent。主要区别在于它们的属性：
RainStartsEvent
TimeRainStarted: Time
LitresOfRainPerSquareMeter: Float
RainTemperature: Integer
SunUpEvent
TimeSunUp: Time
PersonWhoSawItFirst: Integer
Brightness: Float
SongOfTheDay: String
SomeOtherEvent
UniquePropery1: someType
StandardProperty: someType
等等。将会有数十个甚至数百个Events，除了从AbstactEvent继承并从IEvent实施的内容之外，它们可能没有任何共同之处。
现在我需要将这些对象存储在数据库中。我考虑过单表继承或表层次结构 - 继承，但它没有意义，因为Events的数量越来越大。我最终会得到一个超过255个字段的表。
我的另一个想法是将所有Events存储在一个表中，将所有属性存储在另一个表中，每行一个属性，并带有Events表的外键。但是，这意味着我必须将它们全部存储为字符串并进行大量（反）序列化，即在具有大量Events的系统中这可能表现不佳。
我是否需要使用.NET对象序列化来提高性能？那会有帮助吗？
还有什么可能吗？对于这个问题，某种最佳实践或设计模式必须有更标准的解决方案。有什么想法吗？
更新：数据需要连续读取，并且很少更新。记录将在DB中完整读取，没有排序，where子句，条件语句或索引
答案 0 :(得分：0)
看起来您只想存储数据。如果您关心这些数据的索引，查询等，那么您没有说过这个问题？
你可以将它们转换为JSON，并将它们作为MS SQL Server中的字符串（或者大多数RDBMS）进行转换，但是如果你有一个luxyry或者拥有PostreSQL的运气，那么它对JSON data types有本机支持还有一些querying mechanism。
另一个解决方案 - 如果解决方案更多是关于数据而不使用关系模型是可以接受的 - 那就是使用像MongoDb或RavenDB这样的文档数据库，这样你就不会关心（或限制）受限于关系数据库，大部分都是 - 强加给你。
答案 1 :(得分：0)
听起来你需要的不是传统的RDBMS，因为你没有对set和get之外的数据做任何事情。所以你应该研究各种NoSQL选项。
但是，（只是说明了），如果您打算使用SQL Server：
如果您使用非结构化路由，则使用XML字段而不是包含JSON数据的NVARCHAR。解析JSON没有固有的支持。
如果您使用结构化路线，请在DBA.StackExchage上查看我对这个确切主题的答案：