Editor’s Note: We continue our “Need to Know” series, where we explain complex web topics on an executive-level, “need to know” basis. For this installment, Contributing Editor Armando Roggio explains relational databases.
The “Need to Know” Series
- Five Web Design Concepts Ecommerce Merchants Need to Know
- Five Handy HTML Tags To Help Your Ecommerce Business
- Website Compatibility Testing Made Simple
- Image Formats: What’s the Difference Between JPG, GIF, PNG?
- What Is HTML 5?
In the context of the Internet, a modern relational database is a digital repository for storing variable information in such a way that it can be easily captured, retrieved, edited, and distributed.
While very few ecommerce entrepreneurs or marketers will need to design databases or even knowingly interact with them on a day-to-day basis, understanding how relational databases work can affect significant business decisions—like selecting shopping cart software or hiring one web developer over another.
This article will provide a non-technical description of how databases work and explain briefly how this knowledge might impact an online retail business.
How Relational Databases Are Organized
In a relational database, which is the kind used for most websites, information is organized into a series of tables (sometimes called files) that contain similar kinds of data in fields (sometimes called records).
As an example, imagine that an online merchant offers a free newsletter. When site visitors fill out an online form to register for that newsletter, three specific pieces of information are captured. These are the registrant’s first name, last name, and email address.
To store this information, the web developer probably created a database. Within that database a table, perhaps called newsletterregs was also created. And in all likelihood the newsletterregs table has four fields—to hold the three pieces of information described above and an identification number or key to use as a reference.
When the registrant submits the newsletter form the information is sorted and stored in the database table as a row.
As more potential customers register for the newsletter, more rows are added to the table.
With the registrant information stored in this way, it is easy to make a list of email addresses or a list of registrant names based on the stored data.
When the data is first added to the table it is “captured.” If I query the database to get a list of email addresses, I am retrieving or selecting information. Once selected, the list of email addresses could be distributed to various applications. If the merchant allowed newsletter registrants to update their records, say changing an email address, that change would edit or update the table.
Data Lives Here
All of the important information about an ecommerce site, including product descriptions, customer information, tax rules, customer reviews, inventory levels, and more, is stored in a database, using tables just like those described above.
This is an important distinction because storeowners and marketers often think of information as being stored by an ecommerce platform, like Volusion, Shopify, Miva Merchant, or Magento. But in truth, those platforms all store information in a database, querying that database each time a page is rendered or a transaction is initiated.
Server-Side Scripting and Databases
These scripts dynamically generate each page of your website. When some piece of information is required, the script communicates with the database using a database language.
While only developers need to worry about a database language, it is helpful to know that the most common database language for the web is SQL. This term is officially pronounced S-Q-L, but many, if not most, developers refer to it as sequel, which was how its original acronym SEQL (Structured English Querying Language) was said.
When one realizes that essentially every ecommerce platform and, for that matter, every payment processor is employing some form of a relational database to store customer, product, and transactional information, it becomes pretty clear that you ought to be able to distribute, reuse, or just plain move that information.
If your ecommerce platform has stored a customer’s email address, and you have prior permission, you ought to be able to pass that information, via a server-side script, to an email marketing tool.
Likewise, if you decide to move your store from eBay’s ProStores to Lemonstand, for example, you should be able to retrieve the information from one database and simply hand it over to another.
Knowing how your data is stored has, in my opinion, several clear implications. Specifically, you should feel much more comfortable asking for information or moving that information around.
This implies that multi-channel merchants should be able to share inventory data from their physical store with online platforms. Or it suggests that your accounting software, which uses databases, ought to be able to get at your online sales records.
Even more fundamentally, when you are selecting a shopping cart or a payment gateway solution, you should ask how you gain access to your data and how you take your data with you should you decide to change vendors.
More examples might include making a choice between a software-as-a-service model or licensing (buying) the software. In the former, you may not have access to your database and, therefore, to all of your information, when and how you want it. In the later, you most certainly will have access.
Database architecture, which can be thought of as how tables and fields are organized, can have an effect on site performance, so that database optimization might be something to ask your developer about.
Databases are the Internet’s filing cabinet. They store all of the data related to your store, customers, and transactions. While you may never need to query a database yourself, just knowing they are out there might help you make better decisions.