将大量（10000多种）DIFFERENT对象类型存储到数据库中的最佳做法是什么？
在设计新的关系数据库时，通常每个对象类型都由相应的表格表示。设计一个数据库的最佳实践是，哪个数据库存储大量的DIFFERENT对象类型，以避免创建和维护数千个数据库表？对于这种情况，关系数据库有哪些更好的替代方案？将大量（10000多种）DIFFERENT对象类型存储到数据库中的最佳做法是什么？
使用NoSQL数据库（Lucene的，蒙戈，卡桑德拉，Solr的，弹性的搜索，Hadoop的，等），存储文件，可以有任意数量的字段（想想键/值映射）。在关系数据库方面，就像每个“行”可以有不同的行定义。过去我已经实现了这一点，并且我发现它很方便地存储一个class字段，所以我可以重建正确类型的对象（在我的情况下是Java，但适用于任何语言）。
您也可以使用支持JSON列类型的关系数据库（例如Postgres），并将您的对象序列化/反序列化到/来自JSON并将它们存储在JSON类型的列中。为了创建一个方便的单表解决方案，您可能需要一个存储对象类型的列来简化反序列化。我也实现了这个选项，它对我很有帮助。
两种选择都很好。第一个是更好的技术。如果您已经熟悉RDBMS，则第二个可能不那么神秘。
你做什么不想要做的就是使用任何对象关系数据库解决方案，其中每个对象类型都有匹配类字段列的专用表。如果你改变了班级的定义，并且如果不同班级的数量增长超过一个非常小的数字，这完全是不确定的。
答案很大程度上取决于数以千计的对象类型之间的区别的本质，以及它们可以被分类和进一步推广到什么程度和以何种方式。在这种情况下，发现是可维护设计的关键。
以下是一些可能适用于您的对象类型集的潜在持久性选项。需要考虑每个人的利弊。
- 查询一个隐藏的结构或模式中的对象类型允许它们被分解1,2,3。
- 发现可以应用（1）的对象类型的类别。
- 将多个对象映射到单个或更少的一组表或文档类型。
- 一对一映射对象并确定一个元方案来保持它们的价格合理。
无论数据库是否为关系数据库，结构如何，可用的搜索功能类型以及如何实现密钥都应该在上述发现之后作出的决定。这是最佳做法。
确定存储，维护和检索具有所需特性的数据结构无法在500页的书中充分回答，因此当然不是简短的答案。
了解这些潜在选择的利弊将是一个好的开始。您可以通过网页搜索这些持久性哲学的名称和“数据库”或“持久性”来查看相应的描述和供应商产品。
- 关系表
- 关联对象
- 片状非关系
- 映射（键和值）
- 映射（键和固定记录有效载荷）
- 文献（自由文本）
- 分层
- 图（连接顶点的边的网络）
- 多维（OLAP等）
你可能会发现你有成千上万的数据类型的原因是，它们所对应的文件类型，并在共同它们之间的唯一的一点是，他们都写在或人类语言甚至可能不是这样。也许它们是任意的语言环境，在这种情况下，国际化的文档存储系统是首先要检查的选项。
您可能会发现有10,000多种对象类型中的9,800个语义规则可以确认，在这种情况下，规则的表征和规范可能会导致更细粒度的存储方案4,5,6。将语义结构与结构化软件设计项目（比如组合或装饰模式）结合起来可能会大大减少对象类型的数量。
这样的重构很容易就值得花时间，并且可能让您的项目在很短的时间内加快速度。
发现附加结构后，您需要确定哪些规范化级别对您的存储，更新，检索和磁盘空间要求有意义。
关于规范化和反规范化的文献（遍布网络）将帮助您了解空间，写作速度和阅读速度之间的取舍7,8.9。如果每天存储大量数据，则ETL特性也将显着地应用到设计中。
供应商和产品的选择可能是您在开始低级别设计和实现以及测试框架构建之前在体系结构上所做的最后一件事情。 （这是如此多的数据类型的另一个挑战，你将如何充分测试10,000多个类？）
如果没有更多关于数千种对象类型的特性以及为什么会有这么多的特性，那么给出比这更狭义的建议将是不负责任的。
参考
[1] https://www.tutorialspoint.com/design_pattern/design_pattern_quick_guide.htm
[2] https://sourcemaking.com/design-patterns-and-tips
[3] https://sourcemaking.com/design_patterns/strategy
[4] https://www.cs.cmu.edu/~dunja/LinkKDD2004/Jure-Leskovec-LinkKDD-2004.pdf
[5] https://archive.org/details/Learning_Structure_and_Schemas_from_Documents
[7] http://databases.about.com/od/specificproducts/a/Should-I-Normalize-My-Database.htm
[9] https://fenix.tecnico.ulisboa.pt/downloadFile/3779571831168/SchemaTuning.ppt
“最佳实践” 是主观的，且通常作为一种呈现个人偏好的方式，以某种方式具有权威性。
所以，这是我的个人偏好...
你必须做分析工作。你的数据是否有关系？你能否说有实体和关系？如果是这样 - 创建一个关系模式。您可能不得不处理继承关系 - 这是传统关系模型不能很好地处理的问题，但有一些可能的solutions。
您讨论的对象是不是真正的关系？他们有不同的属性，还是主要由非结构化数据组成？这些关系主要是分层的吗？你真的在谈论时间序列数据或地理对象吗？在这种情况下，您可能会被许多NoSQL解决方案之一提供更好的服务。
数据是“读写”还是“只读”？您是否正在构建一个用于报告和分析的大数据存储库？如果是这样，您可能需要使用OLAP/BI数据库解决方案，而不是关系架构。
您是否有极高的可扩展性或性能要求？如果是这样，在哪里 - 读，写，分析？如果是这样，你可能需要考虑一个高度非规范化的数据模型。
敢肯定，当你说10000+对象类型，它超越了原始的类型，如整型，浮点等，甚至复杂的已知类型的图表等
不能使用关系型数据库作为存储例如简单的图形将需要设计自定义关系和表格。所以，唯一的选择就是使用键值 NoSQL数据库，其中任何对象类型将被序列化到文件，并存储在对象ID
不管数据库的类型，你可以考虑一个替代方案是存储你的数据是一个JSON字符串。这样存储的数据可以根据需要动态变化，并且可以自由更改。其缺点包括仅限于服务器端和客户端JSON处理程序，它们将完成查询，解析和其他相关数据的所有“繁重”工作。
像其他人一样说NoSQL数据库听起来像你正在寻找避免关系数据库的结构要求方面。
区分对象类型，对象要素，对象属性和对象实例。
没有系统应该有10,000+个对象类型。维护这样的源代码将是可怕的。相反，确定如何拥有10到100个对象类型，并使用特征和属性来模拟那些不同的事物。
即使您先从实体关系图或设计开始（从后端向前设计），您应该将数据类型数量限制为100，并提供规范化或非规范化的模式以表示属性，功能以及您的分解的物体。
你不妨看看software design patterns来获得一些想法。
对于关系数据库来说，表格代表对象类型是一种常见的误解，它实际上是一种来自网络数据模型的思想。在适当的关系数据库中，每个表代表一个事实类型，可以涉及不同角色中的任意数量的对象类型。 – reaanb
@reaanb，我同意一个1对1的表映射对象通常不好。网络数据模型只是其中一个原因。懒惰的对象设计和ER设计是另一回事。除了您提到的事实类型方法之外，在模式中寻求特定级别的规范化有多种原因（由实用的ETL和同步问题，查询速度和资源保护驱动）。对象设计最好由智能设计的服务或微服务接口驱动。对象关系映射框架意在弥合这两者。 –
如果有人引用资料来源并声称它是可信的或官方回答这个问题的话，我会倾向于将源代码视为不可信，因为具有10K +对象类型的系统是反模式。除了找到一种不需要维护这么多对象类型的方法之外，没有最佳实践。其中一些答案有一些建议可以实现。 – FauChristian