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".
Related
I am dealing with CoreData, for training, I decided to create a small application for recording user income and expenses. CoreData tutorials all contain To-Do-List examples, and I haven't found any good examples that would help me.
// MARK: - Grammar
// I want to apologize for grammatical errors in the text. Unfortunately,
// English is not my native language, so in some places I used a translator.
If something is not clear, I will definitely try to explain it again.
When I began to think over how I would implement the application, I assumed that the most convenient way would be to save all user operations and make calculations in the application in the right places. So far, abstract, since It seems to me that this has little to do with the question, if you need to be more precise, I can provide a complete idea.
So, I'm going to save the user model, which will have the following data:
User operations (Operation type) - all operations will be saved, each operation includes the category for which the operation was performed, as well as the amount in currency.
User-selected categories (Category Type) - Categories that will be used for expenses or income when adding an operation.
Wallets (Type Wallet) - User's wallets, Everything is simple, the name, and the balance on it.
Budget Units (BudgetUnit Type) - These are user budgets, contains a category, and a budget for it. For example: Products - 10.000 $
When I started building dependencies in CoreData, I got a little strange behavior.
That is, the user has a relationship on the same category model as the Budget Unit and Operation. Something tells me that it won't work that way.
I want the user categories to be independent, he selected them, and I'm going to display them on the main screen, and each operation will have its own category model
In the picture above, the category model is used 3 times, the same model.
This is roughly how I represent the data structure that I would like to see. Different models have their own category model, independently of the others.
I think it could be implemented using 3 different models with the same values, but it seems to me that this approach is considered wrong.
So how do you properly implement the data model so that everything works as expected? I would be grateful for any help!
--- EDIT ---
As a solution to the problem, I can create multiple entities as Category (Example bellow)
But I don't know if this is good practice
I looked into several other open source projects and saw a solution to the problem.
I hope this helps someone in the future.
There is no need to save the categories for the user, you can simply save the categories in the application by adding the IsSelected and ID parameter to them in order to change these parameters when you select a category, and immediately understand which ones you need to display.
For budgets and operations (transactions) , we only need to save the category ID to immediately display the correct one.
For example:
Thanks #JoakimDanielson and #Moose for helping. It gave me a different view of the subject.
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'd like to start and apologize if my question doesn't follow the rules for SE.
We're designing a social game that should support millions of players, and I have a very specific question.
Let's say a Player looks like this:
{ ID: "423erRRWEfwm432we", Name: "Friend A", Score: 125, AvatarType: 3.... }
Now when someone logs into the game, we'd like to load all of his friends scores to show to him - now a person could have up to 2,000 friends.
I was wondering what would be the most efficient and scalable DB tech + method to load all of my friends' data (score, name, avatar, etc) - assuming this should be (fairly) realtime and players are going to login a lot.
EDIT:
I think I should have been a bit more specific, I am quite proficient when it comes to RDBMes and NoSQL DBs - my question was what would be the most efficient/scalable way of achieving this - we are currently using a sharded MongoDB environment on a production game and we're not happy to say the least from it's performance.
In database terms, you have a table (ie "PLAYER"), with a self reference (ie a Player may have 0 or more "friends" who are also players). Since a Player may also be friends with 0 or more Players, it's what's referred to as a Many to Many reference. The common way of resolving this is with another table placed between the two tables (in your case, the two tables are the same table ;) ). So create a table called "FRIENDS" or something, with 2 columns: ID and FRIEND_ID. Then create 1 row for each friend relationship. You just have to join / lookup that reference to get the list of Players who are friends to the logged in player.
The actual details/syntax of that solution vary slightly from 1 database to another.
I'm more used to a relational database and am having a hard time thinking about how to design my database in mongoDB, and am even more unclear when taking into account some of the special considerations of database design for meteorjs, where I understand you often prefer separate collections over embedded documents/data in order to make better use of some of the benefits you get from collections.
Let's say I want to track students progress in high school. They need to complete certain required classes each school year in order to progress to the next year (freshman, sophomore, junior, senior), and they can also complete some electives. I need to track when the students complete each requirement or elective. And the requirements may change slightly from year to year, but I need to remember for example that Johnny completed all of the freshman requirements as they existed two years ago.
So I have:
Students
Requirements
Electives
Grades (frosh, etc.)
Years
Mostly, I'm trying to think about how to set up the requirements. In a relational DB, I'd have a table of requirements, with className, grade, and year, and a table of student_requirements, that tracks the students as they complete each requirement. But I'm thinking in MongoDB/meteorjs, I'd have a model for each grade/level that gets stored with a studentID and initially instantiates with false values for each requirement, like:
{
student: [studentID],
class: 'freshman'
year: 2014,
requirements: {
class1: false,
class2: false
}
}
and as the student completes a requirement, it updates like:
{
student: [studentID],
class: 'freshman'
year: 2014,
requirements: {
class1: false,
class2: [completionDateTime]
}
}
So in this way, each student will collect four Requirements documents, which are somewhat dictated by their initial instantiation values. And instead of the actual requirements for each grade/year living in the database, they would essentially live in the code itself.
Some of the actions I would like to be able to support are marking off requirements across a set of students at one time, and showing a grid of users/requirements to see who needs what.
Does this sound reasonable? Or is there a better way to approach this? I'm pretty early in this application and am hoping to avoid painting myself into a corner. Any help suggestion is appreciated. Thanks! :-)
Currently I'm thinking about my application data design too. I've read the examples in the MongoDB manual
look up MongoDB manual data model design - docs.mongodb.org/manual/core/data-model-design/
and here -> MongoDB manual one to one relationship - docs.mongodb.org/manual/tutorial/model-embedded-one-to-one-relationships-between-documents/
(sorry I can't post more than one link at the moment in an answer)
They say:
In general, use embedded data models when:
you have “contains” relationships between entities.
you have one-to-many relationships between entities. In these relationships the “many” or child documents always appear with or are viewed in the context of the “one” or parent documents.
The normalized approach uses a reference in a document, to another document. Just like in the Meteor.js book. They create a web app which shows posts, and each post has a set of comments. They use two collections, the posts and the comments. When adding a comment it's submitted together with the post_id.
So in your example you have a students collection. And each student has to fulfill requirements? And each student has his own requirements like a post has his own comments?
Then I would handle it like they did in the book. With two collections. I think that should be the normalized approach, not the embedded.
I'm a little confused myself, so maybe you can tell me, if my answer makes sense.
Maybe you can help me too? I'm trying to make a app that manages a flea market.
Users of the app create events.
The creator of the event invites users to be cashiers for that event.
Users create lists of stuff they want to sell. Max. number of lists/sellers per event. Max. number of position on a list (25/50).
Cashiers type in the positions of those lists at the event, to track what is sold.
Event creators make billings for the sold stuff of each list, to hand out the money afterwards.
I'm confused how to set up the data design. I need Events and Lists. Do I use the normalized approach, or the embedded one?
Edit:
After reading percona.com/blog/2013/08/01/schema-design-in-mongodb-vs-schema-design-in-mysql/ I found following advice:
If you read people information 99% of the time, having 2 separate collections can be a good solution: it avoids keeping in memory data is almost never used (passport information) and when you need to have all information for a given person, it may be acceptable to do the join in the application.
Same thing if you want to display the name of people on one screen and the passport information on another screen.
But if you want to display all information for a given person, storing everything in the same collection (with embedding or with a flat structure) is likely to be the best solution
While studying for Interviews, this question came to my mind.
I am planning to design a parking lot and I am assuming the following things:
It has multiple levels. Each Level has 2 rows.
The vehicle type could be small, compact and large.
Each row at a certain level has multiple parking spots.
Each parking spot has red/green light indicator( Red- No space, Green- Free space)
Also each parking spot will have size small, compact and large.
6(optional). Also want to add handicapped person situation.
These are some of the assumptions that I could come up with(Not sure if they are enough or I need more).
I was thinking of designing the system in such a way that as soon as the Vehicle enters the Parking entrance.
He should be given information that where is the nearest vacant spot available(For example- Level 3, Row 2, Spot # 10)
I would like to know how to go about designing such a system? I have seen many other designs but none achieves this i guess.
Not sure what you want to achieve through point 6, but the rest are pretty simple to achieve with an OO design, through the usual abstraction, inheritance and polymorphism principles.
You can have an interface called AvailabilityIndicator which has a boolean method isAvailable(), which represents the light indicator (the bulb will show red if isAvailable() is false, and green if true).
You can have an abstract class called ParkingSlot, which implements AvailabilityIndicator.
This could have the level, row and spot number in it.
You can have 3 classes LargeParkingSlot, CompactParkingSlot and SmallParkingSlot which extend ParkingSlot. (Not that your functionality actually needs this, unless the different parking slots have different behaviours or data you want to model, but since you mentioned you wanted an OO approach I mentioned it, otherwise a simple slotType parameter in ParkingSlot would do.)
Then its a question of when the vehicle arrives, checking what type of slot it needs and looking up which are the available ones that match. You might want to put them in a Map data structure which maps each slot type to the list of available ones, so that when one is taken it is removed and put in a separate unavailable list, for fast lookup of available slots when a vehicle arrives.