Business Tech: Building MultiValue Programmers - Part II
Last installment, we discussed different kinds of databases. Now that we have some grounding in what a database is, we should discuss why we use computerized databases. To better understand this, let's throw a party.
Making a List
Grab a piece of paper and put a list of names on it. Congratulations. You've just created a single-table database of potential party guests. Like the electronic version, you can add names and remove names. You can produce changes over time. You can even grab another sheet and build a second table. Or make notes besides the names, creating new attributes (columns).
The problems start with the fact that paper lists don't scale. For tracking a dozen friends, it's probably fine. When the party has a thousand invites, you can do it on paper but you'd be better off with some tools.
One way people solve for increased complexity is to move the lists into word processors or spreadsheets. The big advantage to the word processor is simplicity, ease of use. The spreadsheet, while more complicated, gives you more sophisticated tools. And this is the fundamental trade-off.
Paper requires the least training. Word processing adds complexity but adds features. Spreadsheets bring both, complexity and features, up a notch. Once we go to a true database, we move up several notches in both.
Party Base
When we step up to the database we gain some validation controls, some more sophisticated entry options, and much more of a learning curve. As we said last installment, if you're going to suffer a cost (time, trouble, effort, money) there had better be a payoff.
Our party base will let us transition people from "invited" to other statuses (going, maybe, not going). It will let us catch late responders so we know who to follow up with in our planning. It introduces some strategy into our approach.
We can link the food plans to the guest list, scaling up or down the shopping based on who has assured us they are coming. We can add a trim-down for the difference between "said they would" and "actually showed up." Not all promises are equally valid.
We can go further. What if we slot in a restaurant capacity table? Over twenty-five coming? Automatically scratch off the smallest places. Ten dropped out, unscratch. It isn't that we couldn't do all of this on paper, or with a word processor, or by spreadsheet. It's a matter of how fast or easy it will be to manage it.
Of course, if this is the only big party you plan on throwing, the features may not balance favorably against the complexity. But, if parties are your business, investing the time in building a robust database, with robust software, is that way to go.
Directionality
Another argument for databases: I can move structured data from a database to a word processing document, or PDF, or spreadsheet. I can't always do the reverse. Moving more complex to less complex is rolling a boulder downhill. Uphill is harder. Much harder.
It is an important idea to absorb: Doing it right the first time is better than doing it over and kludging one-shot solutions. Most things in your professional career will push you the other way. Employers usually want you to write it fast and then complain that you can't maintain it. Smart design with smart execution makes for less work, less hours, overall.
Writing clean, clear, manageable code is important. Communicating the value of that to your bosses can make a bad job into a better job and a good job into a great one.
Reporting
The big sell for using a spreadsheet or a database is the ability to organize the data multiple ways. We can use party base to generate reports, reminders, orders for supplies, a budget-to-spending analysis for cost control… al sorts of ways to peer into the data. If parties are your business, it can track staffing, not just guests. That helps with payroll, 1099 forms, W2s, and all the other requirements of having full-time or temporary workers.
Once I pay the "education tax" of learning how to use the database and it's software, I can make one session of data entry into many results. I can maximize the value of the work done. This benefits the users of the software, the maintainers of the software, and the beneficiaries (the party-goers).
Retention
The problem with paper is that it is hard to index and manage compared to well-architected data. System-managed indexes can make one set of data act like it is filed many different ways. We can find the caterer by name, EIN, or by the size of party they can handle.
We can find the guests who have attended multiple events (data mining) and suggest they throw their own bash. We can find the people we threw weddings for a decade ago (more data mining) and suggest an anniversary party. We can find the corporate clients from last year and offer a deal on doing another seminar with us.
We can also look at trends. Most people can spot a huge uptick or downtick in business. But knowing that the summer slump is atypical because it is three months earlier than average… that's a place where tech can help.
When we retain data in an actionable format, we generate actions which can benefit the company.
Architecture
Actionable format is often the missing ingredient in most databases, regardless of the technology. In Part III, we'll talk more about data architecture.
Charles Barouch is the CTO of HDWP, Inc. He is also a regular contributor to International Spectrum Magazine, a former Associate Editor for both Database Trends and for Gateways Magazine, a former distance learning Instructor for CALC. He is presently the Past President of the U2UG. Mr. Barouch has presented technology and business topics in front of hundreds of companies, in a wide range of product and service categories. He is available for on-site speaking and consulting engagements in and out of the United States.
View more articles