Difference between revisions of "RightFielder API:Best Practices"

From Melissa Data Wiki
Jump to navigation Jump to search
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
[[RightFielder Object|← RightFielder Object]]
  
 
==Order Input Data in a Logical Order==
 
==Order Input Data in a Logical Order==
BP_RFOB_001
+
BP_RFOB_001  
 
 
 
  
 
If your database structure has columns in a non-intuitive order, reorder the respective columns
 
If your database structure has columns in a non-intuitive order, reorder the respective columns
Line 19: Line 18:
 
   
 
   
 
==Maintain Hard Delimiters (and Placement)==
 
==Maintain Hard Delimiters (and Placement)==
BP_RFOB_002
+
BP_RFOB_002  
 
 
 
  
 
If the the table to be processed originally had hard delimeters (tab, pipe, crlf), maintain or restore
 
If the the table to be processed originally had hard delimeters (tab, pipe, crlf), maintain or restore
Line 35: Line 32:
 
   
 
   
 
==Only Process required Fields==
 
==Only Process required Fields==
BP_RFOB_003
+
BP_RFOB_003  
 
 
 
  
 
If the table contains un-needed fields or proprietary data types, do NOT add them to the input data
 
If the table contains un-needed fields or proprietary data types, do NOT add them to the input data
Line 47: Line 42:
 
recommended input:  FULLNAME | ADDRESS | CSZ
 
recommended input:  FULLNAME | ADDRESS | CSZ
  
note: if the BANKACCOUNT mumbers are always formatted in a consistent manner, create a
+
note: if the BANKACCOUNT numbers are always formatted in a consistent manner, create a
  
 
SetUserPattern for accurate processing.
 
SetUserPattern for accurate processing.
  
 
   
 
   
==Maintain a consistant design of Source Data==
+
==Maintain a consistent design of Source Data==
BP_RFOB_004
+
BP_RFOB_004  
 
 
 
  
 
Good input design. How is the data to be RightFielded collected? If you are developing a user interface
 
Good input design. How is the data to be RightFielded collected? If you are developing a user interface
Line 73: Line 66:
 
identify an unknown data format - like a part number or an account number for example - and  
 
identify an unknown data format - like a part number or an account number for example - and  
  
will place it in its own category. See the RightFielder documentation and mdRightFielder.cfg eaxample for more details.
+
will place it in its own category. See the RightFielder documentation and mdRightFielder.cfg example for more details.
  
 
   
 
   
Line 80: Line 73:
  
 
   
 
   
==Over-ride the distributed Data Files for keywords with alterante meanings==
+
==Over-ride the distributed Data Files for keywords with alternate meanings==
BP_RFOB_006
+
BP_RFOB_006  
 
 
 
  
 
Data File override. RightFielder allows you to add or override the behavior of known keywords contained
 
Data File override. RightFielder allows you to add or override the behavior of known keywords contained
Line 96: Line 87:
  
  
==Supply data beyond minimun input==
+
==Supply data beyond minimum input==
 
BP_RFOB_007
 
BP_RFOB_007
  
Line 112: Line 103:
  
 
Example, more data: sven miller | anytown, ma 01234
 
Example, more data: sven miller | anytown, ma 01234
 +
 +
[[RightFielder Object|Back to RightFielder Object Main Page]]

Latest revision as of 18:18, 18 November 2019

← RightFielder Object

Order Input Data in a Logical Order

BP_RFOB_001

If your database structure has columns in a non-intuitive order, reorder the respective columns

to represent a more common order (think of the order for a mailing label). This will help RightFielder

process more accurately.

Example Table layout: ADDRESS FULLNAME CSZ

Recommended Order: FULLNAME ADDRESS CSZ



Maintain Hard Delimiters (and Placement)

BP_RFOB_002

If the the table to be processed originally had hard delimeters (tab, pipe, crlf), maintain or restore

these delimiters before processing with RightFielder. This will help Right Fielder process more

accurately.

Example Table layout: FULLNAME FULLNAME2 ADDRESS CSZ

recommended structure: FULLNAME | FULLNAME2 | ADDRESS | CSZ


Only Process required Fields

BP_RFOB_003

If the table contains un-needed fields or proprietary data types, do NOT add them to the input data

to be processed (unless you have created a SetUserPattern to handle them).

Example Table layout: FULLNAME | BANKACCOUNT | ADDRESS | NEIGHBORHOOD_DESCRIPTION | CSZ

recommended input: FULLNAME | ADDRESS | CSZ

note: if the BANKACCOUNT numbers are always formatted in a consistent manner, create a

SetUserPattern for accurate processing.


Maintain a consistent design of Source Data

BP_RFOB_004

Good input design. How is the data to be RightFielded collected? If you are developing a user interface

with edit controls for input, design for multi-row input which can be padded with hard delimiters by

your application.


Customize handling for Proprietary data types

BP_RFOB_005

If you have proprietary data embedded throughtout your source data, create a

valid regular expression examples for the SetUserPattern method. This helps RightFielder

identify an unknown data format - like a part number or an account number for example - and

will place it in its own category. See the RightFielder documentation and mdRightFielder.cfg example for more details.




Over-ride the distributed Data Files for keywords with alternate meanings

BP_RFOB_006

Data File override. RightFielder allows you to add or override the behavior of known keywords contained

in the default data file mdRightFielder.dat. Open the mdRightFielder.cfg file in a text editor for instructions,

syntax and examples on how to do this.

Example: Xyz Smith. Depending on the rest of the input tokens, it may not be recognized as a name, but

adding 'Xyz' as a name in the cfg file will help process records with previously undefined tokens.


Supply data beyond minimum input

BP_RFOB_007

One of the previous Best Practices recommends against processing too much input. Isn't this suggestion contrawise?

No, configuring RightFielder is a fine line between not enough input and too much input.

Since tokens can have multiple meanings, input data will be more accurately fielded if a minimum input

is met. While no strict standard can be applied, an input that represents a true contact record should be

expected to process more accurately than an input record with a single input token.

Example, less than minimum input: sven miller

Example, more data: sven miller | anytown, ma 01234

Back to RightFielder Object Main Page