How to Convince Programming Team to Let Go of Old Ways?

Question

This is more of a business-oriented programming question that I can't seem to figure out how to resolve. I work with a team of programmers who have been working with BASIC for over 20 years. I was brought in to help write the same software in .NET, only with updates and modern practices. The problem is that I can't seem to get any of the other 3 team members(all BASIC programmers, though one does .NET now as well) to understand how to correctly do a relational database. Here's the thing they won't understand: We basically have a transaction that keeps track of a customer's tag information. We need to be able to track current transactions and past transactions. In the old system, a flat-file database was used that had one table that contained records with the basic current transaction of the customer, and another transaction that contained all the previous transactions of the customer along with important money information. To prevent redundancy, they would overwrite the current transaction with the history transactions-(the history file was updated first, then the current one.) It's totally unneccessary since you only need one transaction table, but my supervisor or any of my other two co-workers can't seem to understand this. How exactly can I convince them to see the light so that we won't have to do ridiculous amounts of work and end up hitting the datatabse too many times? Thanks for the input!

Answer 1

Do they intend to use the database at all?

Sounds like they are only interested in using the flat text files...

Perhaps you can try to present your argument like this:

THE CURRENT SYSTEM (their way) using flat files

(1)

Flat file that contains the latest and greatest transaction shall have the field columns as a minimum:

cust id # ,order # ,order dateTime , and possibly some other redundant data from customer and order tables. Note that any redundant info kept requires consistency maintenance as normalization is in danger

for every redundant column kept

(2) must sequentially process the records linear search style to find the customer id# in question

(3) On new order, the linear process must be done again so as to update the customer's current order

and the old record must be appended to the history file. If the history file is sorted in any way, then

those records must be loaded into memory and sorted again, perhaps via 1-pass insertion sort as

only one record needs to be added.

so your fetch is order O(n) and your updates are also Order O(n) best case <-- 1 pass insertion sort

but don't count on the best

OPTION 2: historical database kept, with flat file containing only the customer ids and the

latest and greatest order #

(1) Flat file containing the latest and greatest orders contain only two field columns:

the customer id# and the order # of the latest order. Since these field columns contain

no redundant info, there is nothing to worry about consistency, assuming the database is

normalized

(2) still must linear search the records for the customer id #, but the order # can be updated

on the fly and the file rewritten as you are only changing 1 records. LInear operation

(3) the new order is added to the historical database and an flat file is updated per step (2)

the fetch operation is O(n)

OPTION 3 ( your way) : One single transaction data table with no flat files involved

You must design a query to retrieve the latest and greatest order record probably

using a JOIN or nested query

something like this:

SELECT * from ORDER

JOIN (SELECT order id#, MAX( order_date ) date

FROM ORDER

GROUP BY customerID

) x ON ( CUSTOMER.customerID = ORDER.customerID AND customer.customerid = order.customerID )