This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
admin:indexing:powersearch:sql [2011/01/21 04:51] 127.0.0.1 external edit |
admin:indexing:powersearch:sql [2016/06/28 22:38] (current) |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ~~NOTOC~~ | ||
+ | |||
{{page>:top_add&nofooter&noeditbtn}} | {{page>:top_add&nofooter&noeditbtn}} | ||
Line 9: | Line 11: | ||
**[[admin:indexing:powersearch:sql|SQL]]** | | **[[admin:indexing:powersearch:sql|SQL]]** | | ||
[[admin:indexing:powersearch:optimization|Optimization]] | | [[admin:indexing:powersearch:optimization|Optimization]] | | ||
+ | [[admin:indexing:powersearch:custom|Customization]] | | ||
[[admin:indexing:powersearch:tips|Tips]] | [[admin:indexing:powersearch:tips|Tips]] | ||
Line 16: | Line 19: | ||
==== The SQL Behind PowerSearch ==== | ==== The SQL Behind PowerSearch ==== | ||
+ | |||
+ | === The POWERSEARCH Option === | ||
+ | |||
+ | In most scenarios, the key to implementing PowerSearch is to simply use the POWERSEARCH option on a SELECT statement. Alternatively, the SET POWERSEARCH ON command can be used to automatically activate PowerSearch for all queries on that connection. | ||
+ | |||
+ | <code> | ||
+ | > select name from individuals where name = 'William Cooke' with powersearch; | ||
+ | |||
+ | NAME | ||
+ | -------------------------------------------------- | ||
+ | BILLIE E COOK | ||
+ | MR. WILL COOK | ||
+ | </code> | ||
+ | |||
+ | === The USAGE Clause === | ||
+ | |||
+ | The POWERSEARCH option works hand-in-hand with the data stored in the Omnidex Environment File. To use POWERSEARCH, administrators add a context to columns telling Omnidex what they contain. For example, a column named NAME may have a character datatype, but that alone is not enough to tell Omnidex what the column contains. Moreover, Omnidex cannot look to the column name, as there are many different conventions for naming columns. Administrators add a USAGE clause that identifies the contents as given names, as shown in this example: | ||
+ | |||
+ | <code> | ||
+ | create table "INDIVIDUALS" | ||
+ | physical "dat\individuals.dat" | ||
+ | ( | ||
+ | "INDIVIDUAL" CHARACTER(12) omnidex, | ||
+ | "HOUSEHOLD" CHARACTER(12) omnidex , | ||
+ | "NAME" CHARACTER(50) quicktext usage "NAME", | ||
+ | "GENDER" CHARACTER(1) omnidex bitmap, | ||
+ | "BIRTHDATE" ANSI DATE omnidex, | ||
+ | "PHONE" CHARACTER(14) omnidex usage "PHONE", | ||
+ | "EMAIL" CHARACTER(60) quicktext usage "EMAIL", | ||
+ | constraint INDIVIDUALS_INDIVIDUAL_PK primary ("INDIVIDUAL"), | ||
+ | constraint INDIVIDUALS_HOUSEHOLD_FK foreign ("HOUSEHOLD") references "HOUSEHOLDS", | ||
+ | constraint INDIVIDUALS_GENDER_FK foreign ("GENDER") references "GENDERS", | ||
+ | ) | ||
+ | in "simple.xml"; | ||
+ | </code> | ||
+ | |||
+ | Omnidex provides many different usages to meet the general needs of most applications; however, administrators can add custom usages to meet the specific needs of their application. The general usages provided by Omnidex include: | ||
+ | |||
+ | * SALUTATION | ||
+ | * FIRST_NAME | ||
+ | * MIDDLE_NAME | ||
+ | * LAST_NAME | ||
+ | * NAME | ||
+ | * COMPANY_NAME | ||
+ | * STREET_NUMBER | ||
+ | * STREET_DIRECTION | ||
+ | * STREET_NAME | ||
+ | * STREET_TYPE | ||
+ | * UNIT_TYPE | ||
+ | * UNIT_NUMBER | ||
+ | * CITY | ||
+ | * STATE | ||
+ | * COUNTRY | ||
+ | * ZIPCODE | ||
+ | * STREET_ADDRESS | ||
+ | * CITY_STATE_POSTAL | ||
+ | * ADDRESS | ||
+ | * PHONE_AREACODE | ||
+ | * PHONE_PREFIX | ||
+ | * PHONE_SUFFIX | ||
+ | * PHONE | ||
+ | |||
+ | * ... plus, you can add any custom usages needed for your application. | ||
Line 31: | Line 97: | ||
{{page>:bottom_add&nofooter&noeditbtn}} | {{page>:bottom_add&nofooter&noeditbtn}} | ||
+ |