我们有大量的文本文件，我们想要自由文本/全文搜索，结合有关文本文件的关系结构化元数据。因此，搜索可以是“给我属于 X 组（或 X 的子组）、作者（Ari 和 Bari 和 Mari）、属于组织 Y 并包含文本“合成”的所有文件。后半部分一个是全文搜索，另一个已经作为关系数据存储在我们现有的数据库中。
在我们的数据库（相当复杂）中，存储了一种标识文件的方法，以及大量关于文件的各种元数据，分布在数十个表中，从简单的 1-1 关系到 1-多组 pr文件，甚至树结构关系（比如“这个文件是类型 X，类型 X 是类型 Y 的子组，等等）。而且这个元数据可能会随着时间的推移而改变，在整个应用程序中（这是巨大的）。
现在，我作为数据库管理员，认为这可以通过使用 SQL Server 搜索数据库中已有的结构化元数据来解决，将搜索限制为候选文件，然后将候选文件 id 传递给弹性搜索以获取完整-文本搜索。（在我们的代码中添加或提交文件时在弹性上重新索引文件是微不足道的）
然而，我们项目中的elastic-guys自然有不同的想法：从文件中提取所有元数据以及全文内容，进行elastic-search，并在elastic中专门运行搜索。
这使他们可以轻松地运行完整的 lucene 查询，并且从数据库中删除了负载，这很好。然而，这对我来说也带来了一个噩梦，以保持结构化元数据同步，并且由于数据的规模，不可能定期盲目地重新索引/同步所有内容。
我可以看到这两种选择的优点/顾虑。这种事情有最佳实践吗？