CRUD

CRUD stands for the four fundamental database operations that any database should provide: Create, Read, Update, and Delete. If you read database articles and discussions on the web, you will often see people tossing around the term CRUD. (They may be using the term just to sound edgy and cool. Now that you know the term, you can sound cool, too!)

You can imagine some specialized data-gathering devices that don't support all these methods. For example, an airplane's black-box flight data recorders record flight information and later play it back without allowing you to modify the data. In general, however, if it doesn't have CRUD, it's not a database.

CRUD is more a general feature of databases than it is a feature of good database design. However, a good database design provides CRUD efficiently. For example, suppose you design a database to track times for your canuggling league (look it up online and don't let autocorrect send you to definitions of “snuggling”), and you require that the addresses for participants include a State value that is present in the States table. When you create a new record (the C in CRUD), the database must validate the new State entry (so no one enters “confusion” as their state, even if it is true). Similarly, when you update a record (the U in CRUD), the database must validate the modified State entry. When you delete an entry in the States table (the D in CRUD), the database must verify that no Participant records use that state. Finally, when you read data (the R in CRUD), the database design determines whether you find the data you want in seconds, hours, or not at all.

Many of the concepts described in the following sections relate to CRUD operations.

Retrieval

Retrieval is another word for “read,” the R in CRUD. (Happily “retrieval” also starts with R, so you don't need to memorize a new acronym.) Your database should allow you to find every piece of data. There's no point putting something in the database if there's no way to retrieve it later. (That would be a “data black hole,” not a database.)

The database should allow you to structure the data so that you can find particular pieces of data in one or more specific ways. For example, you should be able to find a customer's billing record by searching for customer name or customer ID.

Ideally the database will also allow you to structure the data so that it is relatively quick and easy to fetch data in a particular manner.

For example, suppose you want to see where your customers live so you can decide whether you should start a delivery service in a new city. To obtain this information, it would be helpful to be able to find customers based on their addresses. Ideally you could optimize the database structure so that you can quickly search for customers by address.

In contrast, you probably don't need to search for customers by their middle name too frequently. (Imagine a customer calling you and saying, “Can you look up my record? I don't remember if I paid my bill last month. I also don't remember my account number or my last name but my middle name is ‘Konfused.’”) It would be nice if the common search by address was faster than the rare search by middle name.

Being able to find all of the data in the database quickly and reliably is an important part of database design. Finding the data that you need in a poorly designed database can take hours or days instead of mere seconds.

Consistency

Another aspect of the R in CRUD is consistency. (The fact that “consistency” and CRUD both start with a C is purely coincidental. Don't get too excited.) A database should provide consistent results. If you perform the same search twice in a row, you should get the same results. Another user who performs the same search should also get the same results. (Of course, this assumes that the underlying data hasn't changed in the meantime. You can't expect your net worth query to return the same results every day when stock prices fluctuate wildly.)

A well-built database product can ensure that the exact same query returns the same result, but the design also plays an important role. If the database is poorly designed, you might be able to store conflicting data in different parts of the database. For example, you might be able to store one set of contact information in a customer's order and a different set of information in the main customer record. Later, if you need to contact the customer with a question about the order, which contact information should you use?

Validity

Validity is closely related to the idea of consistency. Consistency means different parts of the database don't hold contradictory views of the same information. Validity means data is checked where possible against other pieces of data in the database. In CRUD terms, data can be validated when a record is created, updated, or deleted.

Just like physical data containers, a computerized database can hold incomplete, incorrect, or contradictory data. You can never protect a database from users who can't spell or who just plain enter the wrong information, but a good database design can help prevent some kinds of errors that a physical database cannot prevent.

For example, the database can easily verify that data has the correct type. If the user sees a Date field and enters “No thanks, I'm married,” the database can tell that this is not a valid date format and can refuse to accept the value. Similarly, it can tell that “Old” is not a valid Age, “Lots” is not a valid Quantity, and 3 is not a valid PhoneNumber.

The database can also verify that a value entered by the user is present in another part of the database. For example, a poor typist trying to enter CO in a State field might type CP instead. The database can check a list of valid states and refuse to accept the data when it doesn't find CP listed. The user interface could also make the user pick the state from a drop-down list and avoid this problem, but the database should still protect itself against invalid data wherever possible.

The database can also check some kinds of constraints. Suppose the database contains a book-ordering system. When the customer orders 500 copies of this book (who wouldn't want that many copies?), the database can check another part of the database to see if that many copies are available (most bookstores carry only a few copies of any given book) and suggest that the customer backorder the copies if there aren't enough.

A good database design also helps protect the database against incorrect changes. Suppose you run a high-end coffee delivery service called the Brew Crew, and you've decided to drop coverage for a nearby city. When you try to remove that city from your list of valid locations, the database can tell you if you have existing customers in that city. Depending on the database's design, it could refuse to allow you to remove the city until you have apologized to those customers and removed them from the database.

All these techniques rely on a good, solid database design. They still can't protect you from a user who types first names in the last name field or who keeps accidentally bumping THE CAPS LOCK KEY, but it can prevent many types of errors that a paper and cardboard notebook can't.

Easy Error Correction

Even a perfectly designed database cannot ensure perfect validity. How can the database know that a customer's name is supposed to be spelled Pheidaux, not Fido as typed by your order entry clerk?

Correcting a single error in a notebook is fairly easy. Simply cross out the wrong value and write in the new one.

Correcting systematic errors in a notebook is a lot harder. Suppose you hire a summer intern to go door-to-door selling household products and he writes up a lot of orders for “duck tape” not realizing that the actual product is “duct tape.” Fixing all the mistakes could be tedious and time consuming. (Of course tedious and time-consuming jobs are what summer interns are for, so you could make him fix them.) You could just ignore the problem and leave the orders misspelled, but then how would you tell when a customer really wants to tape a duck?

In a computerized database, this sort of correction is trivial. A simple database command can update every occurrence of the product name “duck tape” throughout the whole system. (In fact, this kind of fix is sometimes too easy to make. If you aren't careful, you may accidentally change the names of every product to “duct tape.” You can prevent this by building a safe user interface for the database or by being really, really careful.)

Easy correction of errors is a built-in feature of computerized databases, but to get the best advantage from this feature you need a good design. If order information is contained in a free-formatted text section, the database will have trouble fixing typos. If you put the product name in a separate field, the database can make this change easily.

Although easy corrections are almost free, you need to do a little design work to make them as efficiently and effectively as possible.

Speed

An important aspect of all of the CRUD components is speed. A well-designed database can create, read, update, and delete records quickly.

There's no denying that a computerized database is a lot faster than a notebook or a filing cabinet. Instead of processing dozens of records per hour, a computerized database can process dozens or hundreds per second. (I once worked with a billing center that processed around 3 million accounts every three days.)

Good design plays a critical role in database efficiency. A poorly organized database may still be faster than the paper equivalent, but it will be a lot slower than a well-designed database.

Not all changes to a database's design can produce dramatic results, but design definitely plays an important role in performance.

Atomic Transactions

Recall that an atomic transaction is a possibly complex series of actions that is considered as a single operation by those not involved directly in performing the transaction. If you transfer $100 from Alice's account to Bob's account, no one else can see the database while it is in an intermediate state where the money has been removed from Alice's account and not yet added to Bob's.

The transaction either happens completely or none of its pieces happen—it cannot happen halfway.

Atomic transactions are important for maintaining consistency and validity, and are thus important for the R and U parts of CRUD.

Physical data containers like notebooks support atomic transactions because typically only one person at a time can use them. Unless you're distracted and wander off to lunch halfway through, you can finish a series of operations before you let someone else have a turn at the notebook.

Some of the most primitive kinds of electronic databases, such as flat files and XML files (which are described later in this book), don't intrinsically support atomic transactions, but the more advanced relational database products do. Those databases allow you to start a transaction and perform a series of operations. You can then either commit the transaction to make the changes permanent or roll back the transaction to undo them all and restore the database to the state it had before you started the transaction.

These databases also automatically roll back any transaction that is open when the database halts unexpectedly. For example, suppose you start a transaction, take $100 from Alice's account, and then your company's mascot (a miniature horse) walks through the computer room, steps on a power strip, and kills the power to your main computer. When you restart the database (after sending the mascot to the HR department for a stern lecture), it automatically rolls the transaction back so that Alice gets her money back. You'll need to try the transaction again, but at least no money has been lost by the system.

Atomic transactions are more a matter of properly using database features rather than database design. If you pick a reasonably advanced database product and use transactions properly, you gain their benefits. If you decide to use flat files to store your data, you'll need to implement transactions yourself.

ACID

This section provides some more detail about the transactions described in the previous section rather than discussing a new feature of physical data containers and computerized databases.

ACID is an acronym describing four features that an effective transaction system should provide. ACID stands for Atomicity, Consistency, Isolation, and Durability.

Atomicity means transactions are atomic. The operations in a transaction either all happen or none of them happen.

Consistency means the transaction ensures that the database is in a consistent state before and after the transaction. In other words, if the operations within the transaction would violate the database's rules, the transaction is rolled back. For example, suppose the database's rules say an account cannot make a payment that would result in a balance less than $0. Also, suppose that Alice's account holds only $75. You start a transaction, add $100 to Bob's account, and then try to remove $100 from Alice's. That would put Alice $25 below $0, violating the database's rules, so the transaction is canceled and we all try to forget that this ugly incident ever occurred. (Actually, we probably bill Alice an outrageous overdraft fee for writing a bad check.)

Isolation means the transaction isolates the details of the transaction from everyone except the person making the transaction. Suppose you start a transaction, remove $100 from Alice's account, and add $100 to Bob's account. Another person cannot peek at the database while you're in the middle of this process and see a state where neither Alice nor Bob has the $100. Anyone who looks in the database will see the $100 somewhere, either in Alice's account before the transaction or in Bob's account afterward.

In particular, two transactions operate in isolation and cannot interfere with each other. Suppose one transaction transfers $100 from Alice to Bob, and then a second transaction transfers $100 from Bob to Cindy. Logically one of these transactions occurs first and finishes before the other starts. For example, when the second transaction starts, it will not see the $100 missing from Alice's account unless it is already in Bob's account.

Durability means that once a transaction is committed, it will not disappear later. If the power fails, the effects of this transaction will still be there when the database restarts.

The durability requirement relies on the consistency rule. Consistency ensures that the transaction will not complete if it would leave the database in a state that violates the database's rules. Durability means that the database will not later decide that the transaction caused such a state and retroactively remove the transaction.

Once the transaction is committed, it is final.

BASE

Recently, some kinds of nonrelational, NoSQL databases have become increasingly popular, and they don't always satisfy the ACID rules. Their structure, plus the fact that they are often distributed across multiple servers, makes them behave differently. (We'll talk more about NoSQL databases a bit later. For now, just think of them as alternatives to relational databases.)

To better suit the asynchronous, distributed, sometimes in the cloud NoSQL lifestyle, these databases have their own feature acronym: BASE. (I'm sure this acronym was inspired partly by the fact that acids and bases are chemical opposites.)

BASE stands for Basically Available, Soft state, and Eventually consistent.

Basically Available means that the data is available. (It wouldn't be much of a database if you couldn't retrieve the data!) Relational databases spend a lot of effort requiring data to be immediately consistent (which is why you'll spend a fair amount of time studying normalization and other relational concepts later in this book). NoSQL databases spread their data across the database's clusters, so the data might not be immediately consistent. These databases do, however, guarantee that any query will return some sort of result, even if it's a failure (the electronic equivalent of a shrug).

Soft state means that the state of the data may change over time. Because these databases do not require immediate consistency, it may take a while for changes to filter through the entire system. Instead of enforcing consistency, these databases rely on the developer to provide whatever consistency is needed by the application.

Eventually consistent means that these databases do eventually become consistent, just not necessarily before the next time that you read the data (usually we're talking about seconds, not days).

We'll talk more about NoSQL databases in Chapter 3, “NoSQL Overview.”

NewSQL

NewSQL is a relatively new breed of relational database management system (RDBMS) that attempts to combine the ACID guarantees of traditional databases with the flexibility and scalability of NoSQL databases. These are particularly useful for high-volume online transaction processing (OLTP) systems where distributing the data can greatly improve performance.

One way to create a NewSQL database is to split the data into disjoint subsets called partitions or shards.

Persistence and Backups

The data must be persistent—it shouldn't change or disappear by itself. If you can't trust the database to keep the data safe, then the database is pretty much worthless.

Database products do their best to keep the data safe, and in normal operation you don't need to do much to get the benefit of data persistence. When something unusual happens, however, you may need to take special action and that requires prior planning. For example, suppose the disk drives holding the database simply break, a fire reduces the computer to a smoldering puddle of slag, or a user accidentally or intentionally deletes the database. (A user tried that once on a project I was working on. We were not amused!)

In these extreme cases, the database alone cannot help you. To protect against this sort of trouble, you need to perform regular backups.

Physical data containers like notebooks are generally hard to back up, so it's hard to protect them against damage. If a fire burns up your accounts receivable notebook, you'll have to rely on your customers' honesty in paying what they owe you. Even though we like customers, I'm not sure most businesses trust them to that extent.

In theory, you could make copies of a notebook and store them in separate locations to protect against these sorts of accidents, but in practice few legit businesses do (except perhaps money laundering, smuggling, and other shady endeavors where it's handy to show law enforcement officials one set of books and the “shareholders” another).

Computerized databases, however, are relatively easy to back up. If the loss of a little data won't hurt you too badly, you can back up the database daily. If fire, a computer virus, or some other accident destroys the main database, you can reload the backup and be ready to resume operation in an hour or two.

If the database is very volatile or if losing even a little data could cause big problems (how much money do you think gets traded through the New York Stock Exchange during a busy hour?), then you need a different backup strategy. Many higher-end database products allow you to shadow every database operation as it occurs, so you always have a complete copy of everything that happens. If the main database is destroyed, you can be back in business within minutes. Some database architectures can switch to a backup database so quickly that the users don't even know it's happened.

Exactly how you implement database backups depends on several factors, such as how likely you think a problem will be, how quickly you need to recover from it, and how disastrous it would be to lose some data and spend time restoring from a backup. In any case, a computerized database gives you a lot more options than a notebook does.

Good database design can help make backups a bit easier. If you arrange the data so that changes occur in a fairly localized area, you can back up that area frequently and not waste time backing up data that changes only rarely.

Low Cost and Extensibility

Ideally, the database should be simple to obtain and install, inexpensive, and easily extensible. If you discover that you need to process a lot more data per day than you had expected, you should be able to somehow increase the database's capacity.

Although some database products are quite expensive, most have reasonable upgrade paths, which means you can buy the least expensive license that can handle your needs, at least in the beginning. For example, SQL Server, Oracle, and MySQL provide free editions that you can use to get started building small, single-user applications. They also provide more expensive editions that are suitable for very large applications with hundreds of users.

Similarly, many cloud databases have a free tier for smaller projects and more expensive options for larger groups. Their pricing can be fairly complicated and can involve such factors as the number of cores (the part of the computer that executes code) you get to use, the amount of memory available, the type of computer holding the data, the type of backups you want, and the number of database transaction units (DTUs) that you use per month. (DTUs are a weighted measure of CPU, memory, reads, and writes.)

Installing a database will never be as easy and inexpensive as buying a new notebook, but it also doesn't need to be a time-consuming financial nightmare.

Although expense and capacity are more features of the particular database product than database design, good design can help with a different kind of extensibility. Suppose you have been using a notebook database for a while and discover that you need to capture a new kind of information. Perhaps you decide that you need to track customers' dining habits so you know what restaurant gift certificate to give them on special occasions. In this case, it would be nice if you could add extra paper to the bottom of the pages in the notebook. Good database design can make that kind of extension possible.

Ease of Use

Notebooks and filing cabinets have simple user interfaces so almost anyone can use them effectively—although sometimes even they get messed up pretty badly. Should you file “United States Postal Service” under “United States?” “Postal Service?” “Snail Mail?”

A computer application's user interface determines how usable it is by average users. User interface design is not a part of database design, so you might wonder why ease of use is mentioned here.

The first-level users of a database are often programmers and relatively sophisticated database users who understand how to navigate through a database. A good database design makes the database much more accessible to those users. Just by looking at the names of the tables, fields, and other database entities that organize the data, this type of user should be able to figure out how different pieces of data go together and how to use them to retrieve the data they need. If those sophisticated users can easily understand the database, then they can build better user interfaces for the less advanced users to come.

Portability

A computerized database allows for a portability that is even more powerful than the portability of a notebook. It allows you to access the data from anywhere that you have access to the web without actually moving the physical database. You can access the database from just about anywhere, while the data itself remains safely at home, far from the dangers of pickpockets, being dropped in a puddle, and getting forgotten on the bus.

Unfortunately, the new kind of portability may be a little too easy. Although someone in the seat behind you on the airplane can't peek over your shoulder to read computerized data the way they can a notebook (well, maybe they can if you're using your laptop in airplane mode), a hacker located on the other side of the planet may try to sneak into your database and rifle through your secret cookie recipes while you're asleep.

This leads to the next topic: security.

Security

A notebook is relatively easy to lose or steal, but a highly portable database can be even easier to compromise. If you can access your database from all over the world, then so can cyber-banditos and other ne'er-do-wells.

Locking down your database is mostly a security issue that you should address by using the security tools provided by your network and database. However, there are some design techniques that you can use to make securing the database easier.

If you separate the data into categories that different types of users need to manipulate, then you can grant different levels of permission to the different kinds of users. Giving users access to only the data they absolutely need not only reduces the chance of a legitimate user doing something stupid or improper, but also decreases the chance that an attacker can pose as that user and do something malicious. Even if Clueless Carl won't mistreat your data intentionally, an online attacker might be able to guess Carl's password (which naturally is “Carl”) and try to wreak havoc. If Carl doesn't have permission to trash the accounting data, then neither does the cyber-mugger.

Yet another novel aspect to database security is the fact that users can access the database remotely without holding a copy of the database locally. You can use your laptop or phablet to access a database without storing the data on your computer. That means if you do somehow lose your computer, the data may still be safe on the database server.

This is more an application architecture issue than a database design issue (don't store the data locally on laptops), but using a database design that restricts users' access to what they really need to know can help.

Sharing

It's not easy to share a notebook or a box full of business cards among many people. Two people can't really use a notebook at the same time, and there's some overhead in shipping the notebook back and forth among users. Taking time to walk across the room a dozen times a day would be annoying; express mailing a notebook across the country every day would be just plain silly.

Modern networks can let hundreds or even thousands of users access the same database at the same time from locations scattered across the globe. Although this is largely an exercise in networking and the tools provided by a particular database product, some design issues come into play. (And don't forget what I said earlier about data residency and data sovereignty.)

If you compartmentalize the data into categories that different types of users need to use as described in the previous section, this not only aids with security, but also helps reduce the amount of data that must be shipped across the network.

Breaking the data into reasonable pieces can also aid in coordination among multiple users. When your coworker in London starts editing a customer's record, that record must be locked so that other users can't sneak in and mess up the record before the edit is finished. Grouping the data appropriately lets you lock the smallest amount of data possible, which makes more data available for other users to edit.

Careful design can allow the database to perform some calculations on the server and send only the results to your boss (who's working hard on the beaches of Hawaii) instead of shipping the whole database out there and making the boss's computer do all of the work.

Good application design is also important. Even after you prepare the database for efficient use, the application still needs to use it properly. But without a good database design, these techniques aren't possible.

Ability to Perform Complex Calculations

Compared to the human brain, computers are idiots. It takes seriously powerful hardware and frighteningly sophisticated algorithms to perform tasks that you take for granted, such as recognizing faces, speaker-independent speech recognition, and handwriting recognition (although neither the human brain nor computers have yet deciphered doctors' prescriptions). The human brain is also self-programming, so it can learn new tasks flexibly and relatively quickly.

Although a computer lacks the adaptability of the human brain, it is great at performing a series of well-defined tasks quickly, repeatedly, and reliably. A computer doesn't get bored, let its attention wander, or make simple arithmetic mistakes (unless it suffers from the Pentium FDIV bug, the f00f bug, the Cyrix coma bug, or a few others). The point is, if the underlying hardware and software work correctly, the computer can perform the same tasks again and again millions of times per second without making mistakes.

When it comes to balancing checkbooks, searching for accounts with balances less than $0, and performing a host of other number-crunching tasks, the computer is much faster and less error-prone than a human brain.

The computer is naturally faster at these sorts of calculations, but even its blazing speed won't help you if your database is poorly designed. A good design can make the difference between finding the data you need in seconds rather than hours, days, or not at all.

CAP Theorem

The CAP theorem (also called Brewer's theorem after computer scientist Eric Brewer, who devised it) says that any distributed data store can only provide two of the following reliably:

• Consistency—Every read receives the most recently written data (or an error).
• Availability—Every read receives a non-error response, if you don't guarantee that it receives the most recently written data.
• Partition tolerance—The data store continues to work even if messages are dropped or delayed by the network between the store's partitions.

When a partition failure occurs, you need to decide whether to either (a) cancel the operation (and reduce availability), or (b) have the operation continue (but risk inconsistency).

Basically all of this says that network errors or tardiness can make the data temporarily unavailable, or you can use the most recent value to which you have access.

Brewer noted that you only need to sacrifice consistency or availability if the data store is partitioned. If the data is all stored in one place, then you should be able to achieve both consistency and availability.

Cloud Considerations

A cloud database hosts data in the cloud so it is accessible over a network. There are two common cloud deployment models. First, you can rent space on a virtual machine and run the database there. A virtual machine (VM) is a simulation of a physical computer running on a server somewhere.

Virtual machines have the advantage that the cloud provider can move them around, possibly hosting multiple VMs on a single physical machine. Conversely, you may also be able to use multiple computers to host a single VM. Those two capabilities together make it easier to scale an application up or down as needed.

For example, suppose you write some software to schedule appointments for nail salons. Initially you serve only a few salons, so your VM uses a small fraction of one physical server. Over time, as more and more salons sign up for your service, you need more space and faster processing, so you start using more of the server. Soon your provider moves you onto faster hardware and eventually onto a small group of servers (for a price, of course).

A second way to build a cloud database is to rent a database from a cloud database provider. This has the same advantages as the virtual machine, plus the database provider will maintain the database for you. For example, the provider may perform backups, guarantee a certain level of availability, and so forth (again, for a price).

In this scenario, the database is provided as a service (aaS). More precisely, it is considered a database as a service (DBaaS), which is a kind of software as a service (SaaS). (The phrase “as a service” is very in vogue lately.)

Note that you can create both relational and NoSQL databases in the cloud. You can also find some that are free as long as the database is relatively small. The provider hopes that your nail salon will become wildly successful and that you'll then share your success with them by renting larger virtual machines or databases.

Legal and Security Considerations

I won't talk too much about legal issues in this book, but you should determine whether you might encounter any of them. For example, I already mentioned data residency and data sovereignty earlier in this chapter. Some countries require that certain kinds of data reside physically within their borders, and you could be in big trouble if your data is stored in the cloud on foreign servers.

In addition to ensuring that your cloud servers have allowed physical locations, you need to ensure that your data is properly protected. For example, in the United States, HIPAA (which stands for the Health Insurance Portability and Accountability Act and is pronounced “hip-uh”) prohibits the disclosure of a patient's sensitive medical information without their consent or knowledge. I don't believe HIPAA requires data residency (but I'm not a lawyer, so don't take my word for it), but some states have their own special requirements. For example, all 50 U.S. states plus Washington D.C., Puerto Rico, and the U.S. Virgin Islands have some sort of law requiring you to notify residents if their personal information is compromised in a security breach.

Obviously sensitive information like credit card numbers, bank account numbers, Social Security numbers, driver's license numbers, website passwords, biometric data, business information, and other important items require top-notch security.

Certain other kinds of data are also considered personal and/or sensitive and may or may not be protected by law. Personally identifiable information (PII) is information that could be used to assist with identity theft and includes such items as a person's name, mother's maiden name, address and former addresses, phone numbers, and so on. Sensitive data may include gender identity, ethnic background, political or religious affiliation, union membership, and more.

When you're shopping for cloud databases, consider the kinds of data that you will store, whether it's subject to data residency requirements, and whether it needs more than the normal amount of protection. Then mercilessly grill your cloud provider to ensure that they can handle your needs.

If you don't think these aren't important issues, think again! Governments take these things very seriously. For example, here are a few of the larger fines levied against companies that didn't protect their data properly.

• Athens Orthopedic Clinic—$1.5 million HIPAA penalty
• CHSPSC LLC—$2.3 million HIPAA penalty and $5 million settlement for a 28-state legal action
• Google LLC—€60 million ($68 million) GDPR fine
• Facebook—€60 million ($68 million) GDPR fine
• Premera Blue Cross—$6.85 million HIPAA penalty, plus a multistate legal settlement for $10 million and a class action lawsuit for $74 million, for a total of over $90 million
• Google Ireland—€90 million ($102 million) GDPR fine
• Uber—$148 million for 600,000 driver and 57 million user accounts breached
• Capital One—$190 million to settle a class-action lawsuit over a breach that exposed the personal data of 100 million people
• Home Depot—$200 million paid to credit companies, banks, other financial institutions, and customers because attackers breached their system and compromised their point-of-sale system
• WhatsApp—€225 million ($255 million) GDPR fine
• Equifax—$575 million–$700 million for “failure to take reasonable steps to secure its network”
• Amazon—€746 million ($877 million) GDPR fine

Those dozen cases alone add up to more than $2.5 billion. You can find so many more examples by searching for “biggest data breach fines” that it's not funny. In fact, it's terrifying. Many of these fines were not levied because a company was being evil; they were mostly just being lazy (not following the rules) and careless (not properly securing their data).

So find out what your exposure is and take data security very seriously.

Consequences of Good and Bad Design

Table 1.1 summarizes how good and bad design can affect the features described in the previous sections.