DB Issues: addressbook and users

yehster wrote on Thursday, February 16, 2012:

Shameem said in the other thread:
More than just changing to InnoDB I have heard a lot of issues with tables itself. So whoever had those complaints should actually speak up now. One concrete issue I have seen mentioned before is the addressbook and users being in the same table.

I’m starting a separate thread since it’s a separate issue. It will get confusing if we try and talk about database normalization issues in the same thread as database engine issues.

sunsetsystems wrote on Thursday, February 16, 2012:

Main reason they are in the same table is to avoid duplication; users are generally also candidates for the address book.  Perhaps it would be more aesthetically pleasing if the table had a different name (like “address_book”).

Rod
www.sunsetsystems.com

yehster wrote on Thursday, February 16, 2012:

I might be wrong, but in reviewing the schema, It’s not so much that the address table itself, it that the users table is used to store actual users of the OpenEMR system as well as other “people” (like a referring physician).

My quick assessment is that there should be a “People table” that joins with a “Users” table.  So we can capture info that is common between “People” even if they aren’t an OpenEMR user, and normalize the data in the users table that is specific to some one with login permissions in OpenEMR seperately.

sunsetsystems wrote on Thursday, February 16, 2012:

I have no objection to that.  The challenge is to identify a benefit significant enough that someone is willing to do it.

Rod
www.sunsetsystems.com

sunsetsystems wrote on Thursday, February 16, 2012:

Oh and don’t forget that if someone does this, they also need to handle the table conversion at upgrade time.

Rod
www.sunsetsystems.com

blankev wrote on Thursday, February 16, 2012:

IMHO and in as far as my experience goes with OpenEMR:

1. There are registered users.
2. Seperated the table of registered clients/patients and these have sometimes also a connection with the following two groups:

There are registered third party persons medical
There are registered third party persons non-medical
There are registered third party companies medical or non-medical.

The table used now is a combination of all different parties. With a rather  simple sort and selection option you can get the right group in focus.

That could mean there is no reason for splitting in different tables?

Pimm