Mssql remote application VS web application
I have a client request to develop a Point of Sale (POS) system. but most of the POS system uses a desktop-based application.
client request for all branches no database setup required and branches are directly linked to the HQ server.
this type of requirement is fine for web applications,
but if I am using a desktop application, VB.NET for development and remote access to MS SQL database.
any problem i run into? is it stable?
dont worry about server business,
I just want to know when to fetch huge data for web and desktop (remote db access) data retrieval rate any differentiate?
Server Bandwidth: DEDICATED 100MB DOWNLOAD AND DOWNLOAD
source to share
Basically ... if you are using a remote application, there are many configurations and problems can arise when it comes to the types of OS that a specific user will be using, such as a MAC PC or any Apple product.
Visit these sites: site1 and site2 for more information. The Web application is more convenient than a desktop, but if you try to create a desktop computer and are having problems with the database, you can use VB.Net
and POSTGRESQL
as a database that is not directly related to your VB have a Web database. I don't know exactly how to call it, but try to have a web app that displays the json format for your data and calls it from your VB code. The exact process uses the method GET
and POST
.
you can use this code ... under your module:
Public globalLink As String = "https://samplesite.com/"
Public Sub Save(ByVal link As String, ByVal data As String)
request = WebRequest.Create(link)
request.Credentials = CredentialCache.DefaultCredentials
request.Method = "POST"
request.ContentType = "application/x-www-form-urlencoded"
postData = String.Format(data)
request.ContentLength = postData.Length
byteArray = Encoding.ASCII.GetBytes(postData)
request.ContentLength = byteArray.Length
dataStream = request.GetRequestStream()
dataStream.Write(byteArray, 0, byteArray.Length)
dataStream.Close()
response = request.GetResponse()
dataStream = response.GetResponseStream()
reader = New StreamReader(dataStream)
webRep = (CType(response, HttpWebResponse).StatusDescription)
dataStream = response.GetResponseStream()
reader = New StreamReader(dataStream)
reader.Close()
response.Close()
End Sub
link
is literally a link, and data
are passed parameters. The parameters will look like this when you save ...
www.samplesite.com/POSdata?id=01&field1=sampledata&field2=sampledata2
When I followed this process I used Ruby on Rails
deployed to Heroku
and called from VB
, which works well.
The only problem with this method is when you have a slow internet connection, which is definitely not a problem.
source to share
I just want to know when to fetch huge data for web and desktop (DB remote access) is the data retrieval rate different?
If by this you mean “is there a difference in speed between a desktop application and a web application when accessing large amounts of data from the database,” the short answer is likely no . Your database design and code efficiency are far more likely to affect the performance of your transactions than the (possibly) subtle differences in architecture between access across different platforms.
Assuming all of your PoS clients will be running on the same platform (both web server and desktop), you will only be developing one way to enter your database. Therefore, instead of building a complex system to support different customers, you can focus support on a single access scheme. You can take the time and effort to make your database and code as efficient and reliable as possible.
There is some evidence to support that web access will be slower overall, and you should certainly take that into account. Take a look at this question , for example, where Wim ten Brink suggests that "connecting over a network service will always be slightly slower" and other users have suggested "desktop" strategies. However, please note that this is very empirical evidence and these answers do not necessarily apply to remote database access, just different schemas.
However, you must also weigh the other costs / benefits between methods versus pure performance representation. As mentioned in the question above, for example, web applications are beneficial in other ways, such as a faster client-side update process and much greater (inherent) security. Which of the myriad priorities is important and how important it is to your project is entirely up to you (and mainly with your client), but I would suggest making a decision based on one performance metric (especially since you cannot accurately assess the impact without testing each in their particular scenario) can be a little narrow-minded.
Finally, I'll just take a moment to re-emphasize what I tried to do in my comment earlier : speed is an absolutely moot point if you lose connectivity (and therefore functionality), without a fallback solution. Your client might think they don't need a backup, but I guarantee they will change their minds when the smallest mistake causes them to lose sales.
Additional Resources
- This question has some good answers to why a web application might work better for you since your database needs to be hosted remotely (what's important is that the web application is hosted locally in the database).
- Here's a question with some really solid answers arguing web vs. desktop, although not specifically about database access.
source to share
For performance purposes, a web application can give you the same performance as a desktop application if you use an optimized service like the Web API with an optimized interface. The main problem with implementing POS as a web application is that clients must be online at all times, which is not guaranteed. So I think the best way is to create a WCF / Web API service that encapsulates all the business logic and consumes that service from the Desktop application. The peculiarity of this architecture is the following:
- You will have all the business logic in the service, so if you make future changes to the service, you will not re-install the application on all clients.
- Your business logic and database structure will not be distributed with the client application.
- You can use Sync Framework to store data locally if your server connection is down.
- You will have more control over your applications than on the web, which will result in multiple Windows events, making your application more usable and better.
Note. Accessing the DB remotely will work great for you in terms of performance. But you will need to deploy the desktop application to all clients on every minor change. And from a security perspective, it is not recommended to add the database schema and connection information for all clients.
source to share