我正在开发我的第一个应用程序，作为一个学习项目，做任何事情：
- 客户端前端（角度）
- 后端（OWIN自主机，ASP.NET Web Api 2）
- 数据库和主机（Azure部署）
到目前为止，这是一个学习过程，我已经在我的应用程序中使用令牌完成了登录/注册授权，但正在使用Identity框架和Azure SQL DB（存储在为我创建的dbo.AspNetUsers表下）存储我的用户凭据。
为了配合我的用户表，我希望有一个表来实际存储与我的用户相关联的元数据，在我的应用程序中：
信用卡信息
PDF文件（BLOB格式，但每个帐户关联多个文件）这些BLOB文件是在上传PDF和后来当他们下载它们时又变成了PDF。
我在Azure门户上看到有一个文档NoSQL数据库以及BLOB存储。我想知道我是否可以将信用卡信息添加到我现有的AspNetUsers表中，这可以简化我只需将PDF数据存储在单独的表中的操作。
我也不确定表格的结构，因为一个用户可以有很多PDF文件。我的业余知识认为，也许有一个键值数据库可以更好地采用以下格式：
Key-UserName Value- JSON object of BLOB's with Id's.
我觉得，对于检索表示PDF的BLOB的PDF表，如果我能将ID与每个条目关联起来，并配置一个JSON对象，我可以添加任意多的字段进行查询，但我不确定，那么检索所有这些表并不是最好的。
显然，这还为时过早，我只是在寻找资源和经验，而不是直接的答案。
我想知道是否可以将信用卡信息添加到我的已经存在的AspNetUsers表，只能简化我必须通过以下方式将PDF数据存储在单独的表中它本身
我不确定是否可以在这个表中添加一列，但实际上，我不会将用户的信用卡信息存储在应用程序数据库中。如果可能的话，我会使用第三方支付处理器，并将我的解决方案与之集成，而不是自己存储信用卡信息（我知道有点跑题：））。
现在来谈谈你关于存储PDF的另一个问题，我建议你使用Azure Blob存储而不是DocumentDB。我在这里概述了一些原因：使用ASP.NET和Azure创建一个云存储应用程序。我能想到的其他原因是：
- 虽然确实可以使用DocumentDB将文件存储为附件，但附件的大小是有限制的（我上次检查的是2MB）。对于blob存储，此限制为200GB
- 您不能直接从DocumentDB流式传输附件内容。您首先需要在应用程序中获取内容，然后流式传输内容。但是，使用blob存储，您可以直接流式传输这些内容
就解决方案而言，您可以采取两种方法：
-
创建一个
Attachments表。事实上，它是一个简单的表，具有复合主键-用户Id+Blob Url。每当用户上传blob存储中的文件时，就会得到一个blob URL。然后，您可以将其与其他一些信息（如文件名、上传日期等）一起存储在该表中。如果你想查询数据，这种方法会很好地工作，例如按时间倒序排列文件 - 创建一个容器/用户。在这种情况下，用户上传的所有文件都放在一个容器中。有关更多详细信息，请参阅上面的链接。在这种情况下，当您想要显示用户上传的文件时，只需列出分配给该用户的容器中的Blob。但是，请记住，如果用户上传的文件少于5000个，这种方法会很好地工作，因为一个容器中列出Blob的调用最多只能返回5000条记录。另外请注意，blob存储是一个简单的对象存储，不具有查询功能
对于信用卡信息，在Azure SQL中，用户ID和CC号之间的简单映射表就足够了，并且可以处理用户和信用卡之间的一对多关系（您没有指定，所以也许现在这不是问题…也许以后？）。
关于PDF。。。从成本或性能的角度来看，DocumentDB不是您理想的解决方案。它不太适合像PDF这样的二进制数据的存储和检索。在您的场景中，我强烈考虑使用Blob存储来保存PDF内容本身，并通过SQL Azure中的映射表将PDF映射到用户，该映射表将用户ID与Blob URI相关联。如果需要为PDF存储和查询额外的元数据，可以在SQL映射表中使用额外的列。在创建或删除Blob时，同步到Blob的映射会有一些负担，但这是云中相当常见的数据场景。
祝你好运！