Instance lists do not have to reflect the database that underpins them

Instance lists do not have to reflect the database that underpins them

Instance lists are conceptual. They often reflect the physical structure of the database table(s) that underpins them, but they don't have to.

 

In this simple SECTIONS-EMPLOYEES relationship used through these examples, imagine the visual impact of a section containing 2000 employees. In a case like this you might consider inventing a 4 different child employee business objects named EMPLOYEES_A_G, EMPLOYEES_H_M, EMPLOYEES_N_T, EMPLOYEES_U_END to split up the children alphabetically into 4 groups.

 

Here's another simple example. Imagine you had a single database file containing messages. Each message has a unique identifying 7 digit number. Each message also has a status, somewhat like an e-mail, of RECEIVED, READ, SENT and DELETED. Conceptually this might be arranged into an instance list like this:

Business Object Type	AKey1	AKey2
RECEIVE	RECEIVE
MESSAGE	RECEIVE	26272
MESSAGE	RECEIVE	63738
READ	READ
MESSAGE	READ	73389
MESSAGE	READ	74584
MESAAGE	READ	73873
SENT	SENT
MESSAGE	SENT	78383
MESSAGE	SENT	37383
DELETED	DELETE
MESSAGE	DELETE	62727

 

Conceptually the instance looks something like an e-mail inbox, outbox and deleted items. It is not directly reflective of the underpinning database design.