[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] database schema, was Re: LinuDent and tk_fp and odont
Re: [Gnumed-devel] database schema, was Re: LinuDent and tk_fp and odontolinux
Wed, 17 Apr 2002 12:44:35 +1000
On Wed, 17 Apr 2002 10:33, Andrew Ho wrote:
> Sharing the DB is a good idea. However, is the DB schema easy to extend
> and manage over time? For example, if I take the GNUmed DB and modify a
> few of its tables (e.g. for psychiatry), how do I make sure that I don't
> break compatibility with the Internal Medicine modules? How do I make
> sure what I added will work with other people's ideas for describing the
> psychiatry domain?
Easy. We broke up our database design into independend "services". That is,
one set of tables and relationship focuses on demographics - and nothing
else. One set of tables and relationship focuses on pharmaceutic
reference, and so forth.
For psychiatry, you just add another psychiatry centric "service", but you
don't modify existing tables.
Our design is highly (though not completely) normalized. In your own added
tables, you just add references to whatever other existing information you
need to incorporate into your own design.
The main GUI client software allows plugins; You can take the
off-the-shelve user interface and write a few plugins adding dialogs for
your domain-specific problems. The design is dead-easy: all your plugin
1.) suggest where to be placed on the user interface (you can enforce a
placement on the GUI too if you need)
2.) register itself with a variety of "broker" objects that give the plugin
- access to user interface elements
- access existing database connections
- access to callback function registers that notify the plugin on data
changes (like when a different patient is selected by the user)
When you write your plugin, you just focus on your domain specific needs.
Chances are, that the features common to any domain (like patients
demographics, pathology results etc) are already working and need no
modification. As most user interaction happens through "notebook" alike
widgets, you can expand existing ones by letting your plugin simply add
You can reach such autonomy of information only with highly normalized
data; otherwise, there would be too much artificial interdependence of
information preventing you from adding information in a "black box" style.
Thus, I see the lack of normalization a great weakness in other projects.
|[Prev in Thread]
||[Next in Thread]|
- Re: [Gnumed-devel] database schema, was Re: LinuDent and tk_fp and odontolinux,
Horst Herb <=