Utilisation du stockage Azure local Development via SSMS (sql server management studio)

Question

J'essaye d'écrire du code pour accéder à mon stockage de développement local azur. J'ai commencé par la création d'un nouveau stockage pour moi-même:

dsInit /forceCreate 

Je peux maintenant voir le DevelopmentStorageDb20090919 dans SSMS avec quelques tables precreated tels que dbo.TableContainer, dbo.TableRow etc.

1. Maintenant, peut J'ai simplement ajouter des tables à cette base de données via SSMS (par exemple, table des employés) et commencer à y accéder via le code? Est-ce la bonne façon de faire les choses?

Par exemple:

var svc = CloudStorageAccount.DevelopmentStorageAccount 
.CreateCloudTableClient().GetDataServiceContext(); 

       //"Employees" is the name of the table     
       svc.AddObject("Employees", new Employees("John Doe"));  
       svc.SaveChangesWithRetries(); 

2. De plus, une fois que j'ai terminé, comment puis-je transférer la table et les données dans le compte cloud réel? En exécutant des scripts là-bas?

Answer 1

Tant que cette table existe, alors oui, le code que vous avez écrit va ajouter "John Doe" à la table des employés. Bien qu'il puisse être intéressant de regarder les données via SSMS et que vous puissiez essayer de modifier les données de cette façon, je ne recommanderais pas de l'essayer. Le stockage de développement est assez drôle sans le piquer avec un bâton. Il y a des différences entre le stockage de dev et le stockage réel de nuage, ainsi j'ai constaté que le plus tôt vous pouvez cesser d'employer le stockage de dev le meilleur.

Pour le moment, il n'y a pas de moyen sophistiqué de transférer des données entre les tables Azure (que ce soit dans le stockage de dev ou dans le cloud). Il se résume à exécuter une requête qui sélectionne tout de la table source, puis écrit chaque élément individuel dans la table de destination. Selon la façon dont vos données sont partitionnées, vous pourriez être en mesure de traiter les écritures par lots ou vous pourriez être en mesure de les faire en parallèle. Si vous souhaitez utiliser l'API REST directement, vous pouvez éviter que la bibliothèque de stockage désérialise chaque élément avant de l'écrire.

Answer 2

Je pense que vous confondez Azure Table Storage avec SQL Server ou SQL Azure, qui sont complètement différents. Vous ne pouvez pas du tout accéder aux tables de stockage Azure avec SSMS. L'exemple de code que vous avez fourni utilise le SDK Azure (qui utilise l'API REST Storage ci-dessous). C'est le seul moyen d'accéder à Azure Storage.

Si vous voulez créer/afficher des tableaux d'une façon plus graphique, essayez de Cloud Storage Studio Cerebrata, AzureXplorer de ClumsyLeaf, David Pallman Azure Storage Explorer, ou un autre outil similaire. Ces outils reposent tous sur le SDK ou les appels API directs. Maintenant, en ce qui concerne votre code: Vous devez créer votre table avant d'insérer des objets. Voir CreateTablesFromModel() et CreateTableIfNotExist(). Le Azure Platform Training Kit a une grande intro/laboratoire pour créer et utiliser des tables, et montre comment utiliser CreateTablesFromModel().

Answer 3

Même s'il est préférable d'utiliser les API pour parler au DevStorage, il peut y avoir des scénarios dans lesquels l'accès direct à la base de données peut s'avérer bénéfique. Plus précisément, il peut être utilisé pour contourner certains problèmes SDK spécifiques à DevStorage. Une fois, j'ai rencontré un problème avec le renommage des gros blobs - l'opération expirait simplement (notez que les blobs ne peuvent pas être renommés - ils doivent d'abord être copiés en utilisant CopyFromBlob(), puis supprimés). J'ai essayé à la fois dans Azure Storage Explorer et en écrivant du code et en augmentant tous les délais. Solution? SQL à la rescousse!

Voici un exemple de SQL qui renommer un blob dans un conteneur ou le déplacer vers un autre:

begin tran 

alter table CommittedBlock nocheck constraint BlockBlob_CommittedBlock 

update CommittedBlock set BlobName = @TargetBlobName, ContainerName = @TargetContainerName where BlobName = @SourceBlobName and ContainerName = @SourceContainerName 
update BlockData set BlobName = @TargetBlobName, ContainerName = @TargetContainerName where BlobName = @SourceBlobName and ContainerName = @SourceContainerName 
update Blob set BlobName = @TargetBlobName, ContainerName = @TargetContainerName where BlobName = @SourceBlobName and ContainerName = @SourceContainerName 

alter table CommittedBlock with check check constraint BlockBlob_CommittedBlock 

rollback tran 

Bien sûr, l'utiliser à vos propres risques - c'est un complètement non pris en charge façon de travailler avec dev stotage.