How to store and retrieve information

[schoemr]

Hi, so I have an argument with my lecturer. After login I retrieve the user information from the database e.g. FistName, Lastname, PhoneNumber etc. I then use this information all over in the application e.g. Message with the person's name etc.

So what is the best way to store and use this information?

1) Store as global variables in module
2) Store in session
3) Store in cache?

[vbdotnut]

I reckon this depends what he is concerned about. If hes not concerned about it being in the DB but then concerned you are using it in an app, then hes not a very good lecturer, that would be my answer to him/her.

after that it makes no difference how you temporarily store the data, other than the time it takes to do so. Obviously you wouldn't write it to settings or any file

I use the Environment.Username to communicate to the user and also use that to link arbitrary application options, such as storing user filter strings and configuration options.

Also, in the UK and perhaps some other Countries it is best NOT to even include a phone number at all anywhere at any time period. Leave that entirely up to HR 100%

[Zvoni]

I reckon this depends what he is concerned about. If hes not concerned about it being in the DB but then concerned you are using it in an app, then hes not a very good lecturer, that would be my answer to him/her.

after that it makes no difference how you temporarily store the data, other than the time it takes to do so. Obviously you wouldn't write it to settings or any file

I use the Environment.Username to communicate to the user and also use that to link arbitrary application options, such as storing user filter strings and configuration options.

Also, in the UK and perhaps some other Countries it is best NOT to even include a phone number at all anywhere at any time period. Leave that entirely up to HR 100%

I don't think, that has anything to do with OP's description, especially that Environment-Thing.

In any ERP-System worth its salt, you have "sensitive" Data (Phone-No.) so that is not really out of left field for that sample-database/application

I think OP's question was more in general, how/where to store/keep the Data while he's working with the Program.

To OP's question: I would "blackbox" it as far as it is possible/viable.

"Cache" implies a file written to disk: No-Go --> or do you mean something else with "cache"?
"Session" sounds like a Web-Application --> No Idea

Bottom Line: "Data" must be destroyed when logging out

[schoemr]

Also, in the UK and perhaps some other Countries it is best NOT to even include a phone number at all anywhere at any time period. Leave that entirely up to HR 100%

This is Africa, we don't have time for that first world nonsense 🙂

Over here HR will come pull you out of your house and slap you around a bit if you didn't go to work, nevermind worry about your phone number

But I get what you're saying.

Zvoni, yes that is what I'm also thinking. Both those methods is writing to the server?

When the user exists all the loaded information must be gone. My lecturer thinks if I want to say Msgbox("Welcome Mary") I should get Mary's name from the database each and every time. Me think you only get that information once when you login. Otherwise you keep calling the database for information over and over again...

[vbdotnut]

I should get Mary's name from the database each and every time

That is just silly.

My point was, chances are Mary can be found locally from the machine environment, but if that is not satisfactory and you have to get this from DB then I would set a Form level variable(s) with only columns that will be consumed, which I would not opt for any sensitive data at all. No matter what block/module/class you put this it lives in memory and is not accessible by anything but the running application and that would be machine-code... like a bunch of bytes, so I really dont know what point hes trying to make. What is the reasoning he has provided?

[Zvoni]

That is just silly.

My point was, chances are Mary can be found locally from the machine environment

Not necessarily.

I know of lot of systems, where the UserName for Login doesn't has to do anything with the "real" Name of the User.

Example: Active Directory
In the company i work for, users can have Windows-login-usernames whatever they want, it still shows "FirstName, MiddleName Lastname" because it pulls out the Data from the Database in the AD

[schoemr]

What is the reasoning he has provided?

I didn't write down everything in details because in my head i was already arguing with him........

I have:

1) Reduced memory usage: if you store info in a global variable the memory will be reserved for the entire life of the program
2) Improved scalability: As info in db grow so does the amount of memory required
3)Better security: If sensitive info such as passwords is stored in gv's it can be vulnerable to security risks e.g. malicious user can access info and cause harm
4) Easier maintenance: If you need to change the information in the db then you have to update all your gv's in multiple places and can make maintenance difficult especially in large applications/databases

That is why (according to him) it is better to only retrieve the information when needed.

So now it is okay to "hit" the database a million times for info you can get in once call??

[Shaggy Hiker]

Assuming this is a desktop application (I wasn't clear about that from the first post, as session state sounds more like web), I wouldn't worry about storing a few items in memory. Memory is cheap. Since the dawn of computing, people have generally traded memory for performance, and this is another case of doing that. You certainly COULD go to the DB to get the information every single time. That would come at a performance cost, though perhaps not one that anybody would really notice. If you were doing it frequently, it would add up, but computers usually spend most of their time waiting for the meat bag at the keyboard to get around to doing something, so you likely wouldn't see the cost.

Still, that would be pretty absurd. Alternatively, if you were to store the information in a variable, no matter whether it be local or global, then it is inaccessible outside of the program. Technically, that isn't quite true. It might linger in memory even after the program has closed. Depending on the hardware, it might even be retrievable from RAM even after the computer has been turned off. But none of that is truly plausible. If anybody has sufficient access to your computer to be able to take advantage of any of that, then you have bigger problems than a bit of Personally Identifiable Information.

Therefore, I'd store it in a variable.

[dbasnett]

Based on the little info provided I'd write a class,

    Public Class UserInfo
        Private _FirstName As String
        Public ReadOnly Property FirstName As String
            Get
                Return Me._FirstName
            End Get
        End Property

        Private _LastName As String
        Public ReadOnly Property LastName As String
            Get
                Return Me._LastName
            End Get
        End Property

        Public Sub New(something_to_access_DB_with As Object)
            'retrieve the user information from the database and set variables
            ' e.g. _LastName
        End Sub

    End Class

and then create an instance of the class and use it everywhere.

[schoemr]

Thank you everyone

Memory is cheap.

kkrrrr!! ohhhh!!!!! definitely not according to some people!! It is more expensive than gold, especially CPU memory

thank you dbasnett, that is actually neat

[wes4dbt]

I think there are times when retrieving data each time when needed is the correct approach. In multiuser systems it may be the best way to insure your working with valid data. Some data lends itself to being modified more than others. Something like "Company Name" probably isn't going to change very often. Things like inventory are more problematic and I'd retrieve and save that kind of information often. Some USER information could also change, like Account Balance.

I'd say both method have there place.

[vbdotnut]

If he wants to argue about memory usage over a borderline immeasurable amount of local machine capacity, tell him you are happy to consume the local resource once over spreading the same amount of bytes through the topology and server resources at an undetermined rate, but in both cases is such an insignificant measure and either approach is not going to cripple your application by any means.

Scalability... again, theres nothing complex about this, theres like 2 parts to the flowchart where part one is run the app...

Better security, well like Shaggy said, as long as there was a power source there's potential you could access this near impossible address. I am no hardware expert, but I am envisioning myself fishing for a goldfish in the Pacific thats swimming in the Atlantic, and if by chance I caught it I would need to somehow disassemble it in an exact way in order to eat it.

Which leaves you with maintenance, and thats a thing no matter what. This is the reason project managers exist, good ol documentation.

[dday9]

Personally in my project's startup events, I will create a property under the MyApplication namespace that represents the global record (as a POCO). This works similarly to PHP's $_SESSION if you are familiar with it.

A typical use case would be for a user to login to the application and then on successful login I store the record there. Then when the user creates a record I set my audit log fields using something like:

MyRecord.CreatedBy = My.User.UserId

This works well for me and haven't run into any issues.

[peterst]

public class SomeOperations
  private _loggedUser as LoggedUser
  private _operationsReader as IOperationsReader
  private _operationsWriter as IOperationsWriter
 
  public sub New(
      loggedUser as LoggedUser,
      operationsReader as IOperationsReader,
      operationsWriter as IOperationsWriter)
    
    _loggedUser = loggedUser
    _operationsReader = operationsReader
    _operationsWriter = operationsWriter
  end sub
 
  public sub DoThisOrThat(.. some params ..)
    ...
    ...
    _operationsWriter.CreateSomeObject("operation",
      _loggedUser.UserName,
      _loggedUser.Email)
  end sub
end class

Inject all dependencies into the objects. Do not rely on global variables. Or you will get in troubles sooner or later...