我正在考虑一种方式，如果我有一个需要根据用户输入能够更改数据库模式的应用程序，该如何处理。
例如，如果我有一个“汽车”对象，其中包含汽车属性，如年份、型号、门数等，我该如何以这样的方式将其存储在数据库中，以便用户能够添加新属性？
我了解到EAV表似乎适合这种情况，但问题是当我尝试基于属性集过滤汽车列表时，查询会变得非常复杂。
我能否动态生成表格呢？我发现Sqlite支持ADD COLUMN，但当表格达到许多记录时，速度会变慢吗？而且貌似没有办法删除列。我必须创建一个不包含要删除的列的新表格，并从旧表格中复制数据。这对于大表格来说肯定很慢 :(
CREATE TABLE entities
(entity_id INTEGER PRIMARY KEY, name TEXT);
CREATE TABLE attributes
(attribute_id INTEGER PRIMARY KEY, name TEXT, type TEXT);
CREATE TABLE entity_attributes
(entity_id INTEGER, attribute_id INTEGER, value TEXT,
PRIMARY KEY(entity_id, attribute_id));
INSERT非常简单。您只需要插入一个新对象、一堆属性和它们之间的关系。例如，要插入具有 3 个属性的新实体，您需要执行 7 次插入（一个用于实体、三个用于属性，以及三个用于关系）。UPDATE 时，您需要知道要更新的实体是什么，并通过连接实体和其属性之间的关系来更新所需的属性。DELETE操作时，您还需要知道要删除的实体是什么，删除其属性，删除实体和其属性之间的关系，然后再删除实体。SELECT操作时，情况变得很棘手（您需要编写非常复杂的查询），而且性能会大大下降。SELECT将是：SELECT brand, model FROM cars;
SELECT将非常困难，并涉及三个表的连接。查询性能将非常差。TEXT，这可能会成为一个问题。如果有人将“red”存储为价格，会怎么样？正如您所说，这个模型在使用SQLite时还有另一个问题，因为没有直接的方法来删除列，您需要按照http://www.sqlite.org/faq.html#q11中所述进行操作。
BEGIN TRANSACTION;
CREATE TEMPORARY TABLE t1_backup(a,b);
INSERT INTO t1_backup SELECT a,b FROM t1;
DROP TABLE t1;
CREATE TABLE t1(a,b);
INSERT INTO t1 SELECT a,b FROM t1_backup;
DROP TABLE t1_backup;
COMMIT;
CREATE TABLE entities
(entity_id INTEGER PRIMARY KEY,
name TEXT,
type TEXT,
attribute1 TEXT,
attribute1 TEXT,
...
attributeN TEXT
);
根据评论进行跟进：
使用伪泛型模型后，您的实体表将具有许多列。从文档（https://www.sqlite.org/limits.html）中可以看出，SQLITE_MAX_COLUMN的默认设置为2000。我曾经使用过具有100多个列的SQLite表格，并且性能非常好，因此40个列对于SQLite来说不应该是一个大问题。
正如您所说，大多数记录的大部分列都将为空，您需要为所有列建立索引以提高性能，但是您可以使用部分索引（https://www.sqlite.org/partialindex.html）。这样，即使有大量行，您的索引也会很小，并且每个索引的选择性都很高。
如果您只使用两个表来实现EAV，那么表之间的连接数量将少于我的示例，但查询仍然很难编写和维护，并且您需要执行多个（外部）连接以提取数据，这会降低性能，即使您拥有一个很好的索引，当您存储大量数据时也是如此。例如，想象一下您想要获取汽车的品牌、型号和颜色。您的SELECT语句将如下所示：SELECT e.name, a1.value brand, a2.value model, a3.value color
FROM entities e
LEFT JOIN entity_attributes a1 ON (e.entity_id = a1.entity_id and a1.attribute_id = 'brand')
LEFT JOIN entity_attributes a2 ON (e.entity_id = a2.entity_id and a2.attribute_id = 'model')
LEFT JOIN entity_attributes a3 ON (e.entity_id = a3.entity_id and a3.attribute_id = 'color');
正如您所见，您需要为每个要查询（或过滤）的属性使用一个（左）外连接。对于伪通用模型，查询将如下所示：
SELECT name, attribute1 brand, attribute7 model, attribute35 color
FROM entities;
同时，考虑一下您的_entity_attributes_表的潜在大小。如果每个实体可能有40个属性，假设其中20个不能为空。如果您有10,000个实体，那么您的_entity_attributes_表将有200,000行，并且您将使用一个巨大的索引来查询它。使用伪通用模型，您将拥有10,000行和每列一个小索引。
我建议使用EAV。
根据用户输入添加列听起来不太好，而且很快就会用尽容量。对非常扁平的表进行查询也可能会有问题。您想创建数百个索引吗？
与其将所有内容都写入一个表中，我会在主表中存储尽可能多的公共属性（价格、名称、颜色等），并将那些不太常见的属性存储在“额外”属性表中。稍加努力即可随时平衡它们。
EAV可以在小到中等大小的数据集上表现良好。既然您想使用SQLlite，我猜这不会是个问题。
您可能还希望避免过度规范化数据。由于我们当前拥有廉价的存储空间，您可以使用一个表来存储所有“额外”属性，而不是两个：
ent_id，ent_name，... ent_id，attr_name，attr_type，attr_value ...
反对EAV的人会说它在大型数据库上的性能很差。当然，它的性能肯定不如规范化结构，但您也不想在3TB的表上更改结构。
我有一个质量较低的答案，但可能是来自类似于以下HTML标记的标记：<tag width="10px" height="10px" ... />
以这种肮脏的方式，您将只有一个列作为varchar(max)用于所有属性，称之为Props列，并且您将像这样存储数据：
Props
------------------------------------------------------------
Model:Model of car1|Year:2010|# of doors:4
Model:Model of car2|NewProp1:NewValue1|NewProp2:NewValue2
通过使用一些函数，如concatCustom获取一个数组并返回一个字符串，以及unconcatCustom获取一个字符串并返回一个数组，所有工作都将转到业务层的编程代码。
为了更有效地处理特殊字符，如':'和'|'，我建议使用'@:@'和'@|@'或者更稀有的分隔符。