Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You are trying to solve two problems at once, which may not be the best approach. First, you are <strong>migrating</strong> an existing application. Second, you are trying to develop a <strong>scale out</strong> architecture. If you try and do both of these at once, you are going to run into architectural problems. I suggest that you migrate the application first, without too much concern about the scale out. Once you have the application running, you can then develop a more scalable architecture. You will find very few solutions that have scalable, SQL, and low cost together — so any 'scalable' solutions that you come up with, with such a high dependance on SQL, are going to have a few painful compromises. </p> <p>In order to build something that is more scalable, you are going to have to take a close look at, and plan extensive rework, of your existing architecture. Break the application into separate workloads, ditch your high dependency on T-SQL, triggers, and complex stored procs... and a few other things. The need/business case for whether or not this is worthwhile depends on your application roadmap.</p> <p>Assuming that you have longer term good reasons to move to Windows Azure (cheap for existing app is not one of them), then you are currently embarking on the first step of your migration strategy. I suggest that for this first step that you change as little as possible and simply just 'get it working'. In that case, it may make the most sense to put SQL on a VM — if nothing else but to give to more control and leeway. After everything is running (step 1 of your migration), then you can look at further phases of migration. Steps 2 to <em>n</em> mean that your application architecture will change dramatically, making more use of table storage, and less of SQL. So by step <em>n</em> - <em>m</em> the performance and/or scalability of SQL will not be a problem.</p> <p>The data model of a cloud application is more complex, and requires careful consideration. This is something that I have written about in detail in data model of <a href="https://github.com/projectcalm/Azure-EN" rel="nofollow">CALM</a>.</p> <p>DON'T PANIC. </p> <p>If your application has a mundane future, then a co-lo hosted solution may be the best — where you can specifically configure a database server that meets your needs. If you have high ambitions for your application, then over time you can migrate it to a much more scalable and cloud-friendly architecture that runs well on Azure.</p>
    singulars
    1. This table or related slice is empty.
    1. POAzure Database Design, partition out data tables vs federations?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USSimon Munro
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POAzure Database Design, partition out data tables vs federations?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COThanks for your input Simon. I agree that we are probably trying to solve to much to early. I can't imagine our app running outside of the relational model that SQL offers due to all the joins we perform in order to display useful reports. Admittedly many parts of the DB could go into NOSQL tables with the core financial functions running in SQL. Our product services the UK market so I don't think scaling in a Co-Lo environment would be impossible, I just hate all the associated hardware issues!! I do however like the concept of Azure and running the DB on a VM will be my next test scenario.
      singulars
      1. PO
      1. USQFDev
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload