I'm writing an application which will involve interaction with the database. The application will be used by users from the scale of 100 to 1000 and the database should be able to store up to 100,000 rows of data.
Previously I have used Microsoft Access but my users were required to install microsoft access database engine for my application to function as intended. I want my application to as light weight/portable as possible, so is there any better alternatives where users will not be required to install any third party components to run my application?
Look at mongoDB, it is an open source non relational database that has picked up popularity. Its is very fast too.
Depends on whether the DB will be server side or client side.
If it's server side it's up to you really, I would personally go SQL Server as I know that best, or even a mySql/phpMyAdmin combo. But if it's to reside on the client machine try SQLite (just a warning though it is exactly as the name suggests, LITE, so a lot of the more complex SQL might not be supported). SQLite may be exactly what you're looking for depending on the complexity involved in your project.
ALSO: SQLite is supported on iPhone, Blackberry and Android as well. So if you wanna go mobile, no problem.
Your application could connect to a cloud database (like SQL Azure). That will not require any third party components and it will be accessible from anywhere/any device.
Do you need a only one database for all the users or every user has it's own database? If it will be on the server side, i would prefer SQL Servers (ex. MSSQL, MySQL). But for clients side, SQLLite would do the work.
You should consider if a SaaS model is relevant, in other words if you could benefit from hosting all your users' databases on the cloud and let clients access it by remote. In your scenario I would consider a SaaS model if: (1) your users need to scale up their individual database beyond the capacity of their local machine, (2) there is a need to share data between the databases of different users - or maybe this could enable good features you don't have in your system today, or (3) users find it a drag to have to run the database on their local machine, because of the resources it uses up, uptime needed, backups, etc. If any of these are sometimes true, hosting all the databases on the cloud with some sort of multi-tenancy arrangement might be a good solution and will make your application as lightweight as possible because you don't need to include a database at all.
Related
I have created two applications using Visual Studio and C#.
The premise of the applications is for data entry and browsing of the data. However, I have come to the realization that these applications won't work on other devices as the data source is a local Access database. Am i able to somehow share these apps with others without giving them the Access database too? This is a major problem as my boss only wants these apps and not the database to be sent with them too. Or would I have to migrate the database to an SQL server and try to migrate the application as well?
Thank you
TLDR:
Can Access database applications be shared across desktops?
Yes
Am i able to somehow share these apps with others without giving them the Access database too?
Yes
Or would I have to migrate the database to an SQL server and try to migrate the application as well?
Not necessarily
It's a difficult question to answer because the question seems slightly confused
You've created an app or two that enters and shows data in an access database, and now you're asking if the app can be distributed without the Access database
Sure it can; but what then will be the purpose of the the app?
You ask if it could be switched to using sql server instead.
Sure it can, but I'm not really clear on how you think it will help because you then have to install sql server in the customer premises and give them the database. I suppose you could keep the sql server on your premises and they could connect to it, but then you could just as easily create a web service or API that sits in front of your access db and have your programs interact with the API, as a way of keeping databases off the customer premises and then stick with Access (or change it later and not affect the customers because you're providing the same api which a new db).
It's most typical, when having software that customers use and a database that you keep ownership of, to separate them with an api
As an aside, Access is terrible in a multi user configuration where two different apps are trying to use the same db file I've a file share; take any steps you can to avoid using this scenario
Stackoverflow is designed to answer particular kinds of questions and there's a real risk that this question will stray into opinion based territory and become off topic. We can't design your app for you, we can only help with implementation problems but it sounds like you need to sit back and think some more about what you're trying to solve for the problems your customers face, and see if you can get some help regarding the tech stack you should look to implement. If you desire SO to deliver these answers you'll need to ask them in a particular way, essentially having made a set of decisions yourself and be missing some facts that will drive the implementation choices - ask us for the missing facts rather than to make the implementation choices
If all the clients apps are on the same network and can see a central server, then there's no reason you can't use the Access database in the same way you would a SQL Server database, i.e. by placing it somewhere where it can be accessed by all copies of your application. Access isn't the last word in database features or security, but it's perfectly workable.
We normally create a mapped drive on the client PCs to a location on the server, so that everyone can use the same connection string for the database, e.g. T:\yourdatabase.mdb.
If the clients aren't on the same network and you can't use a VPN to connect them then to single network then things will become a lot more difficult, and moving to SQL Server will probably be a lot simpler.
Essentially, if this is an in-house system where the data isn't too sensitive and all the users are members of staff say, then a central Access database can work fine. If this is an app that's being used by people outside your organisation then SQL is a better choice if you want your app to talk directly to the database.
Alternatively you could write an API that you host on a web server, then your client apps can talk to the API and your API can talk to the Access database.
I created an application with a C # programming language and MySQL database.
When I want to install the software on the user's computer,
What software do I need?
MySQL software should be fully installed on the user's system?
Or is there another way?
Is this with a stand-alone database, or are you creating a shared database the client application needs to connect to?
If it's a stand-alone program then don't use MySQL. Use an embeddable database library like SQLite instead. These are far more durable and resilient and can handle abrupt shutdowns and restarts. MySQL needs a lot more care and attention, plus has a huge footprint in terms of memory and CPU consumption. Managing that automatically is not easy. Walking a client through how to repair a damaged MySQL database is not something you want to do.
If it's a shared database then you technically only need the client libraries, but remember, exposing MySQL to the general internet is extremely dangerous and should be avoided whenever possible. If you must, ensure that your users are using SSH or a VPN of some sort for access to restrict who can connect to your database server.
The best plan for a remote application is to build out an API that intermediates between client and database, giving you the ability to layer in access control at every level necessary to protect the data. MySQL has very broad access control, locking down individual records can be hard to do and easy to get wrong. Unless you can trust all users, it's best to not trust any.
You don't need the server installation on the client / remote machine. Just a workbench should be fine through which you can connect to the server and perform any database operations.
I wrote an application in c# & SQLite for storing data of all employees in a company which has around 500 employees. I want to put the database & the application in a file server/shared folder (MS server). Then all employees will have a shortcut of the application in their desktops. I want to make some input fields (text box) enabled/disabled based on the permission of the user runs the application. Whats the best practice for doing that?
I want the user can read/write in the database through my application only (the application is located in the same database folder). I don't want the user to reach the database without my application. How to do that?
I don't want the user to reach the database without my application
If your application will directly access the SQLite database via a Windows file share, this is impossible. Sure, you can make it inconvenient, but it's not really possible.
The only way to achieve this really is by introducing some middleware.
This would typically be a service (WCF perhaps) that listens for connections from your client application, authenticates them, and manages all access to the underlying database. The database would be stored in a location that is visible to the server only, and not visible through a Windows share to your users.
Also, SQLite isn't exactly a great choice for a multi-user system. You can kill two birds with one stone here - switch to a DBMS (MS SQL Server Express is free, also MySQL, PostgreSQL are common free choices) that accepts client connections over a network, and build your application to connect directly to the database server (using integrated Windows authentication may also be possible like this, so you can avoid an explicit logon). In a simple scenario this may be adequate and avoid you needing to build an explicit service layer.
In a more complex scenario, it can still make sense to have a middleware layer between the application and the database - this way, you can change the database design without changing the application design and deploying to all of your client machines - instead, just change the middleware layer in one place and your application won't know the difference.
If you don't want the users to reach your database you should create a client server architecture.
You can run your service on the same machine as the file server (running as a Windows Service) and use WCF for communication between your server and your client. You access your database from your server and let your server authenticate your users and validate that they have access to the application.
You can cheat and try to "hide" database credentials inside your client application, but that is security by obscurity and any one with some programming skills or similar can find out the credentials to the database and connect directly to the database.
I need to create an application that does the following:
The application is going to be installed on multiple computers on the same network
There is going to be a computer that contains the database other computers will connect to that database. (So there is a server version of the software and a client version)
All the computers that have the application installed should be able to do CRUD (create, read,...) operations in the database.
Database will be small, that is it should be less than 1GB in size.
Problems that I have:
I don't know which database to use:
SQLite - From researching on the internet this seems like a great database. It is fast, very easy to deploy . The problem is that from researching I think it is not that good handling multiple connections. When I say multiple I mean 5 computers using the database simultaneously.
MySQL - I work with this database and I know it is great handling multiple connections. The problem with that database is that I don't know how I will be able to deploy that database. I am required to deploy a database when installing the software. I know that if I require the users to instal MySQL doing a separate installation that will work. Maybe there is a way of deploying MySQL when doploying a project in visual studio.
SQL Server Express - I believe this will be my best option. I have researched on the internet and I found out that it is possible to deploy a SQL Server Express database with a application. I believe it will be easy to figure out how to deploy such database with a project but it will be nice if someone can point me on the right direction on how to connect to that database remotely from a computer on the same network. The database will obviously be shared in the network in order to achieve this.
Microsoft Access Database - I never use this database. I know it can handle multiple connections. Maybe it is a good choice.
It will be nice if someone can point me on the right direction of how to be able to deploy a database when installing my application. Moreover how will I be able to connect to that database from a computer remotely on the same network. Since the database is small and it will just contain text I think that the best idea will be to keep the database on the internet but I cannot do that. The software is required to work without an internet connection.
EDIT
From looking at your answers it looks like I have to install SQL Server express or MySql on the server computer. The problem is that I am required to do one installation. Is there a way of deploying MySql or SQL Server Express when deploying my application. Perhaps I have to embed mysql in the application and make my application install it somehow. My boss want to be able to install the software without having a internet connection.
EDIT 2
I been thinking and this part will be very hard to implement. Do you guys have any ideas how QuickBooks implement their database? I guess I need something similar. When you install Quickbooks you perform just one installation. Quick-books handles pretty well simultaneous connections. Do they use their own database? Oracle? MySQL? I agree with all of you. It will be so easy to perform two installations. Also it will be cleaner. The software that I am creating is supposed to run on windows xp, and latter versions of windows.
If you want a dbms as your backend you are installing two things, It could look to the user like one thing, but I can tell you from bitter experience, that can be a lot of fun.
For instance to install 2005/ 2008 express, there are various prerequisites. Like a .net framework. Then there's patches and updates, then opening up the firewall(s), depends on set up. Different topology / os choices. Peer to peer, domain based, Active directory, Terminal Services, citrix.
So automagically installing without an internet connection, and using the installer for the db, is nigh on impossible, unless you have rigid control over the user environments.
Welcome to a world of hurt.
Oh did I mention permissions, shares, UAC, 32/64 bit (for sql server dmo and smo, maybe)
Do you want to block installs on "incompatible" environments.
Oh and what about upgrades. To the db, to your apps.
What if your client already has a server install and doesn't want to clutter up their kit with another...
and many many more.
And I bet you just can't wait to test all the potential combinations.
You haven't said what your target environments are going to be, so I can't say how many worms are in the tin, but its's very big time with plenty of room for lots of worms.
Ours is a long running legacy app, so we are pretty much snookered, I'd never willingly start with this design again though. Locally deployed web app would take a lot of the pain out of it.
Go back and scare the crap out of your boss.
I would recommend Sql Server Express installed on a server on your network.
Microsoft Access doesn't handle multiple simultaneous connections very well and is not very efficient when accessed from a remote machine.
You don't need to worry about deploying the database with your client application, you can install Sql Server Express directly on the server. (This only needs to be done once). You will need to configure Sql Server Express to accept remote connections after it is installed on the server.
SQLexpress supports multiple connections. So if you attach database on "server" computer you can than connect from clients same way as you would to local database.(provided those computers are in LAN or VPN).
Several articles on the Internet mention that SQLite is not that good handling multiple connections if all the connections are writing to the same database. I finally managed to deploy my application with SQL Server 2008 express. I also deployed my application with SQLite (downloaded the latest version for .NET framework 4). Since I plan to use this database just on a local network (LAN) I gave SQLite a try. I was impressed on how efficient SQLite was. I tested the Database by connecting with 4 computers symoltaniously and constantly writing data (inserts) to the database. No data was lost. When I did this with SQL express it was also very efficient and I could not tell a obvious difference. Maybe you get to see a real difference once there are 50 computers connected like on a web server for example.
Other nice things about SQLite are that it does not take time to deploy. Also there are no heavy services constantly running. I guess that SQLite is a better choice than SQL express. Moreover SQLexpress will only use 1 CPU and the database is limited to 2GB.
I am going to mist the Linq to SQL classes thought. They where very easy to implement with SQL Server Express. So in short I think that every database is good at something. And in this scenario I guess SQLite was a better option for me and for the users.
P.S.
I am interested in seeing how SQLite lattest version will hanle multiple connections compared to SQLexpress. I will try to test soon with more computers and each computer running multiple threads, each thread performing an insert in the database. maybe I,ll see a big difference with that scenario.
I have a few ASP.Net database front-end websites where MS Access is the back-end. I am trying to use ASP.Net dynamic data website. Should I change this database to SQL Server Express or something else to make it easier or should this work from with MS Access.
Pick SQL Express for these reasons:
Scaling: MS Access will never scale. Once you get over about 10 concurrent connections you will start to see trouble. SQL Express will scale. You can always move SQL Express up to a full-blow SQL Server installation. While this is somewhat true of Access, some of your SQL statements and data types may not transfer cleanly.
Security: SQL Server has a much better security model than Access. You can lock down the schema in your db per user. You can also better administrate user access (think dev user vs test user vs production user).
Performance: This is similar to scaling. If you see a traffic spike to your web site, Access may not handle it while SQL Server Express probably will.
Tools: Tools and libraries like LINQ are always going to be targeted at SQL Server. You will get better support and better documentation using them this way.
A Jet back end will work fine for mostly read-only websites, even ones with decent traffic. Michael Kaplan's old website, http://trigeminal.com, uses a Jet database as the back end, and back when it was his primary site (he's since been hired by Microsoft), he said it was getting over 100K hits per day, and was holding up just fine.
For read/write operations, Jet will begin to bog down on a website about the same place it would bog down in a multi-user LAN application, at somewhere between 20 and 50 simultaneous connections, depending on your app's design.
For what it's worth, even though I'm a professional Access developer and know Jet very, very well, I don't use Jet as a back end for any of my websites. That's not so much because I don't like Jet for websites, but because I don't like Windows for a web server -- I'm an Apache supporter (and PHP developer), and host all my websites (and my clients' as well) on non-Windows hosting services (presently all of them are Linux, but that wasn't always the case). All the website databases I have ever done use MySQL for the back end.
In short, find out what your host offers in terms of database back ends and choose the best one. I can't imagine a host that provides ASP.NET that would not offer SQL Server, and that's definitely what I'd go with in that situation. It would be easy enough to upsize your Jet back end to SQL Server on your local PC, and then do a backup that you could import to your website.
You can use LINQ to DataSets to use Linq against an Access .mdb or .accdb database.
You can read more at http://msdn.microsoft.com/en-us/library/bb386977.aspx and http://blogs.msdn.com/adonet/archive/2007/01/26/querying-datasets-introduction-to-linq-to-dataset.aspx