Start by thinking about your data: what is it? how is it related to other pieces of data?
For example, a customer may have a name and address, and a company will hopefully have more than one customer. That means you would need a Customers table which stores:
ID (so that you can have two customers with the same name)
Street line 1
Street line 2
County / State
And each Customer would have their own row in the same table.
But for Invoices, it's different; each invoice has a customer, a date, a total, and a set of products - which means three tables: the Customers from before, the Invoices, and the InvoiceLines tables:
ID (To makes sure they are all distinct)
CustomerID (so you can tell which customer owes you money)
ID (so they are all different)
InvoiceID (so you can tie the set of lines back to an Invoice)
Databases are all about the relationships between data, and you only separate items into different tables when there is good reason to do so - most often when you will have "many of these" associated with "one of these": "Many orders" from "the same customer" for example.
So start by thinking about the data, and how it is organised in the real world - then think about how to create a database model of that world!
Then start thinking about actual databases! :laugh: