I'm currently working on a game where we use ressources like: food, wood, stone, copper, etc. I'm having a problem with the structure for my ressources table.
A ressource has a: "name" and a "base price".
Each guild has a list of ressources (their personal banks of accumulated ressources).
Buildings have a cost of creation (a farm cost 10 woods and 2 stones to create).
Buildings have a monthly production (a farm produce 4 foods per month).
What is the best way to create my tables in this scenario?
First I went with a simple "Ressources" table with only 3 fields (id, name and basePrice).
Then I made an "Guild_has_ressource" table between "Ressources" and "Guild".
Then it became a mess when I tried to do the same with "Buildings"... There was gonna be way too many tables. There is gotta be an optimal way of doing this.
EDIT: Lotan mentionned I needed more details.
My database looks like this:
Database_v1
All my ressources are in a single table "Inventaires". I have a strong feeling that it is the wrong way of doing it.
I believe they should be in a table called "Ressources" where they can have their own "name" field and "basePrice".
A guild has ressources in its bank, a building has a construction price and a production income. How can all these 3 field connects to the same Table "Ressources"?
EDIT2: After more comments. I tested 2 more options.
1st: https://ibb.co/ZdHYLMT
2nd: https://ibb.co/G3ntdLz
What do you guys think? Am I in the right direction?
What I ended up doing is this
It does not feel right, it does not work properly but it's what I managed to do by myself...
Related
I want to make a database for a plugin I am making for Minecraft.
I've been trying to figure the best way to structure this but I have failed many times, could anyone give me some tips?
The idea is:
There will be a active_shops table => this represents individual shops, saving the information about each shop.
I need a table called player_shops => this table will have an AI ID and store things like, members and the name of the shop.
Here is where the problem is,
when adding the active shop I would need to include the ID from the player_shops as a secondary key.
But a player without a player shop can also make an active shop so instead of that ID I would need to store the player's UUID, which is a string of characters.
Please help to figure this out.
The information provided is scarce so it might not apply to your context, but...
Your original DB structure looks like:
Besides the problem you stated, you will not be able to normalize this structure.
I propose something like this:
The relation Shop - Player is to designate the "owner" of the shop.
The Member link table is to link the players members of the shop.
Since I do not know the difference between an active shop, and a player shop, I isolated that characteristic into a ShopType table, allowing you to choose one or the other.
Doing it like this allows a player to have any type of shop he wants. A shop is a shop, from your description I do not understand why you need to have 2 tables for your 2 shop types. A shop is a shop, being Active or Player type.
This is not a complete, add the different missing fields for each table, this illustrates only the structure.
The other possibility is if you need a shop to be 1) player 2) active 3) both. Then the shop table should be modified like so:
the type concept is removed, and boolean attributes define the type of the shop.
This is obviously a work in progress, hopefully it helps enough to get you started thinking of your solution another way.
I have created database where I have table where I´m saving game activity of footbal match (goals, assist, red/yellow card, 11m, ...). I want to make another game f.e. basketball, but also two player sports - table tennis, tennis, ... The problem is that there is a lot of things implemented in this database and it is MySQL.
My question is. What is the best way to do. Create new activity table for every sport (becouse there are different activities) or create column where will be something like XML file and every sport module (JAVA) will be working with that XML or there is another solution for that?
Thank you for response.
Do not store junk in your database. normalize the data you put into it, always, for your own good.
Having been a programmer for a long time i've never seen anything good come from storing xml or json blobs in the database a couple of years down the line. Imagine for instance you want to change the structure of the stored xml/json data, or there is an error. Now you need an extra tool to work with it.
I've worked in the sports stats business. You will want to normalize your data for every specific game type. (maybe even give them a separate database). they are all just slightly different, and soon you want to be tracking game,set,and match for tennis and heats for races and halfs for soccer, track rankings within different game types and scoreboards for wildly different game systems.
You don't want to store non-relative data in the same table.
I would suggest either a separate database per sport, and at a minimum a separate table. You obviously don't want to store a Tennis player with the Baseball players.
I would suggest making new tables for each sport. Name the DB something relative to all to all of them like Sports. Each table could be named the sport.
I have some experience getting data out of database, but not so much in design. To work on this, I'm taking some personal projects and trying to create them in access. I've run across an issue that I was able to get a solution to, but I find it clumsy and was hoping to have some opinions on what I can do better.
My current project is a monthly budget. At this stage I would like a Form to appear as follows:
Category
Sub-Category Budget_Amount
Sub-Category Budget_Amount
Category
Sub-Category Budget_Amount
etc.
I found that I can do this if all the sub-categories are the fields in a table and the category names are hard-coded as labels in the form. However, I would like my table structure to be like this:
Category:
ID
Category_Name
Sub-Category:
ID
Sub-Category
ID_Category
Show_Category
Budget:
Id
Sub-CategoryID
Budget_Amount
The reason I want this structure is that not all sub-categories will be used every month, and in my mind it will be easier to match what was budgeted verses what was spent. I am also trying to practice minimizing space taken up by the database. Are there any ways to do this easily? Or am restricted to my current solution?
I would dive into normalization principles first as you seem not to be too familiar on those principles yet.
"The reason I want this structure..." is not a good reason at all.
Your basic is a sound normalized database structure.
I'd suggest you structure your tables like this:
tblCategory -> CatID (autonumber PK), Categorie
tblSubCategory -> SubCatID (autonumber, PK), CatID (number, FK), Subcategory
As for budgets, I'd expect that budgets tie in into projects. There's no logical reason to tie in budgets directly into any kind of category.
We would need more and escepially more explicit information on what you're trying to achieve.
Similar question:
Database Design Question - Categories / Subcategories
There's sites that could help you to start understanding designing in MS Access, for instance
http://www.functionx.com/access/index.htm
This is my first question to stackoverflow so if i do something wrong please let me know i will fix it as soon as possible.
So i am trying to make a database for Tv Shows and i would like to know the best way and to make my current database more simple (normalization).
I would to be able to have the following structure or similar.
Fringe
Season 1
Episodes 1 - 10(whatever there are)
Season 2
Episodes 1 - 10(whatever there are)
... (so on)
Burn Notice
Season 1
Episodes 1 - 10(whatever there are)
Season 2
Episodes 1 - 10(whatever there are)
... (so on)
... (More Tv Shows)
Sorry if this seems unclear. (Please ask for clarification)
But the structure i have right now is 3 tables (tvshow_list, tvshow_episodes, tvshow_link)
//tvshow_list//
TvShow Name | Director | Company_Created | Language | TVDescription | tv_ID
//tvshow_episodes//
tv_ID | EpisodeNum | SeasonNum | EpTitle | EpDescription | Showdate | epid
//tvshow_link//
epid | ep_link
The Director and the company are linked by an id to another table with a list of companies and directors.
I am pretty sure that there is an more simplified way of doing this.
Thanks for the help in advance,
Krishanthan Lingeswaran
The basic concept of Normalization is the idea that you should only store one copy of any item of data that you have. It looks like you've got a good start already.
There are two basic ways to model what you're trying to do here, with episodes and shows. In the database world, we you might have heard the term "one to many" or "many to many". Both are useful, it just depends on your specific situation to know which is the correct one to use. In your case, the big question to ask yourself is whether a single episode can belong to only one show, or can an episode belong to multiple shows at once? I'll explain the two forms, and why you need to know the answer to that question.
The first form is simply a foreign key relationship. If you have two tables, 'episodes' and 'shows', in the episodes table, you would have a column named 'show_id' that contains the ID of one (and only one!) show. Can you see how you could never have an episode belong to more than one show this way? This is called a "one to many" relationship, i.e. a show can have many episodes.
The second form is to use an association table, and this is the form you used in your example. This form would allow you to associate an episode with multiple shows and is therefore called a "many to many" relationship.
There is some benefit to using the first form, but it's not really that big of a deal in most cases. Your queries will be a little bit shorter because you only have to join 2 tables to get episodes->shows but the other table is just one more join. It really comes down to figuring out if you need a "one to many" or "many to many" type relationship.
An example of a situation where you would need a many-to-many relationship would be if you were modeling a library and had to keep track of who checked out which book. You'd have a table of books, a table of users, and then a table of "books to users" that would have an id, a book_id, and a user_id and would be a many-to-many relationship.
Hope that helps!
I am pretty sure that there is an more simplified way of doing this.
Not as far as I know. Your schema is close to the simplest you can make for what I presume is the functionality you're asking for. "Improvements" on it really only make it more complicated, and should be added as you judge the need emerges on your side. The following examples come to mind (none of which really simplify your schema).
I would standardize your foreign key and primary key names. An example would be to have the columns shows.id, episodes.id, episodes.show_id, link.id, link.episode_id.
Putting SeasonNum as what I presume will be an int in the Episodes table, in my opinion, violates the normalization constraint. This is not a major violation, but if you really want to stick to it, I would create a separate Seasons table and associate it many-to-one to the Shows table, and then have the Episodes associate only with the Seasons. This gives you the opportunity to, for instance, attach information to each season. Also, it prevent repetition of information (while the type of the season ID foreign key column in the Episodes table would ostensibly still be an INT, a foreign key philosophically stores an association, what you want, versus dumb data, what you have).
You may consider putting language, director, and company in their own tables rather than your TV show list. This is the same concern as above and in your case a minor violation of normalization.
Language, director, and company all have interesting issues attached to them regarding the level of the association. Most TV shows have different directors for different episodes. Many are produced in multiple languages and by several different companies and sometimes networks. So at what level do you plan on storing this information? I'm not a software architect, so someone else can better answer this question than me, but I'd set up a polymorphic many-to-many association for languages, directors, and companies and an inheritance model that allows for these values to be specified on an episode-by-episode, season-by-season, or show-by-show basis, inheriting the value from its parent if none are provided.
Bottom line concerning all these suggestions: Pick what's appropriate for your project. If you don't need the functionality afforded by this level of associations, and you don't mind manually entering in repetitive data (you might end up implementing an auto-complete system to help you), you can gloss over some of the normalization constraints.
Normalization is merely a suggestion. Pick what's right for you and learn from your mistakes.
I am working on a reviews website. Basically you can choose a location and business type and optionally filter your search results by various business attribures. There are five tables at play here:
Businesses
ID
Name
LocationID
Locations
LocationID
LocationName
State
Attributes
AttributeID
AttributeName
AttributeValues
AttributeValueID
ParentAttributeID
AttributeValue
BusinessAttributes
ID
AttributeID
AttributeValueID
So what I need is to work out the query to use (joins?) to get a business in a particular location based on attribute values.
For example, I want to find a barber in Santa Monica with these attributes:
Price: Cheap
Open Weekends: Yes
Cuts Womens Hair: Yes
These attributes are stored in the Attributes and AttributeValues tables and are linked to the business in the BusinessAttributes table.
So let's say I have these details from the search form:
LocationID=5&Price=Cheap&Open_Weekends=Yes&Customs_Womens_Hair=Yes
I need to build the query to return the businesses that match this location and attributes.
Thank you in advance for your help and I think StackOverflow is awesome.
Thinking about your data needs, you may be a perfect candidate for a schema-free document oriented database. On a recent episode of .Net Rocks (link to show), Michael Dirolf talked about his project MongoDB.
From what I understand, you could take each Business entity and store it in the database with all its associated attributes (LocationID, Price, Open_Weekends, Customs_Womens_Hair, Etc.). Each entity stored in the store can have different combinations of attributes because there is no schema. This natively accomplishes what you are trying to do with an Attribute and Attribute_Value table.
To search the database, just ask it for all entities that have the particular set of keys and values you need. No complex joins and no loss of performance. What you are doing is exactly what schema-free, document based databases are designed for.
Michael Dirolf: Yes, I think that a lot of the people who are switching are people who have sort of got themselves into corners where they are using relational database the way that we use MongoDB.
Richard Campbell: Right.
Michael Dirolf: So having columns that, a column key and a separate column value and inserting stuff that way so that they get done in schema and all sorts of crazy stuff like that…
Richard Campbell: Yeah, now in reflection I suddenly realized I just describe your perfect customer, a guy who has taken, you know, abusing SQL Server as they say. We’re going down this funny path and you just shouldn’t be here in the first place.
If you keep going down the path of building a relational attribute/value store, your performance will suffer with the combonatoric explosion that results.