I am trying to make a proof of concept where a simple ASP.NET web application that is using Entity framework updates automatically when a record is added to my Azure SQL Database. I did some research and stumbled across SignalR and SqlDependency. At first sight this seems exactly what I want but according to this:
Creating a Query for Notification
There are a lot of restrictions if I want to use SqlDependency. Like I can't do something like this:
context.table.Take(100).Skip(50).ToList();
Because this would result in a SELECT TOP and that is not permitted according to the previous link. I also don't want to get the whole table because that would be over 100 000 records and that would cause performance issues.
Is there a way to have real time data (only like the last 20 inserted records) from my azure SQL database shown on my ASP.NET web application? Preferably not with a periodic refresh but only if a record is inserted.
Related
I am planning to make a software (ASP.NET 4.6.1 MVC with Entity Framework), which does a lot of reading from DB. Therefor I have one database, which contains all global information, projects etc. and now I am thinking to either bring all the content into the same DB but in different tables or to create a DB for each bigger group.
Now as there is a lot of reading going on, is it bad practise to have the connection information in the main db and then to connect to a different DB? Otherwise I would have the project information in the primary database and the content in a different table on the same DB.
Are there any notable delays to connect to a different DB to retrive the information?
If it's all your data, for your application, it should all go in the same database. Definitely use different tables. You should read up on entity design and normalization... and if you really need to do that, you may already be in over your head.
I'm currently developing an app where the users are first asked to create an account trough a website (ASP.NET) to use the app. For a special reason I need to automatically generate a database for each customer creating an account, on the hosted SQL Server. The databases for all the customers are the same.
I was thinking about doing like that: as I have the script for creating the database, I was thinking to insert it in stored procedure or a trigger that will be launched as soon as the user has fully created his account.
I don't really see other solutions, maybe somebody could give me some guidelines? Thanks in advance.
I think such a design has been shown to not scale. I'd recommend redesigning the schema to allow multiple customers in a single database.
Amazon does not such thing. Neither should you.
I agree duffymo on you would have scalability issues.
However there are situations where in you might prefer separate database as your multi-tenant data approach.
In my last project I had to adopt separate DB approach as business wanted complete isolation for each customer. It was a school administrative system and number of customer was not expected to grow in more than three digits in 5-10 years time.
So the solution I designed was, I used Entity Framework code first approach. Every school will have a unique school identifier which will be used to name the database uniquely for each school. The connection string was generated at runtime obviously. A connection factory was used to create the appropriate DataContext based on passed school identifier. The database is created on first usage if not exist. At the same time SQL script was executed to create db users during db creation if not exist.
If this approach sounds appealing I can share code snippet if that helps.
I have a report deployed in asp.net web application, it works on small amount of data.
But when the data set contains thousands of records It may timeout on client side and data not appears.
So how can we solve this problem and retrieves unlimited amount of data to Client when query this report?
Even without knowing the specifics of your situation, you should look into applying paging to your output report. On the server side, make sure that your query utilizes indexes applied to the source tables.
I am in the process of developing a web based solution do replace an application we provide. The web application is a record storing application and each client would have different forms they would input data into and store. My question is: Is it possible to create a backbone Web Project, which would have minimal updates this would be like a container and be the same for all of our clients, and have the document forms which would be different among clients and need to be updated more often.
Any constructive comments for or against this with reason why would also be appreciated.
It sounds like what you’re describing is a multi-tenant system if you'd like to do some research on that term. Your web interface remains the same for all, but the records/documents are different for each client. It sounds like you might need login/access functionality that ties the records to a client ID (possibly stored in a database). According to how you intend to store the records (file system vs. database), you can control access either based on the client ID (foreign key to the doc tables) or you might want to create roles. This is a very high overview for what can become complex according to the specs.
We are going to be selling a service that will be hosted by us, and each client we host will have their own database, but there will be one centralized website. I currently have a blank database with the few things that a new client will need. What is the best way to copy this database so I can setup another client? I want to be able to do this from an .aspx page. Thanks in advance!
Update:
By .aspx page, I just meant that I need to be able to kick off the process from an .aspx page.
Update2:
We're running SQL Server 2008.
Update 3: Referencing Cade Roux's answer... Thanks for a great answer, but...
What is the reason for merging all of the databases into one, and then distinguishing clients based on an identifier in each table? Wouldn't this greatly complicate the architecture of the entire product? I would need to add these Client ID columns to practically every table, and the DAL would need to know which client data its looking for. With the current setup I have, I just switch out the connection string in the DAL, depending on which user is accessing the site. That way, after the connection string is set, I never need to worry about finding client specific data! How do these approaches compare (and should I add this as a separate question?
You have a few different options:
You can detach your empty database, then when a user signs up, copy that database and mount it under a unique name for them and map it to their account in your master database, say.
You can create a database from scratch using scripts and populate any base data either from an online template database or scripting the base data and map it to their account in your master database.
You should seriously consider going to a multi-tenant architecture where all users are in the same database (with most tables having CustomerID columns to segregate the data) if you are going to have more than a few dozen customers.
Regarding your notes about option 3 - it depends on your application. Multi-tenant can be difficult to retrofit. On the other hand, managing and upgrading hundreds of individual customer databases can be difficult in the long haul.
There are previous Stack Overflow questions regarding this:
What are the advantages of using a single database for EACH client?
One database or many?
I think I'll see about re-tagging them with multi-tenant-db or something. Anyhow, I think that this comes up as a consideration secondary to your answer about a particular tactic does show the importance of including details about your overall goals in strategy in every question on StackOverflow.
Depending on what database you're using, there are several approaches. The simplest is to ask your database software to generate SQL code for creating the database and include that with your software. Another would be to just script out in C#/VB the steps needed to recreate your empty database.
Why the need for .aspx page?
You don't say what db version you're using but in SQL2005-2008, you have the ability to "script database as" and then "create to" and have it port the sql to a query window. You could then work with that to create a stored procedure that can be called from your .aspx page.
SQL Server has a system database called 'model'. Any database objects (tables, views, stored procedures) that exist in the model are added to any new database created.
You could create your 'client database' schema as model, and any new database would have all the same tables...
But, if you need to change your database schema later, your best option is to write change scripts which are part of your code-behind file. Since changes to the 'model' database are not propagated to existing databases, the application needs to detect and upgrade the database schema as necessary.
Disadvantage to this approach: If you want a database which isn't a 'client database' then you would need to create the database, and then delete the 'client database' tables.