The Black Ink Team’s Guide To How Relational Databases Are Structured
by Black Ink Team
This article will let you peek behind the curtain, as it were, into how SaaS companies (such as Black Ink Technologies) organize your data for you, make it simple for you to quickly conduct powerful research, and ensure that none of your data becomes disorganized or lost. Get ready, Dorothy, because we’re about to be leaving Kansas.
A relational database is a stratified collection of tables – not four-legged ones, the grid kind – that each contain an isolated type of information. In a CRM database, one table might contain customer names, while another may contain product SKUs. On their own, you don’t usually get much out of one table, but together, the tables all provide a wholistic view; software however is required to tie everything together.
Here are examples of two tables you might find in a rudimentary CRM database (trust us; ours are by orders of magnitude fancier):
Table 1: Customers | |
---|---|
customer_ID | customer_name |
1 | Alex |
2 | Gerulf |
3 | Alina |
Table 2: Sales | ||||
---|---|---|---|---|
sale_ID | customer_ID | product_ID | product_count | timestamp |
1 | 2 | 001 | 1 | mm/dd/yyyy |
2 | 3 | 002 | 5 | mm/dd/yyyy |
3 | 1 | 003 | 10 | mm/dd/yyyy |
4 | 1 | 004 | 100 | mm/dd/yyyy |
The first column in a table for a relational database always contains a unique identifier – a code which signifies to the software looking at the table what everything in a row (or ‘tuple’) means. For these two tables, for instance, you can see that the column header ‘customer_ID’ was used twice. That means that given both of these tables a piece of software could automatically replace the information found under that header in the second table with information correlating to the unique identifiers found in the first table.
Say you were playing a game of Scrabble, but not just an ordinary game of Scrabble – it was the game of Scrabble of the ages. You as scorekeeper now must not only keep track of how many points each player got in a turn, but also what words they played, what multipliers they landed on, and how many seconds they took to decide. All that information is too much for one sheet of paper – you would need multiple sheets of paper to keep track, to make separate lists of scores, words, and seconds on, then at the end of the game you would need to match those lists together.
That’s what a relational database is. It’s a formulaic way of breaking down a large amount of information into separate parts which are easier to keep track of. The ‘lingua franca’ when it comes to databases is SQL, which stands for ‘Standard Query Language.’ Using SQL is like saying to your database ‘give me this information where this equals this, this equals this, and this is greater than this’ – a joke which you would get if you were a software engineer.
When you want your sales team to become all-stars, you need to give them a lot of information – customer information, product information, market information, financial information, schedules, and more. Furthermore, you need to give them a way of making and keeping track of their own information, in addition to a way of sharing it. An industry-specific CRM with a well-structured database is definitely the way to go.