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!
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 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!
For quite a while I am struggling with how to save custom user specific arrays of data in Mailchimp.
Simple example: I want to save the project ids for a user in Mailchimp and in best case be able to use them there properly as well. Let's say user fritz#frey.com has the 5 project ids 12345, 25345, 21342, 23424 and 48935. Why is there no array merge field that let's me save this array of project ids to a user?! (Or is there one and I am just blind...)
I know I can do drop down fields to put users in multiple groups, like types of projects for example, but the solution can hardly be a drop down with all (several thousand) project ids and I check the ones the user is a part of (and I doubt that Mailchimp would support that solution for a large number of group items anyways).
Oh and of course I could make the field myself by abusing a string field and connect the project ids with commas or a json string but that seems neither like a clean solution nor could I use the data properly in Mailchimp (as far as I know).
I googled quite a bit and couldn't find anything helpful sadly... :(
So? Can anybody enlighten me? :)
Thanks for all your help!
It sounds like you have already arrived at the correct answer: there is no "array" type, other than the interests type, which is global and not quite the same as an array.
The best solution here sort of depends on your data. If each project ID will have many different subscribers attached to it, and there won't be too many of them active at any given time, I'd just use interests. If you think there may be dozens of project ids active simultaneously, I'd not store this data on the subscribers at all, instead I'd build static segments for each project, and add users to them.
If projects won't have a bunch of subscribers associated, I'd store the data on your end and/or continue using the comma-separated string field.
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.
I have an application which has several unrelated tables in its db. I'll explain by using an "auto-updating" version of the SO homepage as an example, so lets say I have the tables "users", "comments" and "questions".
The homepage client side needs to periodically poll the server, and get a log of all the new "events" that have happened. I.e., I'd like to display (somehow) the new questions, comments and users that have been added to SO since the last poll.
On way would be to simply keep a variable on the client side containing the last index of each of my tables, send it to the server, and have the server send me the new users, comments and questions.
The problem is, what happens when I add a new type of information, say, votes. Now I have to store another variable on the client-side, and the server has to poll another table. And so on, for every new type of information I keep.
I'm looking for a solution that helps me avoid this.
Another problem - say I'd like to see all the "events" that have happened since last time, but sorted according to when they took place.
One direction I had is to have a single "events" table, which contains the info about when each event happened. I can then poll only this table, and get a list of all the new events that have happened. The problem is that each event is pretty different (a new comment has different columns than a new upvote, etc.) So I'm not sure how to implement this, or if this is even a good idea.
Does anybody have any ideas how I can solve this? This seems like something that would come up a lot, but I don't really have much experience with databases, unfortunately.
Thanks!
It sounds to me like you're trying to future proof via database design. While this can be done through something an EVA model I caution against that because the value its adds tend to not be worth the cost.
Instead you should model the database as closely to reality as possible and not how you intend to use it.
Then use SQL to project the data to how you need it. You can do this by statements that will either deliver the meta data that you need
e.g.
Select
Count(ID) , 'Comments' Type
From
Comments
Where
lastUpdate > #InputParamter1#
UNION Select
Count(ID) , 'Questions' Type
From
Questions
Where
lastUpdate > #InputParamter1#
Or (and this doesn't get used Often enough)
Return more than one result set from your database in one go
Select
userid,
ComentText
From
Comments
Where
lastUpdate > #InputParamter1#;
Select
userId,
Questions,
Tags
From
Questions
Where
lastUpdate > #InputParamter1#
That said you will still have to write some code if you add new stuff but it should be limited to updating your sql, adding new containers for your data and then code to display to the end users and then to validate and store it.
Honestly the idea of adding new stuff requiring some work doesn't seem that awful to me.