This is a data structure/mapping question. I'm using MSSQL, with .NET and EF (and MVC if that's important). I have a table that represents a deck of cards. The states of a card are:
Face down in the deck
Face up in the deck (discarded)
In front of a player
In a player's hand
...and there can be X players. I have a table that represents players as well, with their own unique key. Assume that each player is in a single game, and one deck of cards is in one game.
At first, I thought there would be a one-to-many relationship between players and cards, enforced by a foreign key in the database. Player 1P has card 1C, 2C, and 4C, so cards 1C, 2C, 4C and "1P" under the PlayerID. Then there is a bit field to represent if the card was face up or face down. That works for state 3 and state 4.
How should I handle state 1 and 2? Some options:
Make the PlayerID on the Card table nullable. When I was using EF, I was running into foreign key constraints. Edit: I was running into foreign key constraints, but when I tried it now, it looks like it's working as one would expect.
Creating a dummy player called "Deck", and assign all cards in state 1 and 2 to this player. But, this didn't seem elegant; the Deck player had a lot of other baggage that I didn't want to deal with, and if I started doing multiple games, I'd need multiple Deck players.
Scrap the foreign key in the database, and make the PlayerID nullable. Enforce the constraint in the code. But then I can't do things like Player.Cards() without some extra extension code.
Have two more bit fields: "IsInDeck" and "IsDiscarded" (or some field that represents multiple states, like an int that is 0: in deck; 1: in hand; 2: in front of player; 3: discarded). That way, we don't really care what the PlayerID is if the card is in the "Discarded" state.
Some other option I haven't thought of.
Ideas? Thanks in advance.
You could try a schema like this:
The tables PLAYER, CARD, and DECK are hopefully pretty clear.
LOCATION_TYPE is a list of the kinds of locations that might apply. This would include things like "in a player's hand", "in front of a player", "face down in the deck" and "discard pile". You could use a physical table for LOCATION_TYPE or you could use an enum. The advantage of a table is that you could include some business rules like whether the location type requires a PLAYER FK in CARD_LOCATION and whether the card is visible or invisible (face up/down).
CARD_LOCATION is therefore the intersection that tells you where each card is at any given time. Your Player.Cards navigation property will work well as will your Card.Location navigation property. It is important to note that the FK from CARD_LOCATION to PLAYER is optional.
Related
I was thinking about making a game and couldn't think of a way to to this:
Let's say, for example, you want to make rideable horses in your game, but only the player that owns a certain horse can ride it.
I thought about giving the horses different names and then assigning them to players. Obviously, It would be many horses, so the amount of names... don't even want to think about that. Also then I'm facing a problem: How to automatize the process, so every new player can get thier horse with no problems?
Several ways of going about this:
Use datastores and have an array of horses for each user. Horses will want to be named by a unique name/id. See https://create.roblox.com/docs/scripting/data/data-stores for datastore docs.
Every time you wish to check if a player owns a horse you can query the datastore. The advantages of doing it this way is that it will be saved for each time the player rejoins.
You could also save the array of players horses inside a value instance inside the player object, again assigning each horse a unique name/id. Then reference this instance each time you wish to check if a player owns a horse. The drawback of this approach is that the data won't save between sessions.
Finally and the method I would recommend is a mixture of the two approaches. When a player joins save their horses inside a datastore but also in a value instance as in solution 2. Then during the gameplay you can reference the value instance. When the player leaves and/or every couple of minutes you could save the content of the value instance to the datastore.The reason I would recommend this approach is because you could end up being limited by the number of requests you can make to Roblox's datastores and datastores can get pretty complicated at time especially when it comes to pcalls. In general you should avoid making too many datastore requests in a short space of time.
Hello all!
I have a question about where should the seats be assigned to keep track if it's booked for a showtime.
There is currently two way i thought of.
1) Assign the seats to the showtime instead of cinema. However this means that for each showtime it may have a different number of seats( which should not be true).
2) Check if the seat is assigned by accessing moviergoer->booking-> movieticket->seat number.
This method is tedious and uses more processing time. But i feel it's the right way as it will mean that the seats will be fixed.
I'm sorry if any other part of my diagram is wrongly drawn. However please guide me through this main question! I will be glad to get feedback for other part of my diagram too.
I really hope to learn more from this scenario.
Your design seems ok so far. Just a few observations:
you should remove the navigation in general since it does not add much value
the association from Booking to ShowTime seems superfluous as the Ticket already holds the needed information
re-think about duplicating cinema/movie:string in ShowTime as it adds unwanted redundancy
why do you have a <<use>> iso. an association in Review?
A seat is related to the cinema and the cinema offers show times. So 1) is ok.
Edit: You would map the ticket like this:
The both ID roles would map the ids in ShowTime and Seat. I would use an artificial integer for the seatID and likely some HHMM format for the showTimeID.
I'm trying to create a e-commerce website with out using any third party components.
My biggest problem so far is designing my model/database schema.
The e-commerce solution is for a Take away.
They only really have two types of Meals they Sell.
Rice Meals
Noodle meals Meals
Now Rice Meals have a set of options, so for example a Rice meal comes with either beans or plantain or both. (If both we need to off set the price)
Rice meals also come with a sauce the customer has 3 different options. There is no price difference.
Noodle meals
You can choose a Noodle type
You Can choose a sauce that goes with it.
You can choose if you want fish or meat
Then they have other products that don't have any options.
So my question is how can I create a flexible schema to store Products the options they have and the possible values for those options.
I also need to work out how to store what has actually been selected by the user.
I'm using EF with code first, would love someone to give me a few tips in the right direction.
The closest thing I have come across that may be a solution is this.
http://villyblog.blogspot.co.uk/2008/11/sample-database-schema-for-catalog-with.html
Really confused about the best way to do this.
Keep it simple!
Modeling is a skill. It's about observing and filtering. Even in a relatively simple business like a Take-away there is a lot of noise and if you manage to filter the noise and keep the essence your entity model will become both robust and flexible. First focus on the absolute minimum. Let me try to show you how this could work in your case.
The filtering begins with finding the "ubiquitous" language (Evans, Domain Driven Design): the "things" the business talks about and that are candidates to become entities in the model.
You talk about meals, types, values, prices, discounts, options, products. What are candidate entities?
One important step to take is to find the real, tangible "things". Customers don't eat options. They eat meals, or products. Nor do they eat prices.
"Option" is an interesting word. It is a covert verb. It's an act of opting for some "thing". It's a common design flaw in modeling to turn actions into entities, while they should become methods working on entities. Finding these disguised verbs is very very important. Without diving too deep into this issue I can say that having actions as entities make it hard to assign the right responsibilities to classes.
Likewise, prices (values) and types are no tangible things. They are attributes of things. Turning attributes into entities is a less obvious error, but it happens. I think the model you show as example contains both of the above flaws.
So far, in fact, the only real "thing" that emerges is a Product. The rest is either action or attribute. A Product can either be a meal, or a component of a meal. So these products come in combinations, or aggregates, which can be modeled by a hierarchy.
So here's the core of your "flexible schema to store Products":
You can store all possible combinations of products in one database table. No need to store options separately. Options are products as well. It's an act of combining to design the options in a hierarchy of products.
A concrete part of the hierarchy, the rice meals, could look like this:
The business does the combining, which is designing the hierarchy. The customer does the picking of options. Here business rules come into play. Let's say one rule is that the owner can combine any products, another rule is the customer can only combine end points (the smaller gray rectangles). The parent product could contain a property telling how many of its children can be chosen.
There may be a way to build these rules into the model, but coded rules are far more easy to modify than a model.. Let the model just be a dumb bag of data.
Now the part
I also need to work out how to store what has actually been selected by the user.
When a customer picks options he is making a classical order with order lines. That would make for a model like
Well, this is getting a long answer. A short word on the discounts. It depends a bit on how you want to calculate them. A simple way is a product property that's simply a multiplication factor to apply to the prices of each child product when more than 1 are selected.
Something like this might work, based vaguely on the link you provided:
MealType
- MealTypeID (short maybe? identity, PK)
- Name
Meal
- MealID (long, identity, PK)
- MealTypeID (FK)
- Name
- BasePrice
- IsActive (bit)
MealOption
- MealOptionID (PK) (short or int, identity)
- Name
- PriceOffset
- IsActive (bit)
MealMealOption (not the best name, but just represents a relationship between Meals and MealOptions)
- MealMealOptionID (PK, int or long, identity)
(composite foreign key with MealID and MealOptionID)
- MealID
- MealOptionID
Order
- (this holds stuff common to all orders such as billing address info, messages from the customer, etc.)
- OrderID (long, identity, PK)
- TotalCost
- TotalPriceOffset
etc...
OrderItems
- OrderItemsID (long, identity, PK)
- OrderId (FK)
- MealID (FK)
other order item-specific stuff...
OrderOptions
- OrderOptionID (long, identity, PK)
- OrderItemsID (FK)
- OrderID (FK)
- MealMealOptionID (FK)
anything else needed here...
Any table obviously will also have whatever other fields you deem necessary for that table.
The answer to this question is here >
Database design for user settings
It's a edr diagram of how to store: N number of settings, that are associated with N Number of users, and each user can have a N number of settings associated with that individual user. So you could have one user with 5 settings and another user with 10 settings.
This is very flexible and I'll be using it in the future. I have swapped the entity user and replaced it with product.
What I want to know now is HOW DO YOU STORE SELECTED SETTINGS? These tables are only able to store and show user settings and available options/settings.
Any ideas?
I know the theory but obviously when it comes to real world, I just do not know. In the following example is the relation between game and player/board a composition (they are instantionated inside the Game class)? And between a board and a pawn - aggregation, because the board can exist with 0 pawns?
Class Game
{
Player p;
Gameboard b;
void Start()
{
p=new Player();
b=new Gameborad();
}
}
class Gameboard
{
List<pawn> listOfpawns=new List<pawn>();
}
}
The difference between composition and aggregation is not whether a board can exist with zero pawns, but whether pawns can exist without boards, and also whether players and game boards can exist without a game.
In other words, if destroying a game will destroy all the players and boards then you have composition. If players and boards can live outside a game, then you have aggregation.
If destroying a board with destroy the pawns then you have composition. If pawns can live without a board, you have aggregation.
In general, if destroying the container destroys its elements, that's composition. Elements whose existence is not dependent on the container are said to be held by aggregation.
The classic examples of aggregation are:
Countries within alliances, because countries continue to exist if the alliance is disbanded
People within organizations, since the people still live when the organization ceases to exist
The classic examples of composition are:
The schedule(s) of a person, since if the person goes away, the schedule does too.
Composition
An object contain other objects, stored by value. These are usually elements you think as internal to the object holding them, like a cardDeck object has card objects. Even if the deck isn't initially filled, the objects mostly have purpose only inside the holding object.
Aggregation
An object contains references to other objects, the aggregated objects are something that exist out in the program in another context, and the parent object is just holding them for organizational or functional reasons. Example given in the below site reference is a plane that holds person objects. The persons may come and go, and may be used in other parts of the program.
In This Case:
Your example I'd say falls more under Composition. Much like the deck of cards, the pawns have little meaning outside of the game board.
Terminology
The literalness "by value" or "by reference" depends on the language, when people say one or the other in this context they use it to refer to how strong an owning relationship the parent has.
Of course in Java all objects are stored by reference, But! As soon as no references to an object exist, it's eventually culled by the GC. The airplane is likely to be holding the only reference to the engine, so the engine dies when the airplane is removed. People can have other things referencing them beyond the airplane, so you can think of it less like the Airplane is holding them directly.
(Reference http://atomicobject.com/pages/Aggregation)
Ray and Vigilant are right but what is right for you depends more on the (goal of the) Application then it does on the objects itself.
Game/Player:
If the application is an ad-hoc Game: Player would be Composite
If the application does more with the Players (keeps scores/ranking): Player
would be Aggregation
or
Airplane/Engine:
If the application is a Airline: Engine would be Composite
If the application is Maintenance: Engine would be Aggregation
i need some help with designing iphone's core data object model context. I've started making a golf scorecard application using XCode 4, and the way I want the application behave is...
-User can add players (with first/last name, initials)
-User can add courses (with name, address details, holes with par/lenght)
-Play a round so that in on top of scorecard tableview (hole view) I want to have fixed section that will not scroll, and that will show current score for each player on a round in addition to the best score ever on that same course.
-On hole view, in section header, I want to show like "Hole 11: Par 3 / 150 m" and on each row I want to show buttons to add strokes, and the best score ever on that particular hole.
-When managing players, adding/deleting, user can also browse the rounds that player has ever played.
What is the best approach to design entities? I already got some consultation and he suggested that I should have it like this:
PLAYER:
- first_name
- last_name
- initials
- ROUND:*
-- date
-- COURSE
-- SCORE
COURSE:
- name
- address
- hole 1 (par/length)
- hole 2...18
SCORE:
- hole 1
- hole 2...18
SCORECARD: (will only be temporary object, to be deleted when round is complete)
- PLAYER*
* = multiple objects
Is this a good design? I somehow feel that I should have a permanent SCORECARD objects that will hold PLAYER objects, one COURSE object and 18 holes attributes that will get values like "3:3:5:4" (score for each player, colon being seperator).
I hope this is not too messy posting, and please, forgive my english.
I would consider extrapolating the hole attributes to be an entity. Attributes would be "par" and "length". Then, have a relationship so that a course entity has many holes. Each hole conversely belongs to a specific course.
The data modeller in XCode is really good for visually creating entities and the relationships between them. I'd recommend experimenting until you feel that you have a good model. Think also about how you will use the model in your code. For example, what sort of look ups will you do?
For more detailed study it's worth getting a good book on object modelling. I used Larman's "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development".