Database usability

Before we migrated to MS ACCESS 2007, we noticed that we could not sort queries by property/description in MS ACCESS 2007. This caused a big problem for us since a lot of our tasks are based on several queries and we try to keep them together by coding the description. Why we chose to do this in the first place? Well, as we all know that ACCESS isn't build to be a power house and there are times you have to combine several queries to achieve the task on hand. We did not chose to code the query name since changing the query name may break other queries.

Because of this, we began a project that stored all queries in a table and on top of that we build other facilities to link queries into tasks. In the process, we constructed a framework that we think can be a better user front end for databases.

The framework create a layer on top of the query so that we can assign a path to classify a query. This is like a link in the *nix file system. We can then build a tree structure that allows us to locate a query. We also build a task layer on top of the query so that we can combine couple of queries to create a task. On top the task, we also build a tree structure that allows us to organize tasks.

As mentioned earlier, we stored all our queries in a table, this gives us the ability to search the table and build dependency information between queries. We can also build the dependency info between queries and tasks. All of these helped us in maintaining our projects.

For example, one of our tasks is to import data from external sources. The data format and definition can change from year to year. The process/task to import the data can also change from year to year. Every year we did our best to import that data. However, from time to time, we found that we process the data incorrectly later. It become obvious that we need a good way to document the task we performed every year so that in case of error, we can trace back our steps.

With the system we have, we can create task alias/paths like:
Organization/DataType/DefintionCheck/2007
Organization/DataType/DataImport/2007
etc...
In the case that the data come in in the same format like last year, we can simply create a new link that pointed to the same task of last year. Otherwise we will create a new task and alias.

With the path/alias, we can also build a tree structure that make locating queries and tasks much easier.

At this point, the system is not finished yet and we are trying to make our system more universe so that we can adopt this system to, say, the OpenOffice database.

A thought on EvntIn(Src, EvntId)

I was working on MS ACCESS to create event call backs between objects and devised this function signature. After thinking it through, I decided that this is really not a good way of handling event call backs.

Here's my reasoning:

The appropriation of this function is arguable concerning the implementation of the EvntId, if the source is a class that implements ours and other interfaces. Under this situation, it is true that

we can cast the Src and pass it to our parent object. But casting the EvntId requests a lot from a programming language.

Suppose a class is implementing several interfaces which include specifications of enumerated event IDs. When calling this function, how can that class decide what event Id to use? In order to resolve this, one can require the EventId be stored in the object. But this will raise another problem: What if another event happens before this function got time to process the event? This will lead to the requirement that the calling class must LOCK the event Id for calling this function while still allow other process to update the event Id. This, again, request a lot from a computer language.

If a language implemented the event by calling different call back function and, therefore, eliminated the need for passing the event Id, the issue of casting the event Id will not exist. Also if a language includes the call-back registration as part of the interface specification, the syntax will be OK since the event triggering class knows how to cast EvntId be passed to the call-back function.

In light of this, this function can only be implemented as a internal hub function that called by all event call back functions.

As a related thoughts, a event issuing object should never implement a variable that record the event Id since the value will never stick and using that variable for anything is questionable - queuing events is a different issue.

Idea: Browser web page highlighter

The idea is to create a program/plug-in so that a reader of a web page can highlight a paragraph or sentence or even type notes. This tool will provide a paper-pencil equivalent that allows reader to take notes right on the reading page.

The program/plug-in can require installation so that it can have permission to work on all tabs.

Given the dynamic nature of web pages, there will be challenges on how to implemented this. One possible solution is to save a static copy on the local machine and apply highlights to it. Once this is done, we can extend this to static pages on the web. Possible examples are the RFCs, the W3C URIs ... etc.

One possible solution for dynamic pages is to use the text-search to locate possible positions. The search may include parsing the XML.

In addition to the page highlighter, a program can monitor changes of the highlighted pages and report to user for maintenance.