Project Design 01
Project Constraints
The solution is dictated to be MySQL with the CakePHP Framework for PHP. My self study is aimed in that direction. I am assuming this won’t create a barrier to implementing the data design in Oracle at the same time.
CakePHP has some slightly weird table-naming expectations. I have found that if you follow the CakePHP expectations to the letter, you can get things up and running in extremely rapid fashion. If not, you don’t. I am therefore dictating that the actual MySQL implementations follow the naming conventions documented at http://book.cakephp.org/2.0/en/models/associations-linking-models-together.html.
CakePHP does have a good way of building a solid Web site based on highly normalized tables. CakePHP thrives on a correctly-normalized design. It’s very convenient, given the curriculum sequence, that I intend to create the data design first and build the Web site out from the schema.
I would ideally like to have some sort of useful demonstration up and running for the Strong Family Reunion.
This means that I need to find a way to articulate what I’m trying to accomplish, and figure out what this means for people willing to add their help. These would be genealogy people not hi-tech computer people.
Design Starting Point
The Web application, as I envision it, is a read-only application. Once stuff is imported, there is no interactive aspect for normal users, except the ability to search, click around, and so on.
In http://otscripts.com/mining-the-historian-archives-08/ I listed the primary ways of looking at the Historian Archives. It makes sense to me that our data design should support those views. (I mean “views” in the eyeball sense rather than in the SQL sense.)
In other words, I think the first step is to fully define the User Experience. I don’t care about exact page layout, and there is no reason to mock up Web pages. Get the data design right, and CakePHP will generate code with a good layout.
What I need to do, then, is identify the “user screens” and what should appear on those screens. We should then be able to create a data design supporting those views. Not coincidentally, if we take that approach, CakePHP should be able to generate the complete Web site in minutes. Most of the work involved will be in restricting add/edit/update functionality to the admin area.
In the project description (meaning the list of primary ways of looking at the Historian Archives in #08) I talk about clickable links. In the data design, those are table relationships. If we can get the table design correct, CakePHP knows how to build those links reflecting the relationships.
The designed User Experience should encompass each of the types of artifacts and collections that I described in articles #01-#08. Some of those will be empty, of course, as we phase things in – but the data design should include the tables needed to support the complete User Experience.
Remember, always remember, that we have three primary points of access: By Dwight Number, By Name, By Descendant Line. (Remember, the tooth. Remember! The tooth!)
Our next step, I think, is to carefully consider each of the artifacts and collections described, and identify (write down) what the User Experience should look like with respect to that item.
We then have our basis for a data design – but we’re not done!