Modifying field via update query versus using expression?

[Bcanfield83]

This is a general question when it comes to querying data in a table. I have a specific example though to illustrate my question.


Within my database is a table that contains employee information, e.g.: UserID, Name, Job Title, etc.
This is an import of the company LDAP directory, thus the table is called tblLDAP. By default, certain fields in LDAP contain additional hierarchal information such as the Organization Unit (ou), etc.
One specific field in the table is called "manager". When importing LDAP, it comes through like this:

uid=jdoe, ou=People, o=MyCompany, c=US

However, all I truly want is the portion that immediatelly follows "uid="- which would simply be "jdoe" in this example.

One approach is to run an update query after the LDAP data is imported into the table, e.g.:

UPDATE tblLDAP SET tblLDAP.manager = Mid([manager],5,(InStr(1,[Manager],","))-5);

This uses the "MID" function to essentially extract the UID substring and updates the "manager" field for every record in the table (over 10,000) accordingly

But I could also create a SELECT query and use that same "MID" function as an expression, e.g.:

SELECT tblLDAP.uid, Mid([manager],5,(InStr(1,[Manager],","))-5) AS Manager_UID
FROM tblLDAP;

This would still show the intended substring without actually updating the data in the source table (tblLDAP).
So I guess my question is, is there a "right" or "wrong" way to do it - specifically from an overall performance standpoint? The end result is the same, though obviously with the second approach, it precludes me from needing to run an "UPDATE" query upon importing the data into tblLDAP. This query only takes a few seconds to run even for all 10,000+ records, but perhaps it would still make more sense to use an expression to show the data in the intended way versus actually taking the step to update it in the table?
This field, as well as several others in tblLDAP, is pulled over in many other 'SELECT' queries (and related reports) in the database, so it seems like there would have to be a preferred way of doing it.. but perhaps it's 6-to-1 half dozen to the other and I'm simply overthinking it!

[Micron]

This field, as well as several others in tblLDAP, is pulled over in many other 'SELECT' queries (and related reports)

From a puristic point of view, it makes more sense to update once when there are many operations that have to parse the info, but if the maximum speed benefit in the worst case is nearly negligible, then I could also postulate that the whole thing is a non issue since you cannot accumulate the seconds you'd save over all the operations if they're not run concurrently. Sometimes something like this is a balance sheet. Reasons for splitting on one side, for not on the other. Then you decide if there is a payoff for doing so.

Again, it is usually better to parse that data once and be done with it rather than have to use built in functions (Left, Mid, etc) for every situation, but that has to be measured against whatever is involved in doing so.

[CJ_London]

my own philosophy when bringing in data from other systems is to leave it unchanged as it provides a path back if required for reconciliation or other reasons -for example tracking changes. Most times data pulled from enterprise systems will be denormalised so the usual process would be to normalise it - at this point you could then apply your mid function, whatever, to store data as you want it.