【正文】 ntinues to be used, cumulative traffic (C) increases.look at the pros and cons of each in detail in chapter 5. Suffice it to say for now that any one of these formats will be much smaller than the mishmash returned by the classic web application. In an AJAX application, the traffic is heavily frontloaded, with a large and plex client being delivered in a single burst when the user logs in. Subsequent munications with the server are far more efficient, however. For a transient application, the cumulative traffic may be less for a conventional web page application, but as the average length of interaction time increases, the bandwidth cost of the AJAX application bees less than that of its classic counterpart. interaction with the application can be fluid and continuousA web browser provides two input mechanisms out of the box: hyperlinks and HTML forms. Hyperlinks can be constructed on the server and preloaded with Common Gateway Interface (CGI) parameters pointed at dynamic server pages or servlets. They can be dressed up with images and Cascading Style Sheets (CSS) to provide rudimentary feedback when the mouse hovers over them. Given a good web designer, hyperlinks can be made to look like quite fancy UI ponents. Form controls offer a basic subset of the standard desktop UI ponents: input textboxes, checkboxes and radio buttons, and dropdown lists. Several likely candidates are missing, though. There are no outofthebox tree controls, editable grids, or boboxes provided. Forms, like hyperlinks, point at serverside URLs.Alternatively, hyperlinks and form controls can be pointed at JavaScript functions. It’s a mon technique in web pages to provide rudimentary form validation in JavaScript, checking for empty fields, outofrange numbers, and so on, before submitting data to the server. These JavaScript functions persist only as long as the page itself and are replaced when the page submits. While the page is submitting, the user is effectively in limbo. The old page may still be visible for a while, and the browser may even allow the user to click on any visible links, but do in so will produce unpredictable results and may wreak havoc with the serverside session. The user is generally expected to wait until the page is refreshed, often with a set of choices similar to those that were snatched away from them seconds earlier. After all, adding a pair of trousers to the shopping basket is unlikely to modify the toplevel categories from “menswear,” “women’s wear,” “children’s,” and “accessories.”Let’s take the shopping cart example again. Because our AJAX shopping cart sends data asynchronously, users can drop things into it as fast as they can click. If the cart’s clientside code is robust, it will handle this load easily, and the users can get on with what they’re doing. There is no cart to drop things into, of course, just an object in session on the server. Users don’t want to know about session objects while shopping, and the cart metaphor provides a more fortable realworld description of what’s taking place. Switching contexts between the metaphor and direct access to the puter is distracting to users. Waiting for a page to refresh will jerk them back to the reality of sitting at a puter for a short time (figure ), and our AJAX implementation avoids doing this. Shopping is a transient activity, but if we consider a different business domain, for example, a highpressure help desk scenario or a plex engineering task, then the cost of disrupting the workflow every few seconds with a page refresh is prohibitive.The second advantage of AJAX is that we can hook events to a wider range of user actions. More sophisticated UI concepts such as draganddrop bee feasible, bringing the UI experience fully up to par with the desktop application widget sets. From a usability perspective, this freedom is important not so much because it allows us to exercise our imagination, but because it allows us to blend the user interaction and serverside requests more fully.Figure Interrupting the user’s workflow to process events. The user deals with two types of object: those。（3）、數(shù)據(jù)的安全性工作做的不到位，需要一定的加強，數(shù)據(jù)處理功能還有待完善。圖517 會員管理例圖（4）帖子管理帖子是BBS網(wǎng)站的主要數(shù)據(jù)來源，數(shù)據(jù)量最大，最復(fù)雜。 } else { alert(data)。 }Action(authCheck) public void authCheck() { if (null == (user)) { (false)。 if ($(content).val() == ) { alert(回復(fù)內(nèi)容不能為空！)。 return。 $(content).val($.trim(()))。 return。 } else { $.post(nameCheck,{name:$(username).val()}, function(data) { if (has == data) { $(name_yz).show()。 } catch (Exception e) { (().toString())。 String hql = null。 } else if (failure == data) { alert(用戶名或密碼錯誤,請重新輸入！)。用戶在登錄網(wǎng)站時需要輸入登錄信息，提交后系統(tǒng)會對用戶的登錄信息進行驗證，若登錄失敗系統(tǒng)提示錯誤信息，并給出處理意見，否則顯示用戶登錄信息，并在服務(wù)器端保存用戶登錄信息，登錄操作結(jié)束。表 44回復(fù)信息表列名數(shù)值類型長度默認(rèn)值描述主鍵備注IDINTEGER回復(fù)編號是唯一TZ_IDINTEGER帖子id否外鍵HFNRBLOB回復(fù)內(nèi)容否HFR_IDINTEGER回復(fù)人id否外鍵HFSJDATE系統(tǒng)時間回復(fù)時間否（5）帖子信息表，包括帖子id、標(biāo)題、類別、關(guān)鍵字、發(fā)帖人、發(fā)帖時間、帖子內(nèi)容、回復(fù)次數(shù)、審核人、置頂時間、置頂標(biāo)記，帖子信息表描述如表45所示。(1)工作人員ER圖管理員在對工作人員進行管理時，要從工作人員信息表中取數(shù)據(jù)，工作人員ER圖如下：圖43 工作人員子ER圖(2)系統(tǒng)用戶ER圖管理員登錄，高權(quán)限的管理員對低權(quán)限管理員進行管理時都要從系統(tǒng)用戶表中存取數(shù)據(jù)，系統(tǒng)用戶ER圖如下所示：圖44系統(tǒng)用戶子ER圖 (3)回復(fù)信息ER圖當(dāng)用戶在對帖子進行預(yù)覽時，如果該貼有回復(fù)信息，則要從回復(fù)信息表中取出所有該貼的回復(fù)信息。達人公社BBS主要有以下功能模塊：用戶模塊：帖子搜索、瀏覽、發(fā)表、回復(fù)、新聞瀏覽、個人資料修改、保存管理模塊：帖子管理，帖子審核、搜索、屏蔽、置頂、取消置頂、注銷用戶管理，用戶審核、收索、注銷新聞管理，新聞發(fā)布、查看、注銷業(yè)務(wù)管理，業(yè)務(wù)登記、查看、注銷人員管理，權(quán)限管理、登記、查看、資料修改、注銷系統(tǒng)結(jié)構(gòu)如下圖所示：圖41 系統(tǒng)結(jié)構(gòu)圖 系統(tǒng)數(shù)據(jù)庫設(shè)計 概述數(shù)據(jù)庫是信息系統(tǒng)的基礎(chǔ)和核心，數(shù)據(jù)庫設(shè)計的質(zhì)量將直接關(guān)系到系統(tǒng)開發(fā)的成敗和優(yōu)劣。但所有的實體流最終都要反映為能夠被人