具有现有数据库的Azure移动服务(无需更改架构) [英] Azure Mobile Services with Existing Database (without Schema changes)

查看:83
本文介绍了具有现有数据库的Azure移动服务(无需更改架构)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

作为免责声明,我警告说,这里可能存在不正确的理解,希望不是,但是也许.

情况:

有一个现有的Windows VB时间表应用程序可部署在客户的Windows设备(不是RT)上.此应用程序创建本地SQL Express存储并通过SQL数据同步与Azure SQL DB同步.

Azure SQL数据库进一步与主数据库同步(也通过SQL数据同步),该主数据库存储在与我签约的本地数据库中,通常仅在此主数据库中更改主数据,而事务数据则一直同步到该主数据库天青.

应用程序正在使用的表都在dbo模式下.

我正在尝试创建一个Xamarin Forms移动版(使用PCL的iOS,WP8,Droid以及winRT,使用PCL)版本的应用程序(罗word,但您明白了),该版本使用指向Azure SQL数据库.到目前为止,它仅使用部分功能.

问题:

现在的问题(可能已经很明显了)是我需要访问大多数表,这些表都在dbo模式下,并且我希望/想知道解决此问题的最佳实践./p>

如果我可以指出我的Azure移动服务使用dbo架构,并为手动生成的登录名/脚本赋予适当的特权.对于我的表迁移,这需要包含所需的系统属性(第四位).

另一个建议是将azure移动服务同步操作所需的系统列添加到主数据库,将其推送到azure数据库,然后创建移动服务架构中所有必需数据的视图.我尚不清楚这是否会对服务造成任何限制.

当然总是可以选择将所有数据移动到dbo以外的其他模式-但这需要在其他系统上进行扩展工作,这可能会花费大量时间,尤其是由于我对它们不熟悉.

任何相关信息,讨论或建议都将得到彻底的赞赏.

解决方案

可能最好的选择是为数据库创建Azure移动服务系统属性.在Azure移动服务上,需要五个特定字段:

  • id-应该是唯一的字符串-在此处使用GUID的好主意
  • __ version-由AMS处理,默认/允许为空
  • __ createdAt-通常在插入时在SQL Server上自动生成
  • __ updatedAt-由AMS处理
  • __ deleted-除非记录被删除(软删除支持),否则应为false

这些都在.NET SDK的EntityData类中定义.您可以一次性设置现有记录的值,然后让AMS SDK从此开始对其进行处理.

As a disclaimer I warn that there may be malformed understandings going on here, hopefully not, but maybe.

The Situation:

There is an existing Windows VB Timesheet Application that deploys on customers Windows devices (not RT). This application creates a local SQL express store and synchronises with an Azure SQL DB via SQL data sync.

The Azure SQL DB further sychronises with a master DB (also via SQL data sync) that is stored locally where I am contracted, the master data is typically only changed in this master DB and the transactional data is what is synced up to azure.

The tables the application is working with are all under the dbo schema.

I am working on creating a Xamarin Forms mobile (iOS, WP8, Droid, and maybe winRT, using a PCL) version of the application (wordy, but you get the idea) that uses an Azure Mobile Service that points to the Azure SQL DB. It only uses a subset of the features as of now.

The Problem:

Now the problem (as it may be obvious already) is that I need access to most of the tables, of which are under the dbo schema, and I was hoping / wondering what the best practice would be to solve this.

If I could point my Azure Mobile Service to use the dbo schema and give the generated login the appropriate privileges manually / scripted. This is needed for my migration of the tables to include the required system properties an so fourth.

Another proposition would be to add the system columns required for azure mobile services sync operations to the master db, push them up to the azure db and then create views of all the required data in the mobile services schema. I do not yet know if this would result in any limitations to the service.

There is always of course the option of moving all the data to a schema other than dbo - however this requires extension work on the other systems, which may consume considerable time particularly due to my unfamiliarity with them.

Any relevant information, discussion or advice would be thoroughly appreciated.

解决方案

Probably your best option is to create the Azure Mobile Services system properties to your database. On Azure Mobile Services, there are five specific fields you need:

  • id - should be a unique string - good idea to use a GUID here
  • __version - let AMS handle this, default/null allowed
  • __createdAt - generally auto-generated at the SQL Server on insert
  • __updatedAt - let AMS handle this
  • __deleted - should be false unless the record is deleted (soft-delete support)

These are all defined in the EntityData class in the .NET SDK. You can do a one-time set of the values for your existing records and then let the AMS SDK handle it from then on.

这篇关于具有现有数据库的Azure移动服务(无需更改架构)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆