Link to home
Create AccountLog in
Avatar of drewmore44
drewmore44

asked on

Where to to store objects/variables "permanently"

I am writing a program that tracks the availibility of all employees at a restaurant for each shift of the week. I have a class called Employee, which creates a separate object for each employee, each of which has as attributes a name, job title and dictionary in which the keys are the "ID's" of different shifts (e.g. monAM, monPM, tueAM...) and the value for each key is an as an integer that represents their availability for that shift. (1 for shifts they can't work, 2 for shifts they can work and 3 for shifts they want to work).

There is a GUI with which the user inputs the availability integers for each shift for each new employee. My question is: How/where do I store the employee objects (with updated availability integers) so that they can be accessed every time the program runs? I'm guessing this is going to have to involve exporting some sort of (text?) file when the program closes (or after the "roster" is updated) and importing that file the next time it runs. However, I have absolutely no idea about how to go about doing that...


Also, although this is somewhat unrelated: I have been going back and forth between using a dictionary to store availability integers as values (with keys being the shift identifiers), and creating a separate variable for each shift for each employee. What would be the advantages/disadvantages of each choice? Given that I want these values to be able to be displayed/ updated in entry boxes in a GUI, it seems like the latter choice (separate variables) would be simpler, or is it easy to connect entry widgets to particular key/value pairs in a dictionary?
Avatar of pepr
pepr

A general answer is database. However, it is only a fancy name for a sufficiently well organized disk space.

If the problem seems to be too complex, split it to more of simpler ones. If the data structure is too complex, split it to more connected data structures. If the algorithm seems too complex, wrap the parts of it to the functions. If an object functionality is too complex, let some intermediate object (an agend) solves the part of the problem.

If some implementation is unclear now, wrap it to the object/function with a clear interface. This way, you can wrap your database the same way.

However, your Roster already is a kind of such interface -- the database of all employees plus some functionality on who is available and when.

In relational databases, the normalization (http://en.wikipedia.org/wiki/Database_normalization) means that the record contains only the information that is not duplicit and that does not create interdependencies. In your case, the employee information (like name, gender, and whatever personal) should be separated from the Roster. The employee information should be stored separately from the Roster information. Only some unique information (technical, say an employee number) should be stored in the Roster database. The same number must be stored with the Emp information.

The Roster class-instance/module would be just a wrapper of the roster database table. The Emp class instance is just a wrapper around one record in the employee table.

In the simple case, the tables can be implemented as text files. It will probably be better to use CSV files and the Python standard csv module. Later, you can use the sqlite standard module. Even later, you may prefer to use some real database. It depends on how many people will manipulate with the information at once.

But to make it working for parallel access by more users, each user should be able to modify only his/her own file, and possibly be able to read only the files of the other users. This way, the relational database without the real database engine may not be the best solution.
Avatar of drewmore44

ASKER

"In your case, the employee information (like name, gender, and whatever personal) should be separated from the Roster. The employee information should be stored separately from the Roster information."

Can you help me understand why this is? It seems like the simplest thing to do would be to create a Roster table in which each row represents a different Emp object, with a separate column for each Emp-object variable? Why wouldn't this work?

Also, I'm self-learning how to write a wrapper class now, but would appreciate any guidance (or referral to any reference material) you could offer.
Without having the real database engine, the relation tables approach may not be the best one. To allow parallelism, let each person has its own file that he/she can modify. In the same time he or she will be only allowed (by the application) to read only the other files.

The reason is that otherwise people could change the same information. It is better to avoid that kind of conflict.

Then, the Roster is simply composed of all of the files (read only access).

In your case, you could use json module, or configparser module. But it is easy enough to write a simple parser/reader to use simple files like:
firstname=Drew
lastname=Moore
whateverinfo=something
monAM=3
tuePM=2
...

Open in new window

hmm, I have been reading about how to use the csv module with a simple excel spreadsheet. So, far, this seems pretty easy (although I havent actually gotten it to work yet, and lord knows I've had a lot of things seem easy until I actually tried to make them work.) How would
using json or configparser be a better solution?

If its relevant, I'm using Python 3
ASKER CERTIFIED SOLUTION
Avatar of pepr
pepr

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
The self.table will be the dictionary to store the employee choices for the week days/AM, PM... It will also be pickled/unpickled automatically.

(It's midnight here, Zzzzz  :)
Very helpful!