I am fairly new to constructing databases and was hoping I could get pointed in the right direction on this project. I have self-taught how to use Microsoft Access (my boss is asking that I specifically use this program) and how to "build a database," but I'm stuck on the abstract, specific functions I'm expected to implement. I'll post what I have come up with from all my research to show I've attempted this on my own before asking, but I would greatly appreciate drawing from the expertise of this community. Thanks for all of your time.
Context:
There is a manager survey (1) and an employee survey (2). Every few months, we have leadership roles open up and the managers fill out a survey with all the information regarding the role (opportunity) that they will be in charge of. After all the managers answer, the hopeful employees then review all of the new opportunities, fill out their own survey with some similar questions (and others unique), and indicate what opportunity they are most interested in. Once they fill out their surveys, the data is collected and matched up to the opportunity they wrote they wanted.
My thought process:
The backend can't be editable by those taking the survey - they (managers and employees) should only be able to add a new, non-existent record to their respective table (from the info entered in their survey). The DB would be stored in a
(1) Manager fills survey out (a form created from Mgr_FormShare - a middle man table), import data to backend db table (Mgr_SurveyDataMain)
*Split DB
*Use form as front-end, "properties_data entry: yes"
*Set up relationship between table inside backend and form
(2) Employee reviews opportunities, chooses DESIRED opportunity# and fills in rest of data (in a form created from Emp_FormShare / middle-man table), import data to backend db table (Emp_SurveyDataMain)
*Split DB
*Use form as front-end, "properties_data entry: yes"
*Set up relationship between table inside backend and form
(3) Run query, imports both surveys into one table in backend (ManagerEmpCombineData)
(4) Append an Assigned field in the Mgr_SurveyDataMain (if an opportunity is discovered as chosen, it's "assigned" status goes from no -> yes)
My questions:
Is this the correct way to approach this situation? Is there something I am missing here?
Also, is there a way to ensure all surveys (about 200+ when employee + manager count) will automatically share to the middle-man + only allow one entry per individual? Before splitting, I wanted to make sure that the forms with the properties [DataEntry: "Yes", RecordsSource: "*_FormShare", Each field's control source: linked to respective *_FormShare field] would be enough to make sure that they synced. It's okay if I can't ensure only one use, the sync is the most important aspect.
Thanks again for taking the time to go through my question!
Related
Background
I'm creating a layered .net core application to handle tracking campaigns for a board game. Because of this there is a lot of data that comes from the game itself, for example:
Characters
Weapons
Equipment
Missions
Objectives that belong to a mission
Rewards that belong to objectives
Etc
The application is not to manipulate this data. This data is typically printed on cards that come with the board game so it won't change. The only changes it may have are when I manually add new characters or something due to a new expansion being released.
As far as the app is concerned, these are similar to how you might have a lookup table of States in the US. The app needs to list them so you can select them, entities in the domain hold references to them, but their actual data is irrelevant to the application itself. It's just lookup data.
Except there is a lot of this data and some of it is related. For example an objective belongs to a specific mission and a reward belongs to a specific objective.
The Problem
If my application was being designed to manage this data there would be no problem. However this is not the case. It is designed to manage "Campaigns", which are 2-5 players sitting down to play a game with these cards. It is managing "instances" of this data that have additional properties.
For example a new campaign is created and a row is added to the Campaign table. Now a mission must be added to it.
I can't just add a reference to the Mission data because I also need to store the outcome of the mission specific to this campaign. So I create a CampaignMission entity that references the mission data, the campaign id, and has a column for the mission outcome.
But that Mission data had related Objective data. The data just holds things like objective name, description, rewards etc, but in the campaign I also need to store the outcome of this objective specific to this CampaignMission. So again I create a CampaignObjective that references the Objective data, the CampaignMission, and has a column for the objective outcome.
Before you know it I am doing this for everything. CampaignCharacter, CampaignWeapon, CampaignReward. I feel like I'm just replicating the structure of the game data, relationships included.
Where the game data has relationships, my Campaign entities feel like they're mirroring the relationships to the point where, from the same object, you can access the same piece of game data by following two separate paths, the original game data relationship or the Campaign entity "replica" relationship.
For example if I want the name of the first reward for the first objective in the first campaign mission, you can access it in two ways:
Campaign.CampaignMissions[0].Mission.Objectives[0].Rewards[0].Name
Campaign.CampaignMissions[0].CampaignObjectives[0].CampaignRewards[0].Reward.Name
Both of these point to the same piece of game data. I really feel like there should only be one path:
Campaign.Missions[0].Objectives[0].Rewards[0].Name
Where I'm Stuck
I'm not sure if this is normal but it all just feels wrong. Almost as though the game data shouldn't even be part of the application. I mean the game data could be hosted on some 3rd party API and it wouldn't make any difference to my actual application. It's just data I need to read but I feel it's impacting my app structure in ways it shouldn't be.
My application doesn't really need to know the difference between Mission game data and a Mission in a campaign. All it needs to care about is that a campaign can have missions, and those missions have a name etc and an outcome. It doesn't feel like the Mission game data itself needs to be an entity in my domain.
What I've Tried
I tried keeping single entities in my domain and keeping them separate in my database. So for example a Mission in the domain would include both the game data fields like mission name, the mission outcome and a list of domain Objectives.
When a domain Mission for a campaign is requested from the data layer, the entry is retrieved from the CampaignMission table, along with its game data from the Mission table, then flattened via AutoMapper and returned to the domain as a single Mission entity containing everything.
This just caused a bit of a nightmare with Entity Framework and handling the mappings back and forth between data layer and domain because the CampaignMission in the database also had CampaignObjectives which linked to Objectives that also had to be flattened etc, and I had to keep track of the primary keys for all of these throughout my domain so everything could be unflattened and mapped back again when I want to persist something. It just didn't make sense, in terms of tracking primary keys/identity, for a single domain entity to be represented by entries in multiple tables.
What I'm Now Considering
I'm considering just moving all of the game data into a totally separate project, completely unrelated to my application. My application could then query project as though it was some third party API or something and get any data it needs and I can keep it all out of my solution.
Since the game data would no longer have IDs in my application, when I add a mission to a campaign it would simply have a column for "name" which would hold the mission name. When I want to use that mission I would grab it from the db and map it to a domain entity, so at this point it contains the campaign-specific data such as mission outcome, and also the name. Then I'd query the game data project using the mission name and map all the returned data back on to the entity as well, leaving me with a complete entity.
This is essentially replicating the behaviour of what I already tried but removing the need to track identity for the game data by simply using a name that I can query. It removes the concept of backing game data from my domain and leaves me with a single entity, Mission.
The Question
I've wasted a lot of time on this so far and I'm sure it must be a common problem in similar types of applications. I was wondering if anyone had a better solution for dealing with this kind of situation before I go ahead and try completely separating the data.
I have to admit, typing out the "What I'm Now Considering" section has clarified a few things for myself but I would still love to hear if there is a better way.
Thank you in advance if anyone reads all of this.
Here's what you should be doing. First, add the game data entities to the DbContext as DbQuery<T>:
public DbQuery<Campaign> Campaigns { get; set; }
This will allow you to query it, but will not allow changes. Then, since the game data is static, you might want to actually just persist it on a singleton, which you can then inject where you need it.
In either case, on the actual campaign data that's being persisted, you should only store the id of the game data concept. For example, MissionId, not CampaginMission.Mission. When you need the actual Mission info, just look it up based on the MissionId, either directly from your DbQuery<Mission> property on your context or your singleton class.
I have a question regarding database/system design. We have a table user with user_id and a table school with school_id. We want to implement a feature so that users can add schools to their "favorites list". I already created a third table that contains the relationship between user_id and school_id. Now I have the two following questions:
When a user removes a school from "my favorites" list, should I delete it or keep it in the database but mark it as "deleted"? I want to keep it but it might leave tons of junk data in the table over time.
The front-end design looks similar to like/dislike button on twitter. User can favorite/unfavorite a school with one click. Is there any good way to prevent a bot from constantly hitting the the database by clicking the button?
Thanks in advance!
The answer depends on your application's logic. Both suggestions are ok.
If you need this data sometime in the future or if you are saving history of user actions then you can mark it as "deleted", else you can delete it immediately.
(another approach is mark it as deleted temporarily, and have a periodic job that cleans the table)
I don't have enough experience with this kind of threat, but a simple solution would be is to limit API calls per second per user
I have been going through multiple questions on here about this but cannot find one that fits my circumstances.
I have a program that allows you to schedule meetings. It connects out to a sql database where everything is stored. I have a main screen that pulls information from my appointment class(date & time) and the customer class (customer ID & name) i know this will not populate correctly because the table cannot be two classes. Is there anyway I can get this to work properly. I have a feeling it's super easy that I can implement into one of my java classes. Feel free to ask any questions if something isn't clear!
Thanks!
I'm trying to write a REST interface for an application.
The Model
In the model of this application I already have a situation like the following:
A person can have multiple activities.
An activity can be referred by several people.
The activities of the people are ordered with a specific field (position).
I've represented this situation in my db with three tables: people, activities, people_activities. The table people_activities features three fields: person_id, activity_id, position.
The new Requirement
Everything worked fine until now but now I've got a new requirement, I should be able to insert an activity for a person on top of the others.
So if the content of the people_activities table is for instance this one:
"mark reading 0"
"mark running 1"
if I received the request to add "mark juggling" the result should be:
"mark juggling 0"
"mark reading 1"
"mark running 2"
The solutions
The dilemma for the REST interface now comes from the fact that I identify only two options:
using a single URL like /people/mark/addActivity but this doesn't seem restful at all since it modifies resources not referred by the URL and contains a "verb" too much.
using some URLs like what I'm already using (something like /people/mark/activities or /people_activities?person=mark) and post the new change towards all these resources. This seems to be restful but very sloppy in my opinion.
What's the proper way to deal with this situation in your opinion? Is there a third option I'm not considering?
First Edit
Just by thinking better about the questions I'm realizing that another reasonable solution would be to end with this situation in the database:
"mark juggling -1"
"mark reading 0"
"mark running 1"
Because the position is just a number that has not a "real" value for me. In practice I cannot do that but it looked like a precious information and a way to add a new resource without modifying the other associations, that is not something i need to do from my business logic point of view.
Maybe another error is that I'm letting to much database data spilling on my interface. In this case what i really need from a business perspective is the order of the elements, not their position. The position thing is just a technical detail I have used in the database to accomplish the ordering.
So another question maybe:
is reasonable in your opinion to modify some information in your database if this information is just a technical detail and it's not exposed to the interface users?
I think your solution of inserting the new entity with a position of min(position) - 1 sounds good.
We are also looking to build a RESTful API backed by a SQL database that allows the resources to be reordered and have faced this problem with the implementation details of how to add a new entry to the start or in the middle of the list without having to update the positions in all the entities.
In our implementation we plan use a floating point number for the position field and plan to follow these rules:
If the user wants to insert the entity to the start of the list, insert with a position of min(position) - 1.0
If the user wants to insert the entity to the end of the list, insert with a position of max(position) + 1.0
If the user wants to insert the entity anywhere else, insert with a position equal to the average of the positions of the two entities either side.
With the technology we are using we get 1073 inserts between two entities before we need to rebalance, by updating the position fields in all the entities to be all spaced 1.0 apart from each other. This is fine for our use case.
Side note: With a graph database you don't have this problem. It is very easy to add a new entity anywhere within the list by just updating the two relationships of the nodes either side, just like when you insert something into a Linked List. So that is something else to consider if you are not tied to a SQL database
All of the above is implementation details. With regards to how the API should look to an end user, I would vote to make it appear however is easiest for your clients. In our use case I hope for us to make the position field appear as a 0 based integer index (just like an array), as that will be easiest for our clients. This would mean that inserting a new entity at the beginning of the list will make it appear that the position field in all the other entities has changed, but I think that is fine. It doesn't fly in the face of the REST philosophy too much. It's pragmatic.
I'm creating a text-based browser game and need some advice for django model structure. All the examples are from the same project, therefore I will not repeat the same information assuming you've read all the questions from the top to the bottom.
First question
I have an auth app which contains user profile (Player model), alliance app which holds information about all the unions players join and medals app which represents rewards for both players and alliances.
Both users and alliances can have medals assigned so one of the options is to create a M2M field in Player and Alliance models linking to Medal.
Another option would make medals app usable in any other project of mine. This approach includes the use of generic relations in Medal model which links to either Player or Alliance.
Which solution is more django-like or can I do however I want to?
Second question
There will be tasks for players to accomplish. The scenarios of tasks vary greatly, therefore I need some kind of approach to write unique task progress checking code for each task.
Tasks are held in the database containing information about rewards (which are pretty much the same). Where should I write unique code for each task? Maybe I should add some fields and eval() them later? Then all the information will be held in the DB.
Moreover, tasks demand some tracking, for example, imagine a simple task of going to the manual section (just to make sure the player knows where it is). Then I need to register somewhere whether the player has visited manual page or not. I think about creating another model TaskTrackers in task app. Then another question arises. If I should add OneToOne field from Player to TaskTrackers or vice versa?
To sum up, the main question is whether should I add OneToOneFields/M2M fields to user profile model or add OneToOneFields/Foreigneys from target models to User model? The latter would make my apps more reusable, but the first approach may be more logical.
Waiting for answers.
One your first question, you could do either an M2M to Medal, or use a generic foreign key. You'll end up with a couple of join tables with M2M. With the generic foreign key, you won't have any join tables, but you will have the extra query for the content type. So, you may need to set up both ways and see which is going to impact performance more
On your second question, I might take the approach of using a "Task" model with one or more "Step" models that can be set up as an inline formset. Then you'll need a table like "CompletedPlayerTasks" or something like that, which contains the Player ID, Task ID and Step ID. If a Step ID exists in that table, the task has been completed.
It sounds like you need to be able to create custom fields and forms for the Steps of each Task, which isn't terribly hard to do in Django. There are some off the shelf solutions to do this, but you might need to write your own.
Lastly, I wouldn't name the app that holds your user profiles "auth", which could cause a namespace problem with Django's contrib.auth app. I would name it "profiles", just so it's more obvious what that app does and contains.
Hope that gives you some ideas.