Ask people to tell you words they associate with database and youll probably get big among the responses. Databases handle large amounts of data, and everyone knows that. How big? It depends whether you count the number of items in a database or the size of the items. The Library of Congress has 160 million items on 858 miles of shelving as of this writing. The catalog, which is based on a database, is available online at www.loc.gov/about/fascinating-facts/ . Theres no question among people who are interested in databases that the Library of Congress catalog is far from the largest database in the world. (In all likelihood, the largest databases are not visible to the public because they contain classified corporate and governmental information.)
This chapter provides an introduction or reminder about databases today and how they are used. If youve used databases in the past, much has changed, and if you havent used them much in the past, this chapter will give you a quick overview.
Moving Beyond Big
Beyond big , you should start thinking about databases as being structured and organized . In fact, as a mobile developer, the structured and organized aspects of databases are much more important than their size. From the earliest days of the Web in the early 1990s, web browsers have used databases to store and organize their data. What data, you may wonder? How do you think your browser is able to store your passwords for the web sites you visit? How do you think browsers store web pages in a cache so that they can be retrieved without a new network access when possible? And what about your preferences for default font sizes? Or the download folder for files you can change when you feel like it, and even, on many browsers, restrictions on certain users or types of users? These are just simple examples, but the principles apply even to the largest (and smallest) databases today.
Databases Are Structured and Organized
All those examples can be implemented with a database because all those items need to be structured and organized. Some of the items can turn into large amounts of data (particularly a browser history if you dont choose an option to clear out the old information occasionallyanother option that can be stored in a preference database), but some of the preferences listed are very small amounts of data: even with a fully modified file name for your download folder, 128 characters is enough to store that data element. Furthermore, most browsers store the name of your preferred download folder, but they dont store the history of download folders (last weeks preferred download folder, the folder you used last month, etc.).
In thinking about databases, big is often relevant, but very frequently its misleading. It is structure and organization that matter most.
And they matter a great deal to a mobile developer.
Precisely because mobile devices need to function in a world of constrained resources (e.g., limited storage space and battery power), structuring and organizing the data that is stored is particularly important. Built into a data management system are various optimizations that matter to databases large and small. For example, many databases can store character or string data. Such data is typically quite variable. Even if a database designer specifies that a text field can contain 50, 500, or 50,000 characters, behind the scenes trailing blanks are often discarded. The user (and even the developer) may never know this, but it makes the entire database function more efficiently. (Features like this function behind the scenes and they can be accessed and turned on or off by the database designer in many cases.)
Databases Are Smart
Being able to optimize storage to work with the presence or absence of characters in a text field is a powerful behind-the-scenes tool, but databases have intelligence built into them.
In most database engines today, the designer can specify many attributes of a field such as the following:
Name . A name that is used internally is often quite different from the name that appears in the user interface.
Type . You can specify that a certain database field must be an integer or a string or any other type that the database supports.
Optionality . Some fields are optional, and you can specify that when you set up a database. (Many people have a car with a license number; many other people do not own cars.)
Default values . A database can be set to provide a default valueeither a simple value or a calculated value based on other data in the database.
Cardinality . Sometimes, there are multiple values for part of the database. (To continue the example, some people have no car, other people own a car, and others own several cars. Furthermore, some people own a car and a bike... you get the idea.)
Value ranges . When the database designer specifies the database structure, a range of values for each field can be set. A drivers license identifier that consists of characters other than letters and numbers (depending on the locality) may not be allowed.
Value relationships . You can move beyond value ranges in designing a database. You can create combinations of attributes and values so that, for example, a database can enforce a rule that an employee may be married (to one person or no one), but if the employee is married, the spouses employer cannot be the same as the employees employee. These restrictions in the database reflect policies, but there well may be exceptions (a supervisors approval), and the database can be designed to support a case like that.
These are just a few of the ways in which a database can be set up to enforce logical rules.
Perhaps at this point youre tempted to say, But I can do each of those things with a line or two of code. Thats absolutely true. But there are a couple of points to bear in mind.
Writing Code Is Just the Beginning
You can write the code to implement any of those conditions, but thats just the start. Over time, conditions change, users have suggestions, and the Power That Be (whoever that (or they) may be in your life) decides to change the rules for employment, cars, the conditions that apply to license plate numbers, or any other things that strike his or her fancy.
The code that took only a few lines of code and a couple of minutes to write needs to be rewritten. And, although there is no clear research on the matter, it seems that these changes take place at the last minute before a product (or version) launch and they must be done immediately.
Parlez-vous Python? Sprechen Sie Scala?
The line or two that implement the rules for one of the data conditions may have been written by someone whos no longer around. Even if you wrote them, time may have passed and you may not remember exactly what you were trying to implement (yes, commenting your code is a desirable feature, but life happens...)
Those few lines of code may have been modeled on some code from a friend that does exactly (or almost) what you want. Maintaining even the best-written code is a challenge for everyone involved from the first author to the updater to the manager andeventually the user or manager who asks for just a little tweak.