[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    [Kde-usability] MySQL Database Design
From:       Jono Bacon <f9808590 () wlv ! ac ! uk>
Date:       2001-03-25 4:36:38
[Download RAW message or body]

Hello all,

<DISCLAIMER>

OK, I am no database expert, but I think it is time we discuss how we will 
structure our database. The following is ideas from me just before I really 
start reading up on database design. I have nice MySQL O'Reilly book waitiing 
to be read. :-)

</DISCLAIMER>

OK, in designing our database, we need to identify which research programmes 
we are going to be looking into, and what our database requirements are. We 
also need to be able to plug in new programmes when we develop them. It seems 
we will have the following programmes available:

 - Candidate profiling
 - General KDE Programme
 - Icon Programme

Up until now we have been discussing that profiling is something we will do 
to catagorise what type of users we are getting data from. We were inititally 
planning on getting this personal data such as age, gender, country etc at 
the top of the page. Upon looking at Aaron's page, I think it would be a good 
idea if we get the personal data first so the user can log in and perform 
multiple tests already logged in. This has it's good and bad points:

  Good

  - Saves multiple records for the same users profile for different tests
  - Cleaner and easier for the user...they just log in and they are done
  - Saves disk space

  Bad

  - If the users details change, and they update their profile...it 
invalidates previously stored data.

If the user needs to change their details (such as a new job, move to a 
different country etc) they should have a new profile created. We need to 
ensure that profile data is integral for each programme.

Basing my limited database experience on our requirement, I see we need the 
following tables in the database:

(fields below in CAPITAL LETTERS are linked from another database)

  -----------------

  Country
  - id, country

  This contains a list a of countries showed in a combo box.
  -----------------

  Profession
  - id, profession

  This has a list of professions showed in a combo box
  -----------------

  Uses
  - id, uses

  This contains a list of uses that are available in a combo box
  -----------------

  Profile
  - id, forename, surname, COUNTRY, PROFESSION, experience, uses
  -----------------

  Icon
  - id, filename
  -----------------

  IconProgramme
  - id, PROFILE_ID,  ICON_ID, descrip1, descrip2, difficulty,  ICON_ID, 
descrip1, descrip2, difficulty,  ICON_ID, descrip1, descrip2, difficulty,  
ICON_ID, descrip1, descrip2, difficulty,  ICON_ID, descrip1, descrip2, 
difficulty,  ICON_ID, descrip1, descrip2, difficulty,  ICON_ID, descrip1, 
descrip2, difficulty,  ICON_ID, descrip1, descrip2, difficulty,  ICON_ID, 
descrip1, descrip2, difficulty...............          

   This large table contains all of the moderated (to check for spelling 
mistakes) data from the icon programme.
  -----------------

A for the general test, I have thought of this yet. I am unsure if a huge 
table is the best method of storing the data. Aaron...can you shed any light 
on this?

	Jono

-- 
Jono Bacon - [vmlinuz] - jono@kde.org
KDE/Qt Developer
_______________________________________________
kde-usability mailing list
kde-usability@master.kde.org
http://master.kde.org/mailman/listinfo/kde-usability

[prev in list] [next in list] [prev in thread] [next in thread]