Project Design 02

I view our project (the Web site) as having two distinct phases:

  • We have the User Experience. I believe this is what we want to design first.
  • We have the import process. The data creation/import process is undoubtedly different for each type of artifact or collection.

Project Design 01 talked about the first item. This post talks about the second item.


One of the SOLID principles ( of Object-Oriented Design is the Open/Closed principle: Software entities should be open for extension, but closed for modification.

Here we have a good example of applying that principle. As I see it, the User Experience design should not have to change, even when we add new types of collections or artifacts. To be sure, over time, we may find ways that we want to improve the User Experience. That may include changing that part of the design. On the other hand, it might not; it might merely mean adding to (extending) the experience.

That’s why I look at the import process as separate. Each import process is likely to be different for each type of artifact or collection. I see a two-step process:

  1. Do whatever it takes to get the data into the database in usable form. This will include creating whatever tables make sense at the time. An ad-hoc design is fine. Whatever works, is good enough. More on this below.
  2. Create an export process to get the data from the previous step, over to the User Experience database. This could include inserts, replacements, whatever. It’s my intent that the User Experience data design will mean that the tables are ready and waiting. It’s this step which populates those tables.

It’s my experience that the import process has to be ad-hoc. We are dealing with human-created artifacts rather than well-structured computer databases. It will require custom code at every step to get the data into tables in a usable form. In other words we make it up as we go.

The purpose of that ad-hoc import is to then marshal the results and insert those results into our well-formed User Experience database.

This is where the extensibility comes in. We build structures as necessary for additional import steps, but we don’t need any additional design work for the User Experience database.

The ad-hoc imports will in all likelihood be handled on localhost (my Mac laptop). This is another reason for having separate and unconnected tables for the import phase. Once the data is imported into some sort of usable form, I can dump and restore the tables and their contents to the production database. Since they are new tables, there is no risk of collision. We can then run the insert phase on the production database.