phpScheduleIt
June 18, 2013, 02:18:52 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: phpScheduleIt 2.4.2 has been released!
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Data Dictonary (Functional Design)  (Read 1458 times)
jan
Newbie
*

Karma: 0
Posts: 11


« on: June 23, 2010, 05:36:31 AM »

Referring to an older post, here: http://php.brickhost.com/forums/index.php?topic=3763.0

Hi nick and all,

Yes, a data dictionary showing relations between the tables would be helpfull, someone has a document like this?

Currently i am (before programming anything) making a Functional Design of the needs of a large school. It has:
- more then one schedule,
- every schedule has its own Admin and own resources.
- A schedule-admin sees only it's own resources.
- Only admins make reservations (for students).
- resources must be in grouped (example: recording devices, display devices)
- One reservation can contain more then one resource (cannot be solved with accessoiries)

Anyone has made similar revisions/implemetations? Is there a way to share or work together?

regards, jan

Logged
jan
Newbie
*

Karma: 0
Posts: 11


« Reply #1 on: June 25, 2010, 05:31:51 AM »

Here it is: DB relationships between the tables (partial). First how it is now in schedule-it 1.2, and secondly in the same doc the implementation we want. Is it correct? Can you advise on how to do our version? Starting with more then one database would that be a good option? Or more recoding. Thanks in advance for some advise! regards, Jan
http://www.larka.nl/schedultitDOC/DB-schema-UK.pdf

Logged
Nick
Administrator
Hero Member
*****

Karma: 15
Posts: 5506


WWW
« Reply #2 on: June 28, 2010, 01:37:28 PM »

Looks like it should work.  Will you just have a many-to-many between reservations and resources?  This change will ripple through much of the code since there are a lot of assumptions that a reservation is only for a single resource.

Starting with a new database isn't a bad option.  That makes it easy to compare the changes or roll something back.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2006-2007, Simple Machines Valid XHTML 1.0! Valid CSS!