需要为场景设计数据库
我在设计我的应用程序数据库时遇到了一个问题。我在网上搜索了类似的结构，但找不到任何。那么问题来了：
我有一个用搜索页面和数据网格设计的页面。请看下面的屏幕截图：
我有一个名为contact的表，它与身份及其子类型有关系。
Identity 类型目前仅包含两个值，但将来可能会增加（停车、生活区），根据下拉列表中选择的项目，搜索字段会更改，网格视图也会更改（请参阅标题）。The first image shows that when identity type parking is selected then the user can filter the results by section, lane, row and the parking number.
如果我们更改身份类型，搜索字段将再次更改，行字段在两种身份类型中都相同。
用户应该能够在数据库中保存从网格中为联系人（在联系人表中）选择的详细信息。
我很困惑我应该如何设计一个数据库，该数据库将显示带有身份字段的网格，而这些身份可以保存到与联系人相关的数据库中。
这是我想出的东西
我仍然不清楚所选行将如何保存在数据库中。
对此的任何帮助将不胜感激。
我认为你需要稍微改变你的方法。首先，您应该设计包含业务数据的数据库，而不必担心如何保存诸如搜索对话框状态之类的内容。在这一点上包括这些只会混淆设计。
你给的图看起来不错。您应该只删除表“IdentityType”。这不是一张好表——它包含两种完全不同类型的东西。这始终是 SQL 数据库中出现问题的线索。而在 OO 中，我们可能有两个类ContactIdentity，BuildingIdentity它们继承自一个公共基类或接口，但在 SQL 中这不是正确的方法。
现在，您应该能够使每个搜索页面在 Javascript 中工作。尝试这样做，忘记您想要一个适用于不同列集的“一般情况”解决方案。您似乎还有两个问题：
- 如果您添加新身份，您希望能够通过更改某些数据而不是编写新代码来“在配置中”这样做。
- 您希望能够在同一数据库中保存用户的搜索，可能（但不一定）。
第一个是你如何设计你的应用程序的问题。您不应该期望界面会准确反映数据库结构。您可以拥有更多的数据库表，并且仍然具有相同的两种搜索方法。或者您可以有更多的搜索方法，仍然使用您当前拥有的相同表格。无论哪种方式，您都应该警惕尝试根据数据库表的结构自动生成搜索页面。而是选择您可能使用的“视图”，并找到一种表示其元数据的好方法。例如，这可以是可以过滤/排序的列列表。或者检索您想要在表中包含的所有项目的 SQL 查询的文本。
其次，您要保存搜索。有两种方法可以做到这一点 - 是否要保存搜索参数（以便可以在不同时间对可能更改的数据再次运行相同的过滤/排序，并显示最新结果？或者是否要保存结果以便用户可以准确地看到他们当时找到的条目集？
我倾向于认为第一个更有意义，因为这意味着他们没有看到可能过时的东西。如果是这种情况，我会尝试将所有过滤器等的详细信息存储在 JSON 对象之类的东西中。（你也可以使用 XML - 我倾向于认为 JSON 更容易使用。）在 JSON 中可能看起来像这样：
{
"query": "parking",
"filters": {
"section": "A",
"lane": [1, 2, 5, 6],
"row_number": {
"greater_than": 10
},
},
"selected": [1,2 3, 4]
}
现在，您可以将 JSON 文档保存在一个数据库中，该数据库不一定是，但可能与您保存停车数据的数据库相同。您可以同样将其存储在文档数据库之类的东西中。您希望在该数据库中拥有与应用程序和查询的使用相关的数据，例如保存搜索的用户、会话 ID、保存的时间戳等。在这种方法中，不必担心将搜索与进行搜索时存在的数据集准确地联系起来。
另一种方法是保存搜索时选择的行中的所有标识符。我认为这有点问题。如果数据库中的标识符发生变化，并且正确 ID 的其余详细信息不再正确的行怎么办？如果有人选择一个条目是因为它位于给定建筑物的给定楼层，而现在不再是什么？
无论如何，在这种情况下，如果您确定标识符仍然引用相同的数据，您可能只想保存一个 ID 列表。在 SQL 中执行此操作的方法可能是这样的：您创建一个表 saved_search，其中包含用户 ID、保存的时间等。然后创建两个“关联表”：
CREATE TABLE saved_search_parking
(
saved_search_id int,
parking_id int,
CONSTRAINT uc_saved_search_parking UNIQUE (saved_search_id, parking_id)
)
和一个类似的表saved_search_living_area。对于已保存搜索中的每个停车位，您在表中创建一行，将它们链接起来。一个保存的搜索包含多个停车位，一个停车位可以包含在多个保存的搜索中。这确实意味着您可以在保存的搜索中同时拥有停车场和生活区。但我认为，与替代设计相比，这是一个小缺点。在任何情况下，将保存的搜索加载到“停车”页面的代码应该只查看saved_search_parking表格，与“生活区”页面相同。