search

jordanbrown0 / reg3

REG.PRG version 3
Other
2 stars 0 forks source link

"Master" integration #3

Open jordanbrown0 opened 4 years ago

jordanbrown0 commented 4 years ago

v2 looks up previously-known people from a MASTER table and fills the data in. It also retains the ID from MASTER so that (in theory) information from the current convention can be easily used to update MASTER.

v3 doesn't have a separate step for entering the new member's name, making it unclear when the search would happen. Also, v3's standard search mechanism is a free-text search, not very compatible with being the first step in entering the name.

Perhaps (P) should search both current members and previous messages, allowing you to select "add new".

jordanbrown0 commented 4 years ago

Maybe (N)ew would initially ask for first/last, offer MASTER records, then continue to the full editor.

Keep MASTER in memory like a normal table? Or have a different DBMS mode for it? Probably want to have it in a separate DB. Read MASTER directly from DBF? Use full replication mechanism for MASTER sync?

jordanbrown0 commented 3 years ago

Some thoughts and options:

  1. Don't do master.
  2. v2 style - copy from master on "new".
  3. Duplicate contact info between the two tables, so that master is maintained, and everything is still available out of "members".
  4. Proper normalization, with the contact info only in the "master" table.

Any answer that doesn't include the contact info in "members" makes export to other systems uglier. It couldn't be just 1:1 export through an agnostic exporter; the exporter would need to do a join.

Synchronizing master between systems and conventions would be straightforward, using the existing resync mechanism and just exporting that one table.

On the other hand, if it's necessary to copy data from master to members on resync, that would be a brand-new kind of operation, a bulk operation affecting two tables. (But maybe not awful, since it's a simple key.)