- A service request is made on the server for both the search and the construction of the update form, and naturally also for the actual update. The pages are build up in the server. A new search has to be activated after each update.
Building the menu, about 50 times: request about 500B + database query + result about 800B (menu and header) = about 1300 B Construction of the update page, 50 times request about 500B + database query + result about 700B. Processing the update about 50 times request: 500B + database update + result page about 500B Data transfer: 50*1300 + 50*1200 + 50*1000= 175000B Database operations 50*menu query+ 50*user data query +50*update query Poor usability because of menu renewal.- Data for the list of employees matching the search condition and the numerals for the update form are fetched from the server in the Ajax way. The whole page is not renewed but only the changing parts (the menu and the update form).
Building the menu, about 15 times (assuming that about 15 of the initials are in use): Apporoximaty same as in case a, some titlest etc not transfered = about 1200 B Construction of the update page, 50 times: request about 500B + database query + result about 500B (only data). = about 1000B Processing the update about 50 times request: 500B + database update + result page about 500B Data transfer: 15*1200B+50*1000B+50*1000B =118000B+ program code about 2000B= 120000B Database operations: 15* query for menu+50*user data +50*update- The search condition is used to retrieve all personal data needed for the menu and the update. These are shown in a data grid..The super user is able to change the information in the grid and save the row when is has been changed.
User group fetch 15 times: request 500B + database query + result about 900B = 1400B Construction of the update page does not cause data transfer. Processing the update about 50 times request: 500B + database update + result page about 500B Data transfer: 15*1400B+50*1000B =21000+50000 =71000 + program about 6000B= 77000B Database operations: 15*query for user data +50*updata- There is no search possibility. All the employee records are loaded in the data grid. The update is similar to case c. User fetch 1 times: request 500B + database query + result about 1500B Construction of the update page does not cause data transfer. Processing the update about 50 times request: 500B + database update + result page about 500B Data transfer: 1*2000B+50*1000B =2000+50000 =52000 + loading the program 6000B= 58000B Database operations 1*query for users + 50*update
You may assume that there is about 100 bytes data for each employee and that name and user account occupy about 80% of this. The header information of service request and response may be assumed to be about 500 bytes each..
When data trransfer is concerned the most efficient alternative is d. It is also most efficient on database usage. A list of 200 names is quite long so choise c might be more usable.
Many program libraries provide a solution for this. When the record in clicked its fields turn to editable and 'save' and 'reset' buttons appear. There are many ways to implement this, for example a ready made hidden form.
http://www.cs.helsinki.fi/u/laine/dime/s07/ajax2.html shows one answer.
See page http://www.cs.helsinki.fi/u/laine/dime/s07/cookitest.html
Exercise to be done during exercise session: Build a skeleton for a php-page on the department's : php-server. The page should show a title, the date and a text you provide as a parameter.. Instructions in Finnish