My database adventures are still going nicely, though I am starting to bump up against things that I haven't learned yet (ie. SQL) so it's getting interesting.
Yesterday, I went back to basics and built the database again from the ground up using the lessons I learned.
Today, I continued that work by creating a table of just unique identifiers for my books.
This might seem like a strange thing to include, but I have personal reasons for it.
Reason #1: Book promo sites ask for identifiers all the time. Wouldn't it be nice to look at what, say Bargain Booksy needs to submit a promo, and then generate a query that has all that info…? (title, author, ASIN, etc.). Plus, if you have the unique identifier, you can build a correct link (and store fewer characters in the database).
Reason #2: Data mining. I was working with a developer last year who was building an app for me that involved APIs–they needed all of the unique identifiers for my books for all retailers, and I had to rush out and get them, which took me several days. Storing them in a table makes them easy to recall if I ever need them again.
While we didn't continue with the app work, the experience taught me a lot about APIs and how to actually connect with book retailers on the backend so that you can glean data from them (long story). And trust me, there's a lot of data to be gleaned…if they'll let us have it.
The world is moving toward more interconnected apps and services. It's just a matter of time before authors can access the benefits of data mining and APIs. Having a solid database is a bet on this future, if it ever comes to pass.
Anyway, rabbit hole.
Designing the Front End
Now that I've got the back end of the foundation built, it's time to create a front end to make data entry easier (and more visually appealing).
I want a “one-stop shop” for entering information for my books, and I need one form to send data to a few different tables on the back end.
Based on some advice and videos I've seen on the Internet, I wanted to create a form that had various subforms within it for easier entry.
I messed around with this WAY too long (my rite of passage with subforms I guess), but this is what I came up with:
Did you hear that sound? Why, it's money in the bank…
Exactly what I was looking for, though the design needs some tweaking. I've got the basic book information at the top, and then a bunch of subforms that are within the tabbed area.
In this example, you can see that I have my cover designer information listed for the book. If I wanted to add another designer, I could do so in the form below, and I would 1) keep track of new updates to the book and 2) keep track of the book at a high level.
One thing I need do at some point (soon) is create a designer table so that I can capture designer info ONE TIME instead of having to re-enter it. Otherwise, my entries will be inconsistent (as you'll see below…)
I'll figure that out at a later date, as I'd also have to do this with editors, narrators, translators, etc. I've opened enough Pandora's boxes for today…
I populated some more information on my other books so you can see how this works. Pay attention to the tabs.
Anyway, I'm out for the night. My brain hurts.
Thanks for following this so far. Before you go, consider joining my Fan Club. It's an amazing place to be these days if you want writing and self-publishing business tips.
