On Sun, 30 May 2004, Adrian Midgley wrote: ... > > right, use unlimited number of tables to model unlimited number of > > services. That's the same as using unlimited number of OIO archetypes > > (forms) to model unlimited number of services. > > Those look exactly opposite to me - normalising the table should allow an > unlimited number of services to be stored in one fashion (a normal form, in a > very relevant sense) within one table.
Adrian, You and I may be focusing on two different aspects of the design. The description of each new "service" must be stored somehow. I think this you also agree with me. My point is that it does not matter really where and how this information is stored. Regardless of where and how, for each new service, some new information must be added. In the case of OIO, we create new forms to describe each service. In your normalized database schema, you may add additional rows to some set of tables. > Not normalising the table means that each service is exceptional, and > therefore must be handled by a new table, Correct. It is worthwhile examining how well (or not) this fits the real world. > thus producing an unchecked and hard to examine growth of tables. That's going a bit too far. There are many ways to code relationships between tables. Not "fully" normalizing hardly means we have an unchecked growth of tables. I have described previously (in response to Tim Churches query most recently) how OIO utilizes database tables to model forms in a measured and controlled fashion. > Inevitably confusion will arise and some services will be added twice, > or more, entries will be made in one place, looked for in another, and > mistakes will be made as a result. Same dangers (and more) can occur in poorly designed or poorly implemented "fully normalized" systems. :-) As I said above, it is important to examine how well the information system models the real world. Normalized systems may fall short because they have a hard time modeling exceptions. Ask yourself this question, are there domains that are characterized by diversity of workflow and information needs? In those domains, do we expect to encounter modeling challenges that come from the need to accomodate local variations and "exceptions"? Finally, would "medical practice and research" fall into this class of knowledge domains? ... > I do see several people who have patiently explained why they have > adopted some of the principles of informatics and of database design, > which arose out of useful but unconnectable ad hoc system development a > score or so of years ago. Could you kindly point to some of these previous failures so that I can learn from them? ... Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
