我有一个这样的数据库模型：
tb_Computer (N - N) tb_Computer_Peripheral (N - 1) tb_Peripheral
每台计算机都有 N 个外围设备。但是每个外设的性质不同，会有不同的领域。键盘有型号、语言等，网卡有速度等规格。
但我认为创建与外围设备一样多的表是不可行的。因为有一天有人会想出一个非常特定的外围设备，我不希望他仅仅因为它不是键盘也不是网卡而无法添加它。
data在 tb_Peripheral 中创建一个包含有关特定外围设备的 JSON 数据的字段是一种不好的做法吗？
我什至可以创建一个tb_PeripheralType包含特定类型外围设备具有哪些数据的特定信息。
我在很多地方都读到过这个，到处都发现这是一种不好的做法，但我想不出任何其他方式来按照我想要的方式实现它，完全动态的。
实现我想要的最佳方式是什么？现在的模型错了吗？你会怎么办 ？
这不是“好做法”或“坏做法”的问题。使事物完全动态化有好处也有坏处。你已经很好地概述了上行空间。
完全动态设计的缺点是，将数据转化为有用信息的过程并不像在设计范围内确定数据语义的数据库那样例行公事。
当您开始添加有关一种新型外围设备的数据时，您能否构建一个报告和一个报告生成过程，使其适应新的数据结构？如果您最终在需求变化时坚持对应用程序进行维护，那么通过使数据库设计完全动态化，您获得了什么？
PS：如果对数据库设计的更改仅包括添加新表，则对现有应用程序的“涟漪效应”可以忽略不计。
我能想到四个选项。
首先是创建一个表外设，其中包含您可能想要的有关外设的所有信息。这将在字段不适合该类型的列中包含 NULL。添加新外围设备时，您必须添加描述性列。
第二种是为每个外围设备创建一个单独的表。
第三个是将信息编码为 JSON 之类的东西。
第四种是将数据成对存储。所以每个外围设备都会有许多不同的行。
这些方法也有混合体。例如，您可以将公共字段存储在单个表中（ala (1)），然后为其他值创建键值对。
问题是如何使用这些信息。我的大部分工作都是直接在 SQL 中完成的，所以对我来说最糟糕的选择是 (3)。我不想解析奇怪的信息格式来获得对 SQL 查询可能有用的东西。
选项 (4) 是最灵活的，但它也需要更多的工作才能全面了解所有可能的属性。
如果我从头开始，并且我非常清楚自己想要什么字段，那么我将从 (1) 开始，一个用于外围设备的表。如果我有外围设备和属性会定期更改的要求，那么我会认真考虑（4）。如果这些表仅由应用程序使用，那么我可能会考虑 (3)，但无论如何我可能会拒绝它。
当你做这种设计时，只有一个问题需要回答。JSON，一个序列化的对象，xml，或者天堂禁止 csv，并不重要。
你想在知道结构的 API 之外使用它们吗？
如果你想说使用 sql 来获取键盘类型的所有外围设备，其键数属性 >= 102 说。
If you do, it gets messy, much messier than extra tables. No different to say having a table of pdfs or docs and trying to find all the ones which have more than 10 pages.
Gets even funnier if you want to version the content as your application evolves.
Have a look at a Nosql back end, it's designed for stuff like this, a relational database is not.