通过 SSMS(sql server management studio)使用 Azure 本地开发存储
我正在尝试编写代码来访问我的天蓝色本地开发存储。我首先为自己创建一个新存储:
dsInit /forceCreate
我现在可以在 SSMS 中看到 DevelopmentStorageDb20090919 以及一些预先创建的表,例如 dbo.TableContainer、dbo.TableRow 等。
- 现在,我可以通过 SSMS 将表添加到该数据库吗(例如 Employee)表)并开始通过代码访问它们?这是做事的正确方法吗?
例如:
var svc = CloudStorageAccount.DevelopmentStorageAccount
.CreateCloudTableClient().GetDataServiceContext();
//"Employees" is the name of the table
svc.AddObject("Employees", new Employees("John Doe"));
svc.SaveChangesWithRetries();
2 。另外,完成后,如何将表和数据移植到实际的云帐户中?通过在那里运行脚本?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我认为您将 Azure 表存储与 SQL Server 或 SQL Azure 混淆了,它们是完全不同的。您根本无法使用 SSMS 访问 Azure 存储表。您提供的代码示例使用 Azure SDK(它使用下面的存储 REST API)。这是访问 Azure 存储的唯一方法。
如果您想以更图形化的方式创建/查看表,请尝试 Cerebrata 的 Cloud Storage Studio、ClumsyLeaf 的 AzureXplorer、David Pallman 的 Azure 存储资源管理器,或其他类似工具。这些工具都依赖于 SDK 或直接 API 调用。
现在,关于您的代码:您需要在插入对象之前创建表。请参阅 CreateTablesFromModel() 和 CreateTableIfNotExist()。 Azure 平台培训套件 有一个关于创建和使用表的精彩介绍/实验,并展示了如何使用 CreateTablesFromModel()。
I think you're confusing Azure Table Storage with SQL Server or SQL Azure, which are completely different. You cannot access Azure Storage tables at all with SSMS. The code sample you provided is using the Azure SDK (which is using the Storage REST API underneath). That's the only way to access Azure Storage.
If you want to create / view tables in a more graphical way, try Cerebrata's Cloud Storage Studio, ClumsyLeaf's AzureXplorer, David Pallman's Azure Storage Explorer, or some other similar tool. These tools all rely on the SDK or direct API calls.
Now, regarding your code: You need to create your table before inserting objects. See CreateTablesFromModel() and CreateTableIfNotExist(). The Azure Platform Training Kit has a great intro/lab for creating and using tables, and shows how to use CreateTablesFromModel().
只要该表存在,那么您编写的代码就会将“John Doe”添加到员工表中。虽然通过 SSMS 查看数据可能很有趣,并且您可以尝试以这种方式更改数据,但我不建议尝试它。开发存储已经很有趣了,不用用棍子戳它。开发存储和实际的云存储之间存在差异,因此我发现越早停止使用开发存储越好。
目前,还没有在 Azure 表之间传输数据的奇特方法(无论是在开发存储中还是在云中)。它归结为运行一个查询,从源表中选择所有内容,然后将每个单独的项目写入目标表。根据数据的分区方式,您可能能够批量写入,也可能能够并行执行它们。如果您愿意直接使用 REST API,则可以避免存储库在写入每个项目之前对其进行反序列化。
As long as that table exists, then yes, the code you have written will add "John Doe" to the employees table. While it can be interesting to look at data through SSMS and you could try altering data that way, I wouldn't recommend trying it. Development storage is funny enough without poking it with a stick. There are differences between dev storage and actual cloud storage, so I have found that the sooner you can stop using dev storage the better.
At the moment there is no fancy way of transferring data between Azure tables (be they in dev storage or in the cloud). It boils down to running a query that selects everything from the source table, then writes each individual item to the destination table. Depending on how your data is partitioned you might be able to batch the writes or you might be able to do them in parallel. If you're willing to use the REST API directly you could avoid the storage library having to deserialise each item before it's written.
尽管最好使用 API 与 DevStorage 进行通信,但在某些情况下,直接数据库访问可能是有益的。更具体地说,它可用于规避 DevStorage 特有的一些 SDK 问题。
我曾经遇到过重命名大 blob 的问题 - 操作会超时(请注意,blob 无法重命名 - 首先需要使用 CopyFromBlob() 复制它们,然后删除)。我在 Azure 存储资源管理器中尝试了两种方法,一种是编写代码并增加所有超时。解决方案? SQL 来救援!
下面是一个 SQL 示例,它将重命名容器内的 blob 或将其移动到另一个容器:
当然,使用它需要您自担风险 - 这是一种完全不受支持的开发存储方式。
Even though it's best to use the APIs to talk to the DevStorage, there might be scenarios where the direct database access could prove beneficial. More specifically, it can be used to circumvent some SDK issues that are specific to DevStorage.
I once ran into a problem with renaming of large blobs - the operation would simply time out (note that blobs cannot be renamed - they first need to be copied using CopyFromBlob() and then deleted). I tried both in Azure Storage Explorer and by writing code and increasing all the timeouts. Solution? SQL to the rescue!
Here is an example of SQL that would rename a blob within a container or move it to a different one:
Of course, use it at your own risk - this is a completely unsupported way of working with dev stotage.