I'm writing in Java.
Trying to write my first user time-management mobile app.
I create a user class and a great function which allows the user to create a group of users in which he is admin, from which he has capabilities to track the employees—-
Does it require separate arrays?
Or is there something about databases that I don't yet understand?
Where does all the info from a single user being stored?
Sorry in advance for the noob question.
There are many solutions possible, you can have a separate table called admin where he has the entries of all of his associated employees (user) and yes programmatically you need to access them via an array. More information like uml diagram will make it more clear.
Related
I have an app, which takes input from a user (name, phone#, email) and generates a QR code. I used shared preferences to save the data so that the user does not have to fill out the fields every time. Right now, this only works for one person, and I want to add functionality for a second or third person.
Essentially, a main menu, that can open as many instances of the QR Generator as needed, and retrieve already open instances so that you can access the QR Codes of each person when you need it.
I have no idea where to start, so any help would be much appreciated. If you need to see the current code for the QR generator, I can attach that.
You should store the data in a database instead of sharedpreferences. And it should work smoothly. Database can store a lot of data and that too for multiple people. Which might help. You can store all the data of one person in one single row creating multiple columns for multiple attributes such as name, phone, email.
You can create multiple rows, and hence multiple people can store their data.
Database can used in two ways in android
Room persistence (also uses sqlite)
https://developer.android.com/training/data-storage/room
Raw SQLite database
https://developer.android.com/training/data-storage/sqlite
I'm still new to MVC programming in Java. My question is, in what part of the program is it best practice so store user information? I have a login form and I handle the login in one of my models. What's the best way to make the user data available to the entire application? I was thinking about adding field variables to my model and simply storing the data there, but since I have several models I wouldn't be able to retrieve the data from other models. Is it a good idea to create an object that stores the user data and calling that object from all models? Or is there a better approach? Thanks!
First of your question is too generic an is risking its closure.
Your gut feeling to not mix data is right. Keep whatever user data together. Maybe for now it's just a username but this kind of data tend to grow over time and you want this flexibility later.
Think about where you need that data most. User data is needed for authentication, authorization and tracking.
If you think of the relation of user data and user generated data, or the interaction between content and user data, how would you structure such relations?
If you think about performance, which subset of the user data is at least necessary to fullfil your requirements?
I know I am wage but your question is wage itself.
Try to step back from your code and think more about the architecture of your software.
I am busy practicing on designing a simple todo list webapp whereby a user can authenticate into the app and save todo list items. The user is also only able to to view/edit the todo list items that they added.
This seems to be a general feature (authenticated user only views their own data) in most web applications (or applications in general).
To me what is important is having knowledge of the different options for accomplishing this. What I would like to achieve is a solution that can handle lots of users' data effectively. At the moment I am doing this using a Relational Database, but noSQL answers would be useful to me as well.
The following ideas came to mind:
Add a user_id column each time this "feature" is needed.
Add an association table (in the example above a user_todo_list_item table) that associates the data.
Design in such a way that you have a table per user per "feature" ... so you would have a todolist_userABC table. It's an option but I do not like it much since a thousand user's means a thousand tables?!
Add row level security to the specific "feature". I am not familiar on how this works but it seems to be a valid option. I am also not sure whether this is database vendor specific.
Of my choices I went with the user_id column on the todolist_item table. Although it can do the job, I feel that a user_id column might be problematic when reading data if the data within the table gets large enough. One could add an index I guess but I am not sure of the index's effectiveness.
What I don't like about it is that I need to have a user_id for every table where I desire this type of feature which doesn't seem correct to me? It also seems that when I implement the database layer I would have to add this to my queries for every feature (unless I use some AOP)?
I had a look around (How does Trello store data in MongoDB? (Collection per board?)), but it does not speak about the techniques regarding user_id columns or things like that. I also tried reading about this in some security frameworks (Spring Security to be specific) but it seems that it only goes into privileges/permissions on a table level and not a row level?
So the question is whether my choice was appropriate and if there are better techniques to do this?
Your choice is the natural thing to do.
The table-per-user is a non-starter (anything that modifies the database structure in response to user action is usually suspect).
Row-level security isn't really an option for webapps - it requires each user session to have a separate, persistent connection to the database, which is rarely practical. And yes, it is vendor-specific.
How you index your tables depends entirely on your usage patterns and types of queries you want to run. Is 'show all TODOs for a user' a query you want to support (seems like it would be)? Then and index on the user id is obviously needed.
Why does having a user_id column seem wrong to you? If you want to restrict access by user, you need to be able to identify which user the record belongs to. Doesn't actually mean that every table needs it - for example, if one record composes another (say, your TODOs have 'steps', each step belongs to a single TODO), only the root of the object graph needs the user id.
I'm using Google App Engine and Objectify 3.1 and slowly learning about denormalization and designing entities based on their usage, but I'm still struggling with some aspects.
I'm currently building a system in which a User entity can participate in a Game entity and need to be able to find all games a user participates in. The way I see it, there's two basic solutions:
Solution 1)
Store a list of user keys (participantKeys) on the game and find the games a member participates in like this:
List<Key<User>> userList = new ArrayList<Key<User>>();
userList.add(new Key<User>(User.class, myUserId));
Collection<Game> games = ofy().query(Game.class).filter("participantKeys in" , userList).list();
Solution 2)
In addition to storing a participant list on the game entity, also store a list of games the user has participated in on the user entity and find the games like this:
User myUser = userDao.getUser(myUserId);
Collection<Game> games = user.getParticipatedGameKeys();
Solution 1 would become pretty slow once there's a lot of games in the system.
Solution 2 would make finding the games faster, but I'll need to constantly keep the list updated as users join and leave games.
The list of games would also become large once a user has been using the system for a long time. I only want to return all games the user is currently participating in, so that would require traversing the list and excluding "historical" games.
Am I missing a more elegant solution? Neither of the above seem very attractive.
Any and all help is greatly appreciated!
Edit:
I decided to try something like Mikl suggested after thinking about alternatives for a long time.. so it's good to hear a solution that's very pretty much exactly like it :-)
I have created a GameParticipation entity which contains a link to the game, a link to the user and all other information that I need to be able to get.
Every time a game is joined, I update the GameParticipation entity to reflect the current state of the game. When a game is left, I delete the entity. Also, when a game is changed, I update all related GameParticipation entities.
I've done a little performance testing and it seems to work reasonably well!
you can also have an another entity I don't know how you can call it (UserGame?) , but in this entity you will store the game key, the user key and also some information you want to access to, for instance the user name, the game name and so on. Then when the user enter a game you will create this entity.
With this entity you can easily retrieve the games a member participates in and also all the users that partipate to a game.
The inconvenient with this method is that, if a user property or a game property change you need to update also the information you stored in the USerGame entity like the userName.
I don't know if it's a good solution but it should work.
I am developing a facebook type application for my institute.
and I am stuck at the friends module. i.e. How to know if the particular users are one's friends.
I googled a lot but didn't get any satisfactory answers.
What I got is : there will be many friends of a person and implementing users and their friends in seperate table will only increase redundancy and large DB size.
I thought of using a graph with vertices as users and edges as connection .
But how to implement something like that in db.
Or How Facebook handles such huge amount of relationships?
Personally, I would have a dedicated table for it:
You could have a table with just two columns: userID and friendID
Since the relationships between users in the db will be many-to-many, normalizing it requires a link table which breaks it into many-to-one-to-many
http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html#03
This kind of problems are usually solved by using a different type of database. For a social network, a graph database should make sense, as nodes and relationships are first class citizens in it. There's a social network example for the Neo4j graph database, the full source code of the example is included in the standard dowload package. I've also written a blog post on this theme, with another example as starting point.