I'm developing an ASP.NET MVC 4 web application hosted on IIS which will be using multiple databases on a single SQL Server 2014 instance (each database for a different company). The web application will be used for analysing and summing large amounts of business data.
What is the best practice in this kind of situation? Will there be performance issues if only one web application and pool is used with multiple databases? One database may have 1-20 users.
Which one would be a better choice, A or B?
A) 1 web application and 10 databases
B) 10 web applications and 10 databases
Your question doesn't belong to MVC at all.
If you have large amounts of data and you worry about performance, then you should think about how to store and query data at the database level. And you may interested in this kind of questions:
What provider use to query data? (pure ADO.NET or an ORM like Linq-to-SQL or EF)
Should I have all databases in one SQL Server instance, or can I use linked servers or even union data on web server side?
Should I have my databases files on different hard drives?
Answering these questions:
ADO.NET is always faster than ORMs just because they all use ADO.NET at their core. But it's harder to maintain ADO.NET queries in future
Linked servers are slower especially if you have your database on different machines (you will transfer your data by net and it is not fast if the is a large amount of data)
In the performance way it's better when your database files stored on different hard drives
Answer to your question now will be obvious, I think :)
Create one web application.
Related
Trying to figure out the best way of managing data stored in an on-premise SQL Server database, for a Power Automate Model-Driven App. For Canvas Apps, typically I use a connector to either access the tables directly, or to access the data via a Power Automate flow.
From my research, it seems like I have two options:
Create Dataverse tables which represent all of my SQL Server tables, and use an ETL tool to keep those tables in sync.
Use a Virtual Table to connect "directly" to the SQL Server tables
Neither of those options really seem great, though. The entire premise of the Power Platform is for a relatively low-code experience, and both of those two options require quite a bit of coding. The ETL option, for example, requires me to write ETL operations for every table that I want to manage, along with dealing with any number of concurrency issues that may arise. The Virtual Table, on the other hand, seems on the surface like it'd be a better approach, but to actually implement a Virtual Table for an SQL Server table, I need to write a custom connector, and I need to leverage the old D365 UI to manage it.
The "best" approach I've seen so far is explored a bit by Juuka Niiranen in this blog post, however, a year later, and the approach he wrote about is still in preview: https://jukkaniiranen.com/2021/06/virtual-dataverse-tables-with-no-code-via-connectors/ and https://learn.microsoft.com/en-us/power-apps/maker/data-platform/create-virtual-tables-using-connectors?tabs=sql
Does anyone have any other suggestions? Is that above connector approach the recommended one, despite still being in preview?
I have been asked to build a SpringBoot POC based on a relationship data set.
For context purposes you can consider an HR system data set.
If chose to build a monolithic app, I can use just SQL database.
If I use microservices patterns, I would need to use Sql and NoSql databases.
Is there a real world scenario where I would split the data between the 2 databases?
Like separation of concerns?
Is there a scenario where one would choose to use 2 databases?
To me it doesn't make any sense, but I might not be experienced enough to have had a scenario like this.
I am tasked with writing a Winforms point-of-service app for a small company that has about 10 locations. It has a fairly simple database structure with tables for customers, invoices, transactions, stores, vehicles, etc. I'm thinking of using Azure SQL Database for the "master" database, but the app is mission critical for each location and needs to have an "occasionally connected" architecture to insure that it can run if and when an Internet connection is not available, and then sync when the connection is back.
I have researched the Microsoft Sync Framework, which seems like the best option, but all the documentation seems several years old and out of date.
Azure Data Sync looked promising, but that seems like more of an Azure Management type tool, whereas I want the sync functionality to be built into the client application.
Some of the mobile solutions sound interesting, but it seems to me that I need essentially identical SQL Server databases on the client and cloud server, and most, if not all of the tables need to stay synchronized. I'm thinking the easiest way to do this would be to use GUID IDs for each entity and either Sync Framework, or rolling my own code for synchronization.
So, I guess my questions are:
What is the generally recommended, up-to-date approach for creating an occasionally connected Winforms app?
Is the MS Sync Framework still relevant?
Is my idea of having identical databases on client and server, using GUID IDs for entities, and either using MS Sync Framework, or rolling my own synchronization code plausible or insane?
Thanks.
I'm going to develop a Web Application with two essential requirements:
Total independence of DBMS. The application should work with different DBMS like Oracle, SQL Server and MySQL. That is, Client 1 use this application with SQL Server, but he wants to migrate to an MySQL Database. The application should be able to work with this new DBMS without needing to make changes to the application code. The only change I want to do is to change the connection string.
Scalability. ie, we will have a clustered SQL Server installation.
I know that Data Access Block is able to handle different DBMS and I assume it won`t be an issue to meet the scalability requirement, but I don't know if this is the case with Entity Framework.
Choose Entity Framework, for a couple of reasons.
First, EF is where Microsoft is putting all its data access emphasis for the foreseeable future. Entlib's data block is primarily there to support folks already using it.
Second, Entlib will give you a regular API, but it doesn't insulate you from the differences in SQL statements. Oracle in particular does stuff with cursors no other database does (or needs to); EF at least attempts to give you a uniform API.
As far as scalability, that's all about the design of your database and application, no data access tool will give you that.
Our IT manager is asking my help on deciding on which would be the best to save the data. Is it in sharepoint or sql server.
On my side I don't know much about saving data on sharepoint server, how does it work, how fast, how secured, etc. I even have a doubt if sharepoint is capable of complex database design. As far as I know, sharepoint is not a database server that's why I have this doubts.
So obviously I would say Sql Server would be my prefered storage and also because Sql server is known to me for a long time already. Considering my 3 weeks exposure on sharepoint vs. 7 years on Sql Server. I don't have the enough experience to witness the strength of Sharepoint for me to decide on what to do. So to be fair on sharepoint I would like to ask you guys out there who are more experienced on this.
My questions:
1.) Does sharepoint have the ability to store data?
2.) If sharepoint can store data, what are the pros and cons?
3.) Can it cover a complex design such as relational database design like sql server does?
4.) If you where to develop a sharepoint project, would you choose sql server as the backend?
Thanks in advance!
It obviously depends on the application, and complexity of it, who the client or audience is, and how you want to deploy it.
Here are my answers to your questions:
1. Yes
2. Pros:
It provides a UI for updating data.
Cons:
Creating relational structures will be complicated.
Think custom lookup lists, associated with other custom lists.
3. Yes, but I wouldn't try it.
4. SQL Server, but this depends on the project and
isn't an entirely technical decision.
Personally, I think given your skillset, you should use SQL Server, if your manager has said it's up to you.
SharePoint itself is built on top SQL Server and ASP.NET.
Yes. You can create a custom list (basically similar to table structure), you can store document along with its metadata. You can store web pages if you are using it as your publishing (CMS) platform.
It's not supposed be a relational engine like SQL Server. Pro: versioning, workflow, for most cases, UI is there to support data input / editing. Con: Limitation of the UI w/ large amount of data.
To some degree you can relate one list to another field in a different list / document metadata.
See what I said before point 1.
SharePoint offers its own database layer built on top of SQL Server.
A complex object model is provided, and the SQL language API not available.
Acsess is by API, REST, and UI List Webparts with views; NOT SQL and the database is not accessible except through interfaces.
Deep inside data stored in Entity-Attribute-Value triples (specifically: site, web, list, item, state, field, value) such that each value goes into its own record. This is strickly non-tablular.
Maintains a dynamic end-user populated Metadata dictionary.
As a non-relational layer above a DB is offers inheritance, multi-type list, hierarchies, taxonomies, versioning, check in/out and other advanced features missing from a relational model.
Documents may be attached to a list.
Extensive use of GUIDS for identifiers, but this causes problems when moving partial related data between systems.
No referential integrity.
No joining of database tables or lists.
Filtering is more limited than in SQL.
No concept of a schema.
Parts of SharePoint break when restoring from a backup or when published to a separate site.
Rolling new features and data from development to production is problematic and sometimes breaks.
Hope this helps.
Sharepoint is obviously not a Database Server but somehow it works on some ways.
1.)Yes
2.)You can but not as complicated as Sql Server does.
Pros: It's the interfaces the gives sharepoint the edge, UI grants the user a friendlier way of inputting data.
Cons:Just like what I've said complicated database design is not easy to do.
3.) 100% Yes
4.) I would prefer Sharepoint if the application doesn't need complex design on data. Definitely Sql Server for enterprise type of application.