Results 1 to 3 of 3
  1. #1
    Join Date
    Jul 2014

    Generalizing a table by moving non-general properties to separate tables.


    I am designing a database for a saas visualization application.

    The application will primarily be used by medical reseachers, but must be general to accommodate visualization of different types and from different domains.

    I am trying to decide how to generalize data set records. For example, I had properties such as diagnosis, species, gender, race, etc. In addition, some data sets might be 4D volume data, some 3D volume data, some might be graphs, or data sets I have never heard of. Different types of data sets from different domains will have different properties.

    So I am thinking I will keep the general properties such as id, name, license, and category in one table, and then have separate tables to keep more specific properties.

    Also we discussed just getting rid of most properties, allow the user/s add these things in the description, and then rely on a tag system to allow searching. Of course some specific properties such as patient id will still need to be included, because they do not make sense as tags.

    Anyone have any suggestions?
    Last edited by tAllan; 07-18-14 at 15:20.

  2. #2
    Join Date
    Jul 2014
    I'm using MySQL, and designing the database with dbDesigner4

    Let me clarify myself with an example.

    Say you want to store athletes, their stats, and information about themselves.

    But their stats are specific to their sport or maybe even the position they play. But it is nice to have a table of all of the athletes in the system including all of the properties that are general to an athlete. so you can look for athletes in a certain income bracket, or from a specific generation, etc. If you add new types of athletes to the system later on, you don't have to change your code base and check for their existence in what would be all of your athlete type specific tables.

    Is it good to have this general athlete table and have a separate table for each athlete type to store their statistics?

    Say you do this. Then athlete_id is a foreign key in another table, but which one depends on what type of athlete they are. How do you implement this? It seams there must be a better solution. Intuitively it seams like I need a table of tables.

  3. #3
    Join Date
    Nov 2004
    out on a limb
    Look T the sub/super type model
    I'd rather be riding on the Tiger 800 or the Norton

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts