[ Pobierz całość w formacie PDF ]
.It's worth noting that in many cases, youcould easily add a much richer set of details for the data objects, such as users' emailaddresses and preferences, account histories, and complex event tracking such as departmentsand locations.However, you get the idea, and keeping the example simple enables you tocarry this book under your arm instead of in a wheelbarrow.3.1.1 UsersThe first portion of the data store is the easiest to design.Storing information about users isgenerally not a difficult task; the most complex part of the job is determining whatinformation needs to be stored.For the purposes of the example application, this informationis fairly limited.Here's a list of this basic information and how it could be logically grouped:" Username for application" User's "real" nameo First nameo Last name" User's home officeo Cityo StateEven this simple list contains enough information to distinguish users from each other.Whilean application client might have the same first and last name as another client, you shouldbuild rules into the application to ensure the uniqueness of their usernames.For now we'llsimply assume that the mechanism that creates usernames, either programmatically or byletting the user select one, can be coded to utilize this sort of constraint and inform the user iferrors occur.3.1.1.1 Data constraintsWith this basic step complete, it's time to make some decisions about constraints set upon thedata.For example, usernames should be unique.The issue, then, is whether this constraintbelongs at the application level or at the data layer.Your initial impulse may be to place theconstraint at the database (or directory server) level, rather than in Java code.However, this type of constraint can often result in error messages returned to Java programsthat are difficult to deal with at runtime.Additionally, the error message returned is oftenvendor-specific.While Oracle may supply an ORA-1302 error code, PostgreSQL may returnthe string "Uniqueness constraint: duplicate data." And a directory server might use anentirely different format for error reporting.As you can see, although the data is protectedfrom invalidity, the corresponding Java code still needs to perform some checks of its own.29 Building Java"! Enterprise Applications Volume I: ArchitectureThe code that creates users will need to specifically check for and handle this error condition.This is something I'll explain later.At the same time, usernames may need to be at least four characters long (for example).Thisis another, similar constraint, but must be handled completely differently.First, themechanism for length checking is not as standardized as the check for uniqueness.Somedatabases allow a data length (both minimum and maximum) to be directly defined.Otherdatabases provide for triggers to be coded that perform these checks and generate errors, ifneeded.And still other databases provide no means for this sort of check at all.In these cases,where generic means are either nonexistent or insufficient, the answer is to code, code, code.So, the answer to where data constraints belong is a mixed message.In almost all cases, if aconstraint is set on data, it should be at least checked for specifically, if not completelyhandled, at the application level.And in the cases where a database offers a general way(preferably across databases) to enforce constraints at a lower level, those means should beused in addition to application code.3.1.1.2 User typesAnother requirement of the Forethought application is the ability to represent both clients andemployees in a similar fashion.While there is certainly a temptation to store these users intwo separate areas of the data store, you should not give in; the information being stored aboutemployees and clients is exactly the same (username, first name, and last name).In fact, thereis rarely a time when the core information about disparate groups of people is significantlydifferent.The only difference here is that an employee has an associated office record, butsimply adding a separate structure for office data takes care of that requirement and stillallows the use of a single structure for both clients and employees.Records, Structures, and Other DatabaseTermsAs you've probably noticed, quite a few terms get thrown around when talking aboutdatabases.First, the entire database can be referred to as a data store
[ Pobierz całość w formacie PDF ]