I've tried to motivate myself to learn databases several times now, but I'm having a hard time seeing where they're used. I don't do any web development nor any scientific computing, so is there anyplace where I could reasonably use a database?
Um, well, most any kind of administrative business support, f'rinstance?
Build a simple web-based Contact manager that stores names, email addresses, phone numbers etc. That would get you familiar with the mechanics of using a database without getting crazy complicated.
Where do you think the questions and answers in SO ar stored? Where do you think your user details are stored?
Build a small application for your personal use.
For a light weight but real-world example, you could start a blog using Wordpress. Wordpress uses MySQL to store all the related information.
A better way to learn though would be to download a free DB and follow along the tutorials. Here is a free version of Oracle 10g known as Express Edition.
Even in desktop software, you need to store, organize, search and retreive data. Did you ever need to save several record of the same type in your programming ?
Databases are for storing data. If you application needs to store date in some way, or retrieve it from a central location, then you would generally use a database.
If you are currently storing your data in a flat file, you are losing all the benefits of the structure of a database. RDBMS (relational database management systems) help you structure your data to prevent redundancy (duplicate data), ensure data integrity and account for scalability. They can also help with allowing multiple users to access the data while avoiding corruption. Most RDBMS also provide some form of transactional access. This means that you can group operations up into logical transactions that must either be fully successful, or fail without changing any data. This is really helpful if you want to update various parts of your data, and it's important they remain in sync. If you were to use a flat file and the sysytem crashed in the middle of you updating the file you would be left with invalid/out of sync data. With an RDBMS no change would be made until the transaction as a whole completed successfully.
At a simple level, you could describe almost any data storage mechanism as a database. Whatever you are currently storing information is could be described as a database. The question is, would your data storage benefit from the extra services provided by a traditional RDBMS.
In my applications I will often use flat/xml files to store basic config information, but anything complex or multi user goes straight in a database, even if it's a local SQL Express database file.
Databases (I'm guessing you're talking about relational DBs) will be useful when you have to store data in a STRUCTURED way, having relations between elements stored and kept on disk.
The idea is that you'll be able to manipulate this data while keeping things CONSISTENT.
- How would you process a 1 Tb data set made of : menus <--> dishes <--> ingredients ?
- How will you remove a dish from a given menu ?
- How to add simply a price to a menu without rewriting all your data and your code base ?
- All this while keeping fast-paths on your data to be able not to read it all from disk to find menus more expensive than X ? (they're called index) ?
- All of this allowing two users to access (ie read, modify) the data concurrently ?
Some alternatives, such as storing an XML file (with a structure) or a memory dump on disk, or some kind of serialization will need you to load everything to memory, process it with structure and dump everything to disk to change your data while keeping it organized.
From there, you can use different databases, (relational in-memory or on disk, in process or not, document based such as couchdb, ...) with different scalability / simplicity tradeoffs, ranging from sqlite to Oracle/postgresql.
The approach I'd propose is to learn what a relational DB really is, understand it, play wit it a little bit (use sqlite) then try to understand how it might apply to a given problem.
Just understand that firefox browser bookmarks, iPhone data or the backend of most enterprise apps (booking tickets) are stored as a database ...
If you ever stored a list of things not number-related in excel and used some filters, well you should maybe have used a DB for this information.
Think of it this way. If you ever need to store data of any kind, then you have a need for a database of some kind.
I see that you are an embedded CS student, at least by your profile. I bet most of the projects you've worked on would have no practical use for a database, due to software/hardware limitations in many cases.
However, relational databases are being used on certain small/embedded platforms now. Check out SQLite, which is a small relational database engine written in C that is highly suited for embedded PC/PC-104 projects. This database is used on various embedded systems, including cell phones and MP3 players. A prominent embedded Linux proponent performed some research on the database and determined that it suitable for use in soft-realtime applications.
If you don't need persistence with strong integrity guarantees, powerful query capability or data management, you don't need a relational database management system and should not use it.
Get SQLite. It is fast, used lots of places, free, fast, and completely self-contained (i.e. no servers). And it has a command line program where you can experiment without messing anything up.
I used to think that db'ing wasn't something I wanted to mess with either. But it's a damn fine skill to have, and with all of the resources on the internet, it's pretty easy to learn.
Want to save program state (and restore it)? A little database is perfect. Want to pass around some intermediate results? An in-memory database will handle it nicely.
I have seen situations where a database drove a whole software system. Obviously, the core system was in language X (where X is your favourite language), but the steps to run it were in a database, and the driver for the program involved reading the steps from the database, parsing them, and calling the appropriate functions (internally). So to change how your program operates, you just supply a new database. Pretty sweet, if you can plan things well.
As a well organized way to store and retrieve data, a database is hard to beat.
Plus, knowing SQL is a sure way to get the ladies!
Spreadsheets have two popular uses: The one they were designed for, which is running calculations on numeric data, and the other one, which is standing in for a database application.
If you or your team uses a spreadsheet for non-numeric data, and if the spreadsheet is wider and deeper than you'd prefer ... or seems inadequate in meeting the intended need (making decisions, learning status, etc) ... or isn't secure against tampering, or doesn't allow collaborative editing when that's needed ... or won't publish the results in helpful formats for varied purposes ...
-- then you might have a reason to use a database.