我的任务是决定我们的技术堆栈是否足以完成我们手头的项目，或者我们是否应该更改它（以及确切地改变哪些技术）。
问题是我只是一个SQL Server DBA，我有几天时间想出一个解决方案......
他们希望网络应用程序能够用他们的术语将分离成主题或项目的药物研究集中起来。这些研究作为csv文件发送，它们的结构如下：
他们不想在这一点上扼杀数字。 98％的文件有几千行，但有2％有几百万行（大约200个字段）。
后端是SQL 2008R2。我为每个细分市场设计了EAV（在任何事情之前请记住，这不是我们的第一个EAV设计。它在使用较少数据之前运行良好。）和中间层/前端是PHP 5.3和Laravel 4框架引导。 我们遇到的问题是PHP窒息了大文件。当行数超过10万时，它无法及时插入SQL，因为涉及到大量的数据透视，最重要的是，PHP需要首先返回所有字段ID才能开始插入。我将解释：这是必要的，因为客户端想要对字段名称进行某种控制。我们为所有可能的字段创建了一个存储库，以尝试并最大限度地减少模糊问题;例如，名为“血压”，“血压”，“血压”或“血压”的字段都应存储在数据库中的相同名称下。因此，为了最小化问题，用户必须首先将他的csv字段插入到另一个表中，我们将其称为属性表。这个动作不会完全解决问题，但是当他插入字段时，他看到已插入的可能匹配。当用户输入血液时，会有一个面板显示已经使用单词blood的所有字段。如果用户认为它是相同的，他必须将csv标题更改为字段。无论如何，这一切都是为了解释这不是一个简单的EAV结构，并且有很多来回的ID。
这个问题让我们对我们的技术堆栈选择有了第二个想法，但是我们对可能的选择有限制：到目前为止我只使用过关系数据库，实际上只有SQL Server而其他人只知道PHP。我想MS完整堆栈是不可能的。 在我看来，非SQL方法将是最好的。我读了很多关于MongoDB的内容，但老实说，我认为这对我们来说是一个超级陡峭的学习曲线，如果他们想要开始处理这些数字甚至是有一些报告功能，
我猜Mongo不会那么做。我正在阅读有关PostgreSQL的关系，它是着名的HStore类型。所以这就是我的问题开始的地方：
- 你们会认为Postgres比这个项目更适合SQL Server吗？
- 我们是否能够将csv文件转换为JSON对象或任何要存储到HStore字段中的内容并且有点可查询？
- Postgres坐在窗户盒子里有什么问题吗？我不认为我们的客户有Linux管理员。我们也没有那件事......
- 商业应用是免费的吗？
- 或者我们应该坚持使用我们拥有的东西并尝试使用临时表或批量插入或依赖后端进行繁重工作的其他技术来解决问题？
很抱歉很长的帖子，感谢您的输入人员，我感谢所有的答案，因为我在这里拔头发:)）