Small steps and the big picture
This week for Clio 3 I recovered from last week’s angst–at least mostly. Working on my PHP CRUD (more on that below) and looking at the tutorials for what we’re doing next in class got me thinking both about the small steps and the bigger picture.
Small Steps
First, the small steps.
After class, I realized that my approach to tackling my PHP CRUD (create, read, update, delete) was off, to put it mildly. In creating my form for entering new data or updating my database, I followed a few examples, working to customize for my own needs–and picking up more PHP with it.
I went through it in a systematic way–just using the wrong system. I went through each portion of the file for all 37 or so variables (perhaps the first problem was having 37 variables). For example, one night I created all of the blanks for data entry, and tried (unsuccessfully) to create the menu for those fields already populated (e.g., people). The next night, I went through all of the edit scripts. Then I tried the new record portion. But doing it this way meant that it never actually ran. It got too complicated–both from my own PHP ineptitude and my surfeit of variables–before I could get it to that stage.
So after I threw my hands up in despair, I tackled CRUD again from the ground up. I approached it in what I’ve learned is the better systematic way: I created a very basic form first, with a few variables. I did everything I needed to get that functioning fully. Then I added more variables, and got those to function fully.
I started out with the small steps: the basic data entry parts. And lo and behold, it worked! I now have a functional, albeit far from complete, CRUD going. If you want to add a claim, I have the database living locally, so feel free to play. I’ll eventually password-protect the editing and deleting functions, but for now, I’m just glad to have them, and glad that others can see.
The next steps are, though, the harder ones. I need to figure out my menus…
Perhaps that will be the next step. Or perhaps it’s time, now that I’ve gotten a functional form using procedural PHP, to make one using object-oriented PHP. Like others in the class, after last week’s class and the tutorial, I understand the idea behind object-oriented PHP. Being that I still want to keep roughly 37 variables, if not more (see below), I’m thinking that will be the way to go by the time I turn this into my final project.
But I just don’t feel in a position to start implementing object-oriented PHP for this particular task. If others want to do so and there is time in class, perhaps a “crash course” for our specific tasks?
And the Big Picture…
This brings me to the question that I’m guessing the two people who got this far might have: 37 (or so!) variables?! Is this guy crazy? Well, yes, and likely, yes.
Last week’s frustration got me thinking about what I’m doing with this database. Specifically, what do I want my final project to look like, and how will it serve me (and the broader history profession) in the future?
Having reached this point in the semester, I’ve abandoned my original idea of having my final project reside in Omeka. It simply doesn’t work for what I’m trying to do.
So instead, my final project will be a stand-alone database. My end goal remains the same: using information that resides in U.S. citizen claim files against Mexico as a window into the interactions of the two countries on the ground before they went to war in 1846.
The information in many of the claim files at the National Archives is incredibly rich–useful beyond simply analyzing the claims themselves. All the files contain memorials, stating detail about the incidents for which the claimants sought compensation. But in order to advance their claims, these U.S. nationals submitted extensive supplementary documentation. Several ship manifests reside in these files, listing specific quantities of goods being traded–along with their ultimate destinations. The claimants who visited or even resided in Mexico detailed their activities there.
My goal is to capture as much of that information as possible in a systematic way, then analyze it for my dissertation. What types of goods were most traded? To and from where? How did that change over time? Where were people from the United States most active in Mexico? In what kinds of activities did they engage? What money was at stake? Who were the people connecting with Mexico? Where were they from? Where did they reside? How old were they? Answers to those questions–and many more–reside in this collection. While this collection in no way presents a comprehensive view of the activities of U.S. citizens with regard to Mexico, it does provide a snapshot. It provides a dataset that, at least at this early stage in my research, I’m guessing I would be hard-pressed to find elsewhere.
As such, that is why I chose to work with this dataset, and why right now I have roughly 37 variables. Likely I will end up with more, not less.
So, what will my final product be? As mentioned above, it will be a standalone database. Users will be able to search or browse the database, and run queries. I will provide maps and visualizations as I do them. One model for what I’m thinking is Jean Bauer’s Early American Foreign Service Database. Likely, I will include digitized versions of the memorials and supporting documentation in a separate Omeka collection.
So, that’s where things stand now. Any comments are most welcome!
David.. I think the best projects start as one thing and get refined to the point where they look totally different. I’m sure as you do more research it’ll morph even more. It sounds like you have a decent idea of where you want to end up, which is half the battle!
[…] more sophisticated. But after setting up a custom MySQL database in my Clio 3 class in 2012, I wasn’t ready to do that again. If the data is a mid-sized nail, an Excel spreadsheet is too small of a hammer, but a custom MySQL […]