I'm just learning about Azure Mobile Apps. Do Easy Tables support relationships? My existing schema has multiple tables with foreign key constraints, and I need the ability to create complex joins (Easy APIs). I'm trying to understand the point of all this "Easy" stuff.
Should I skip it and just create a custom ApiController and manual db script deployment?
Easy Tables are just simple SQL Azure tables that are exposed through a Web API OData Service endpoint. So when you create them you can connect to the SQL Azure and create your relationships etc there and customize the API code to include those relational data in the response.
From my experience they are good if you dont have complicated logic/business rules or complicated queries.
To my experience if you have complicated stuff even normal Web API OData Service endpoints would not help because the interception of the requests makes the code complicated and you are better off creating your own Web APIs.
I almost feel like the Easy API and Easy Tables are more designed to give you a kick start for a simple mobile app in a hackathon or to put an idea together as a demo real quick. But for real life enterprise stuff I will go with building my own Web API.
Related
Currently I have a monolithic application with some modules like financial and accounting. This application uses a single database and the modules are divided into schemas, so when I need to display the data on user interface or in a report I just need to do a simple query with a couple joins.
My question is, in a microservices structure where each module has his own database, how do I retrieve this data getting the same result as if I were in a single database?
When talking about splitting the database in the process of migrating a monolith to Microservices, there are some known patterns like:
The shared database
Database view
Database wrapping service
Database as a service
Seems the database view or the database as a service could be a candidate in this case, but of course no one better than you can decide which one is viable in your project.
I highly recommend you to have a look at chapter 4 of "Monolith to Microservices" by Sam Newman.
I'm looking for some resources to get me started on how to design and implement an API for SQL.
Is this done by writing a series of functions and/or stored procedures to process your transactions on the SQL server (T-SQL).
I have read a bit about Transaction API's v Table API's. While you don't have to chose one of the other I would prefer to avoid the Table API's and focus more on Transaction API's to keep performance high and avoid using cursors.
Also from what I understand RESTFUL API's are just making the requests through HTTP requests (Using JSON) rather than connecting to the DB directly.
If my understanding is completely wrong on this subject please correct me as I am trying to learn.
Thanks
I'm using a javascript-based Azure Mobile Service, so no Web API / Entity Framework / Code First. I'm just using the Azure portal to create the tables and columns. I've noticed that there's no way to define strong relationships between tables. I have created columns that reference other columns. But unlike Entity Framework, this does not create true foreign key relationships between tables.
I've read that one can use the $expand ODATA operator to return related data:
http://zimmergren.net/technical/extending-windows-azure-mobile-services-queries-to-include-relational-data-and-optional-metadata
...but the MSDN documentation for the Azure Mobile REST API does not contain the $expand operator:
https://msdn.microsoft.com/en-us/library/azure/jj677199.aspx
Does this mean that relational queries are not possible without using an Entity Framework based Azure Mobile Service? Is the $expand operator only available for .NET-based Azure Mobile Services (not javascript-based)?
The $expand query operator is not supported in the Node.js backend for Mobile Services. However, you could certainly modify your Read backend scripts to return data from the related tables.
See this document for more information on implementing joins in your backend code: https://azure.microsoft.com/en-us/documentation/articles/mobile-services-how-to-use-server-scripts/#joins
You should also make sure you optimize your SQL queries: https://azure.microsoft.com/en-us/documentation/articles/mobile-services-sql-scale-guidance/
I'm currently developing a service for an App with WCF. I want to host this data on windows-azure and it should host data from differed users. I'm searching for the right design of my database. In my opinion there are only two differed possibilities:
Create a new database for every customer
Store a customer-id to every table (or the main table when every table is connected via entities)
The first approach has very good speed and isolating, but it's very expansive on windows azure (or am I understanding something of the azure pricing wrong?). Also I don't know how to configure a WCF- Service that way, that it always use another database.
The second approach is low on speed and the isolating is poor. But it's easy to implement and cheaper.
Now to my question:
Is there any other way to get high isolation of data and also easy integration in a WCF- service using azure?
What design should I use and why?
You have two additional options: build multiple schema containers within a database (see my blog post about this technique), or even better use SQL Database Federations (you can use my open-source project called Enzo SQL Shard to access federations). The links I am providing give you access to other options as well.
In the end it's a rather complex decision that involves a tradeoff of performance, security and manageability. I usually recommend Federations, even if it has its own set of limitations, because it is a flexible multitenant option for the cloud with the option to filter data automatically. Check out the open source project - you will see how to implement good separation of customer of data independently of the physical storage.
we have several sites for several different clients, each with several different databases.
Some of the databases are at client location, some are on our site.
I have been tasked with creating a few sharepoint sites that will display information from the databases.
Is it okay to call stored procedures from my sharepoint sites? Since the database is not for the sharepoint site, I feel like that site should not have direct access to the DB and should get the data through web services. Certainly, this would be the case if the data were exposed to another company, but since we are responsible for all of it, is that okay?
In my opinion you save yourself from lot of trouble by just going directly to the database, since you control both ends. The direct access to DB will also have better performance than writing some web services in between the two systems.
If the other system wouldn't be yours, I'd definitely hope that it had a web services (or RESTful web services) interface. My reasoning here is that in most software, web services are really actually meant for integrations and thus changes to them are kept at minimum. Database schema changes are fairly typical during the lifetime of a software product and thus it's not generally easy to evolve the schema if other people build integrations directly against the DB.
Querying the database directly is not a supported scenario, thus you shouldn't ever need to do that.
Best practice is to use the existing Web Services, or implement your own custom Web Service.