Pawnshop Application (any RDBMS):
one-to-many relationship where each customer (master) can have many transactions (detail).
customer(
id serial,
pk_name char(30), {PATERNAL-NAME MATERNAL-NAME, FIRST-NAME MIDDLE-NAME-INITIAL}
[...]
);
unique index on id;
unique cluster index on pk_name;
transaction(
fk_name char(30),
tran_type char(1),
ticket_number serial,
[...]
);
dups cluster index on fk_name;
unique index on ticket_number;
Several people have told me this is not the correct way to join master to detail. They said I should always join customer.id[serial] to transactions.id[integer].
When a customer pawns merchandise, clerk queries the master using wildcards on name. The query usually returns several customers, clerk scrolls until locating the right name, enters a 'D' to change to detail transactions table, all transactions are automatically queried, then clerk enters an 'A' to add a new transaction.
The problem with using customer.id joining transaction.id is that although the customer table is maintained in sorted name order, clustering the transaction table by fk_id groups the transactions by fk_id, but they are not in the same order as the customer name, so when clerk is scrolling through customer names in the master, the system has to jump allover the place to locate the clustered transactions belonging to each customer. As each new customer is added, the next id is assigned to that customer, but new customers dont show up in alphabetical order. I experimented using id joins and confirmed the decrease in performance.
The drawbacks of using name joins vs. id joins is if you change customer name, the join with their transactions is severed, so I dont allow updating the name. Anyway, how often does one need to change a customers name? The other draw back is name requires 30 chars where id is INT, so .dat and .idx are larger. Every morning an sql proc is executed which unloads customer and transactions in sorted name order, drops/re-creates the tables, loads the unloaded data and all indexes are re-created which keeps performance optimized.
How can I use id joins instead of name joins and still preserve the clustered transaction order by name if transactions has no name column?
The following is an example of how the data sits in customer.dat and transactions.dat when using pk/fk name, as described in the above schema:
customer.id customer.pk_name transaction.fk_name transaction.ticket_number
----------- ------------------------------ ------------------------------ -------------
2|ACEVEDO BERMUDEZ, FRANCISCO J. ACEVEDO BERMUDEZ, FRANCISCO J.|123456
ACEVEDO BERMUDEZ, FRANCISCO J.|123789
3|ANDUJAR RODRIGUEZ, WILFREDO C. ANDUJAR RODRIGUEZ, WILFREDO C.|101010
ANDUJAR RODRIGUEZ, WILFREDO C.|121212
1|CASTILLO DIAZ, FRANKLIN J. CASTILLO DIAZ, FRANKLIN J. |232323
CASTILLO DIAZ, FRANKLIN J. |343434
So, when clerk wilcard queries by customer master name, customers transactions are automatically queried and quickly displayed when clerk scrolls thru names returned into the current list since they are in the same sorted order as the master.
Now, the following example is the same data using pk/fk id:
customer.pk_id customer.name transactions.fk_id transactions.ticket_#
-------------- ------------------------------ ------------------ ---------------------
2|ACEVEDO BERMUDEZ, FRANCISCO J. 1|232323
1|343434
3|ANDUJAR RODRIGUEZ, WILFREDO C. 2|123456
2|123789
1|CASTILLO DIAZ, FRANKLIN J. 3|101010
3|121212
OK, so now keep in mind that my perform 1-page screen includes all customer columns and all transactions columns, and there's a master/detail instruction which when the clerk queries by customer name, the first transaction row belonging to that customer is automatically displayed. Then the clerk will press 'D' to make transactions the active table and press 'A' to add a new transaction, or clerk may scroll through all the customers transactions to update one in particular or just provide customer with info.
When using the pk/fk name method, as the clerk scrolls through customer names to locate the desired customer, response is immediate. Whereas when using the pk/fk id method, response time lags, even with supported indexing, because the engine has to jump to different locations in the transactions table to locate the corresponding group of transactions belonging to each customer as clerk scrolls through each customer name in the master!
So, it seems like having the customer's transaction rows grouped together and in the same sorted order as the customer rows allows the indexing to locate the transactions quicker as opposed to having to jump all over scattered groups of each customers transactions. If each customer could remember their customer i.d. number, then my issue would be academic, but in the realworld, we even gave each customer an i.d. card with their customer number on it, but most of them lost their cards!
Here's an example of the daily reorg executed every morning before pawnshop opens for business:
{ISQL-SE (customer and transactions table reorg - once-daily, before start of
business, procedure}
unload to "U:\UNL\CUSTOMERS.UNL"
select * from customer
order by customer.pk_name;
unload to "U:\UNL\TRAN_ACTIVES.UNL"
select * from transaction where transaction.status = "A"
order by transaction.fk_name, transaction.trx_date;
unload to "U:\UNL\TRAN_INACTIVES.UNL"
select * from transaction
where transaction.status != "A"
and transaction.trx_date >= (today - 365)
order by transaction.fk_name, transaction.trx_date desc;
unload to "U:\UNL\TRAN_HISTORIC.UNL"
select * from transaction
where transaction.status != "A"
and transaction.trx_date < (today - 365)
order by transaction.trx_date desc;
drop table customer;
drop table transaction;
create table customer
(
id serial,
pk_name char(30),
[...]
)
in "S:\PAWNSHOP.DBS\CUSTOMER";
create table transaction
(
fk_name char(30),
ticket_number serial,
tran_type char(1),
status char(1),
trx_date date,
[...]
)
in "S:\PAWNSHOP.DBS\TRANSACTION";
load from "U:\UNL\CUSTOMERS.UNL" insert into customer {>4800 nrows}
load from "U:\UNL\TRAN_ACTIVES.UNL" insert into transaction; {500:600 nrows avg.}
load from "U:\UNL\TRAN_INACTIVES.UNL" insert into transaction; {6500:7000 nrows avg.}
load from "U:\UNL\TRAN_HISTORIC.UNL" insert into dss:historic;{>500K nrows}
create unique cluster index cust_pk_name_idx on customer(pk_name);
create cluster index tran_cust_idx on transaction(fk_name);
{this groups each customers transactions together, actives in
oldest trx_date order first, then inactive transactions within the last year in most
recent trx_date order. inactives older than 1 year are loaded into historic
table in a separate database, on a separate hard disk. historic table
optimization is done on a weekly basis for DSS queries.}
create unique index tran_ticket_num_idx on transaction(ticket_num);
create index tran_trx_date_idx on transaction(trx_date);
create index tran_status_idx on transaction(status);
[...;]
[grant statements...;]
update statistics;
If you have time, I CHALLENGE ANYONE TO TEST THIS!.. It's more noticeable when you have a large table.