The internet is full of tutorial, examples, and answers to questions, but it’s very hard to find a complete applications built step by step. I’ve not found any, in any case, so I thought it would be fun and satisfying and perhaps even helpful to document building a complete application, step by step — sort of like how you can watch videos on YouTube of people building homes step by step.
I’ll clarify up front that I’m not a professional programmer. But I got my first computer in 1980, a TRS-80, and quickly learned BASIC and Z-80 assembly. I’ve been hooked ever since on the idea of making computers help us solve problems. I’ve used almost a dozen languages, including specialized ones that worked only under one narrow platform, and some of my software has been used in real business settings. I’ve read a lot about software development and try to follow best practices, but I’m still learning. This here is really a learning project for me. If we learn together, fantastic!
So then, who are you? I expect you will be someone who already knows the basics of programming and databases. You should know about loops and if-thens. Regarding databases, you should know the basics of normalization. You should know about primary keys, foreign keys, and lookup tables. You should know about queries, and you should know the basics of the SQL language. Did I mention foreign keys? You should know why, in the record of an invoice, we don’t enter the client’s name and address but instead just enter the client’s record ID, which “points” to a record or row in the Clients table. If you know this, we’re on the same page. If you don’t, I welcome you nonetheless, but you will do yourself a favor by reading up on the basics of database normalization and design. Just get familiar.
What kind of application will we build? I propose we build a billing system, one of the oldest tasks assigned to computers. Actually, the oldest tasks assigned to computers was bombing and artillery targeting, but right after the war, we got billing. Everybody needs to get paid, after all. So let’s suppose we’re some kind of consulting company. We don’t have any products to sell. We only bill our services, and we pass along expenses we incur on behalf of our clients.
Let’s brainstorm some features this system will have.
- Display a list of clients, narrowed down by search criteria.
- Display the invoices for any client.
- Enter transactions into client invoices.
- Display invoices and invoice detail lines in their own right, narrowed down by search criteria.
- Produce accounting reports.
Here’s a conceptual diagram of our database. The arrows indicate the 1:M direction. Thus, we have that each client can have multiple invoices, but each invoice can belong to only one client. Similarly, each invoice can have multiple line items. Further, each user could create multiple invoice line items, and each service could have been billed on multiple invoice line items.
That’s it for now. Let’s think things over and come back to discuss which database we’ll use.