One of the most common problems I run into when creating any information system is the fact that people go by so many different names. Someone named "Bill Smith" may go by "Will Smith","William Smith", "Smith, Will", etc... If say, I wanted to write an application to link blog posts to authors, I would have to account for all those names.
My question is: What approaches do you take to keep consistent data throughout your application. How do you structure your database so that you can refer to a single identifier to locate all those names? What UI approaches do you take make sure that people enter in names in a consistent manner?
As long as you have a unique id for each user (which is not their name) you can have a table that maps name variations to a unique id, and then associate each post with that unique ID.
(Table mapping names to UIDs)
Name UID
Robert S 123456
Bob S 123456
Bert S 123456
Darren 987654
(Table with post information, including author's UID)
Title Author ...
Post 1 123456
Post 2 123456
Post 3 987654
(Table with author information)
UID Preferred Name Webpage ...
123456 Robert Smith http://www.robert.com
987654 Darren Jones http://www.jones.com
It's probably a good idea to accept only one name from your user, and allow them a "nickname" or a "public name". That gives them the freedom to have a legal name, perhaps for mailing or billing, and a public-viewable name for interaction on your site.
Beyond that, I don't think I would allow my users to have multiple names, unless my system required it. If I did, I'd split it up into two tables:
Users:
userid (ex: 1821)
UserNames:
userid (ex: 1821)
firstName (ex: Jonathan)
lastName (ex: Sampson)
In addition, you could add a field in the usernames table called 'isPrimary'. This would be a boolean value that will tell you which name to treat as the primary name for the user. This is similar to how wikipedia store a history of data/changes. They keep all, but mark which is "active", or in your case "primary".
It sounds to me like you are trying to use their name as a primary key or UID. This is the wrong way to go. You should have a seperate UID as the primary key, then the name can be whatever you want, and you can even have a list of alternate names.
The real problem happens when you have multiple applications, and each one has their own schema for user information. The billing system might have "Will Smith"; the payroll system might have "William Smith"; the claims system might have "Willie X. Smith". All are really the same person. What do you do? It's a huge issue for stovepipe, legacy apps.
I agree with the first 3 posts on how to structure your schema.
In regards to the UI I would allow a field for the persons legal first,middle and lastname which should change very rarely.
Then allow nickname(s) depending on your application requirements.
Having their full legal name can come in handy for billing/financial/HR situations too.
You could always make a AKA table, where you could have the prefer name to AKA name. So if someone uses the name Bill, you can always replace it with William.
I have never personally used this concept for names, but I do support a project that does something similar with Movie Titles, which can varied for different countries.
Related
I was actually told this is true, and if so, then I must be missing something. If I make an intent with an employee custom entity, then I make another intent that also uses the employee entity, do I have to enter all the employees again? One for each intent?
I made an intent called who-is. The user basically asks "who is {employee}" or "tell me about {employee}". I entered about 5 different phrases. However, I used a lot of employee names to teach luis what an employee is, so I have the same phrases repeated a lot of times to get all the names. So far so good.
Then I made another intent to get the number of direct reports for an employee. Do I have to teach that intent the employee names again? If so, this is a hassle and I must be missing something. We may have tens of different intents that need an employee and tens of sample employees to teach luis.
In Luis Entity works on whole app, so if you have mapped one entity in one intent and if you have similar words in other intents it will be mapped automatically.
I have created contact from account(primary contact) through quick create form,if I am creating contact second time on same account(Primary contact), "Last name" field filled as selected contact's First Name+ Last Name in Quick create form.
can anyone tell me what could be the reason?
any help would be highly appreciated.
Regards,
Amar
This is because CRM sees the primarycontactid value as more of a user trying to find a contact which is also the natural flow of things in CRM. You create an account, either you assign a known primary contact or enter a search term which does not resolve to an existing contact, in which case it makes a lot of sense to auto-map the lookup search term to the last name on the contact.
Although the behavior makes much more sense if the lastname was pre-populated with the look up search term if the contact was non-existent, the downside effect of it overweighs the actual functionality, especially considering the natural flow of things.
We are working on implementing the FHIR API in a veterinary health care system. One question that has come up is which resource type we should be using for the owner of the animal (patient). In the context of the animal it is easy to see that the owner information can go into the contact of the Patient resource.
However, an animal owner is quite often referenced outside the context of an individual patient. So that leads me to RelatedPerson. The description of the RelatedPerson resource gives an example of "The owner or trainer of a horse", so it seems it might fit. However, one big issue with this is that a RelatedPerson can only be linked to a single patient. The relationship between animals and owners in the veterinary domain is many to many. So an owner often has more than one animal.
This issue led me to the Person resource. This at least gives a way to have multiple Patient's (animals) belonging to one Person (owner).
In either case we'll have to add a "percentOwnership" attribute as an extension to the resource since an animal can potentially have multiple owners.
If this is the way we should do it (using the Person resource), my next question is how would one search using the API for all Patient's linked from a given Person? If we used the RelatedPerson (which is probably not workable due to the limitation mentioned above), it seems like this search would use the relatedPerson compartment to search. However, there doesn't seem to be a person compartment in the spec.
Summary:
What resource to use for the owner of an animal?
How to search for all animals belonging to a particular owner?
If you just want contact information, then Patient.contact is fine. If you're interested in the owner as a potential actor (information recipient, informer, performer, etc.) then RelatedPerson will be necessary. However, RelatedPerson is specific to a particular Patient's record (i.e. you'll have a distinct RelatedPerson instance for each animal). To link all of the RelatedPerson instances together and say "this is the same person", you'd use Person. To query, you'd query on Person where link matched one of the desired RelatedPerson records. Then you'd need to do an include of Person.link and RelatedPerson.patient to bring back all of the animals
I realize this is quite specialized question(about Oracle's eTRM + eBusiness suite ) I'm trying to figure out the meaning of this
REMIT_TO_ADDRESS_ID NUMBER (15)
which comes from the AR.RA_CUSTOMER_TRX_ALL table . The reason is that in a query I have, there's a bug like this where we say:
LEFT OUTER JOIN ra_customer_trx_all
ON rct.REMIT_TO_ADDRESS_ID = acct.REMIT_TO_ADDRESS_ID \
(acct is from the table hz_cust_acct_sites_all , by the way)
My guess is that REMIT_TO_ADDRESS_ID is some kind of meta-data?
I really appreciate any pointers/tips. Thanks.
Little bit rusty, but did Oracle Apps for 10 years. From your question I understand that you are new to Oracle Apps technology. ra_customer_trx_all stands for:
"RA" => "Accounts Receivables" also known as "AR" (something you sell and want money for),
"customer" says it,
"trx" => "transactions",
"_all" => all records across all organisations (multi-org).
It is a nice table with lots of features :-)
When in Oracle Apps a column is listed with name ending in '_id' and data type of number(15, 0), it is generally a reference to a row in another table. Depending on the Oracle Apps module, you will sometimes find also a foreign key constraint. But generally most Oracle Apps modules rely on the frontend to enforce referential integrity.
So remit_to_address_id refers to another table. In this case address information. Also, the naming of the column tells us that the referred row is used in a special way (role) namely as "remit to".
You might want to join it to the address table of Apps. When you do so, please check the columns listed in the indexes. The multi-org field org_id may be listed first (probably not in AR). If you forget them, you will still have good results since the ID-s are unique across the system, but the index might not be used.
For end user queries, I generally recommend to use the multi-orged view instead of the _all table. This ensures that users only see their current organisation. Remember that you need to set up the client_identifier session variable (if I recall correctly) to store the current organisation ID in.
I hope this helps you.
I have no knowledge of eTRM, or any other Oracle business application.
That said, as a complete wild guess, I would say that the REMIT_TO_ADDRESS_ID is the ID of an address that a payment of some kind is sent to, and that the address is optional (thus the outer join). So, in an Accounts Payable system, you may have a vendor, who has a normal business address. But when you send actual monies, they have an optional Remit To Address, and the payment is sent there instead of the normal business address.
I am working on an application using the Yii framework, so its MVC-style. I have a record type "person", which contains information about membership. Members come in two types: adults & kids. With the kids, SOME of them we know their ages and they are divided into age groups. The age groups have names (e.g. "8 & Under".) So as an example, John Smith & Jane Smith have two kids Jimmy Smith and Janey Smith. Janey wants to do a soccer program, so we need to know her age and put her in an age group. Jimmy is doing arts & crafts so we don't need to know his age because his program isn't divided by age. And we don't ask for the ages of the adults.
So the question: I have a few choices about how I store this. I could:
put an int agegroup field in the person table, and define the values as CONST values when I define the model for people (and probably have a special value for "undefined" - for the adults. Then I need to write a little code to translate the const value to descriptive labels.
put an agegroup field in the person table as above, but also add another table in the database with the reference data. Enforce referential integrity to this new table. This raises another question - should I create a dummy record in the reference table for cases where I don't know/care about the agegroup, or should I allow null values in the people table agegroup field?
others?
I know I can make either of these work. But I would welcome advice on which approach is preferred and why!
For the possibility of future expansion (you may want to create, delete, and modify age groups) I would recommend having an age group table consisting of a beginning age, an upper limit age, and a description. You can leave the beginning age as null to signify a 'up to n'/'n and lower' group, or vice versa with the upper limit. The primary key would consist of the beginning and upper age together (composite key.)
Then, in your 'activities' table, you would need to enforce a reference to the age group table (even if just to a 'null/null' or 'all ages' record.) This way you can create activities for age groups -- 8 and under soccer, 12 to 14 soccer, all ages crafts, 18 and older art, and so on.