I'm designing a web app which allows users to attend events and search for specific types of events.
Say, for instance, that these events are taking place in Hogwarts. The students have their own table where their studentID is held as a primary key, and this also contains which house they are a part of (of which there are 4), the subject they take, and which year of study they are in (e.g. 1 or 4 or 5, etc). The events can be for all students, specifically for 4th year students in the Ravenclaw house, or anywhere in between.
The events are held in an events table, which contains an eventID as the primary key, but I'm not sure how to hold the data for the house/year/subject it is aimed at. Obviously if an event were only aimed at 3rd year Hufflepuffs who take Potions, or something similarly specific, I could hold it within the same table. However, what if the event is for any year of Hufflepuffs (and not any Slytherins, etc)? Or if all students from all years, houses and subjects are eligible to attend? Will I need a table which holds all the years for each event and a separate table for which houses it's for and a further separate table for the subject it's aimed at?
Any advice or links are appreciated.
I think there are two ways but you definitely need at least one more table for the associations. Either you want to be very specific, about the combinations possible or you want to do it generally, like: only third years, only hufflepuffs, then the combination of the two values will be only third year hufflepuffs.
What I am trying to say are these two options.
1) One table that holds rows with very specific details:Event ID and the explicit combinations of all possible options (Here you will have a lot of rows)
This would mean that the event can be associated with second and third year hufflepuffs, but only second year slytherins.
association_id event_id year_id house_id subject_id
1 1 second hufflepuff potions
2 1 third hufflepuff potions
3 1 second slytherin potions
2) One table per property (here the disctinction is not as clear but you only have to create one row per property etc.
The following two tables could be used to store that all hufflepuffs and all slytherins that are in second or third year might attend
association_id event_id year_id
1 1 second
2 1 third
association_id event_id house_id
1 1 hufflepuff
2 1 slytherin
Does that answer your question or at least help you to find a solution?
Mybe if you can describe the target you are aiming at more closely one can find a solution suitable for your Problem together.
Related
I have been trying to design a MySQL table o store the items of the store purchased by the costumers. I am stuck with what approach should I take to design a good table.
My first option is:
id
bill_id_fk
item1_id
item2_id
item3_id
item4_id
In this approach, I'll create may be 20 columns for items (assuming that a costumer may buy a maximum of 20 items at a time). ID of the items will be stored in the item(n)_id columns for that specific bill_id_fk.
My concern with this approach is that it would be difficult to query later for a specific item, like how many times a specific item has been sold.
My second opinion is:
id
bill_id_fk
item_id
1
1
23
2
1
29
3
2
23
In this approach, I'll just create 3 columns and for each item I'll create a rows with the bill_id_fk for a specific bill.
In this approach, it is easier to query for a counts of the sell of a specific item. But my concern is creating thousands and thousands of rows when the app will be used and how will that affect the performance of the app over time?
I'd like to have your opinion on what is the best practice for designing such database. Or is there any other approach should I take?
There's no chance that you will go with the first choice, the second is the best approach for your case.
it will not affect your performance if you indexed the right columns.
When it comes to items can add a column to your bills table that holds item numbers, for example:
bills (id - total_price - user_id - item_counts)
bill_items (id - bill_id - item_id - item_price)
I am creating a database and I am unsure of the best way to design my tables. I have a table of real estate properties and I want to store information about those properties - e.g. bedrooms, bathrooms, size... I may have additional information I want to store in the future if it seems useful - e.g. last purchase price or date built, so I need to be flexible to make additions.
Is it better to create a separate table for each "characteristic" or to have one table of all the characteristics? It seems cleaner to separate the characteristics, but easier programming-wise to have one table.
CHARACTERISTIC TABLE
id property_id characteristic value
1 1 bedrooms 3
2 1 bathrooms 2
3 1 square feet 1000
4 2 bedrooms 2
...
OR
BEDROOM TABLE
id property_id bedrooms
1 1 3
2 2 2
...
BATHROOM TABLE
id property_id bathrooms
1 1 2
...
Forgive me if this is a stupid question, my knowledge of database design is pretty basic.
I would suggest a middle ground between your two suggestions. Off the cuff I would do
property table (UID address zip other unique identifying properties)
Rooms table ( UID, propertyID, room type , room size,floor, shape, color, finish, other roo specific details ect..)
Property details (uid, propertyID, lot size, school district, how cost, tax rate, other entire property details)
Finally a table or two for histories eg.
Property sales history(UID, PropertyID , salesdate, saleprice, sale reason, ect..)
Often grouping your data by just "does it match" logic can yield you good results.... care needs only be taken to account for 1to1 and 1tomany relationship needs of tables.
I am focused to this:
"I have a table of real estate properties"
Now as far as i knew you has to be a different type of:
Houses
Bedrooms
Comfort room and so on.
For further explanation:
You has to be a table of:
1. House type
2. House names,description,housetypeid,priceid,bedroomid,roofid,comfortroomid and any other that related to your house.
3. Bedroom type
4. Comfort room type
5. Dining type
6. roof type if it has.
7. House prices
8. Bathroom type
something like that.
One table with a few columns:
Columns for price, #br, #bath, FR, DR, sqft and a small number of other commonly checked attributes. Then one JSON column with all the other info (2 dishwashers, spa, ocean view, etc).
Use WHERE clause for the separate columns, then finish the filtering in you client code, which can more easily look into the JSON.
I have a tutoring website where teachers list their preferences for the ages of their potential students.
So far, I have broken those ages into the following categories:
0-4, 5-9, 10-14, 15-19, Adults. These categories, I think, represent decent break points for students ages. But no matter -- the real issue is table creation.
I will make a secondary table, teachers_ages, with a foreign key for teacher_id and another column for age. Should I make this column an enum, with the following acceptable choices '0-4' '5-9', '10-14', '15-19', 'Adults'?. Is this somehow bad-practice (to group numbers with words?) Does it violate any database creation norms? Is there a better way to break age groups for use with CRUD?
Update: teachers can choose as many age groups as they want
Typically you would create a lookup table which would list an identifier and the associated value. For example
Lookup table (AgeRange)
ID Min_Age Max_Age Description
1 0 4 "Less than 4"
2 5 9 "5 to 9"
3 10 14 "10 to 14"
4 15 19 "15 to 19"
5 20 1000 "Adults"
Now you can add another table with the teacher id and the age range id. (There can be more than one entry in this table allowing teachers to have any number of preferences.)
When validating you join to this table and look at Min_Age and Max_Age. When reporting you use the Description field.
If each teacher can only choose one age group you do not need to add a second table. Put the age-group field in the teacher table. Set the datatype as varchar and use check constraints for your five choices.
Your approach is a valid way to break groups down into demographics, such as age, income, population, etc.
I am working on a rewrite for a registration app and starting to think about how I want to design the DB structure. I need the app to be flexible because some events offer different things. Here's a particular one:
Each event offers shirts, but not every event offers the same sizes. I figured I'd have a Shirt_Size table with all possible options and then in a form to create a new Event, they'd be able to just checkbox what shirts they want. Where would I store the particular subset of sizes for that particular event? I will need to query that to populate a drop down for the form that will be for registering for events.
I figured I could do some kind of comma-separated column for the Event model that is different value IDs from Shirt_Sizes? But I've been reading that it's bad to do that, so I'm not sure how this is normally handled. Thanks!
You can create a third table that has a column for event_id and shirt_size_id and populate it as necessary. Say event1 only has small and medium shirts, you would add two rows to the table.
id event_id shirt_size_id
1 1 1
2 1 2
And if the 2nd event had small medium and large shirts, add 3 rows to the new table.
id event_id shirt_size_id
3 2 1
4 2 2
5 2 3
Then when you query for data to populate the drop down, you can join all three tables.
I am developing an evaluation system for different programs that needs a lot of flexibility. Each program will have different things to track, so I need to store what data points they want to track, and the corresponding data for the person being evaluated on the particular data point. I am guessing several tables are appropriate. Here is a general outline:
Table: accounts
- unique ID assigned to each account. We'll call this 'aid'
Table: users
- each user with unique ID.
Table: evaluation
- each program will enter in the metrics they want to track into this table (i.e attendance)
- column 'aid' will correspond to 'aid' in account table
Table: evaluation_data
- data (i.e attendance) entered into this database
- column 'aid' will correspond to 'aid' in account table
- column 'uid' will correspond to 'uid' in user table
The input form for evaluation_data will be generated from what's in the evaluation table.
This is the only logical way I can think of doing this. Some of these tables will be growing quite large over time. Is this the most optimal way of doing this?
I'm a little confused about how accounts, users and programs all relate to each other and whether or not account and program are the same thing and that you used the terms interchangeably. I'm going to use different terms which are just easier for me to understand.
Say you have a website that allows freelancers to keep track of different projects and they can create their own data to track. (Hope you see the similarity)
Tables...
freelancers
id title etc
projects
id freelancer_id title description etc
data_options
id freelancer_id title
You can even add other columns like data_type and give options like URL, email, text, date, etc which can be used for validation or to help format the input form.
example data:
1 5 Status
2 5 Budget
3 5 Customer
4 99 Job Type
5 99 Deadline
6 102 Price
7 102 Status
8 102 Due By
This display 3 different freelancers tracking data, freelancers with the id's 5, 99, and 102. Deadline and Due By are essentially the same but freelancers can call these whatever they want.
data_values
id project_id option_id option_value
a column freelancer_id as you would be able to to a join and get the freelancer_id from either the project_id or the option_id
example data:
1000 1 2 $250
1001 1 1 Completed
1002 1 3 Martha Hayes
This is only showing information freelancer with the id 5 has input because option_id's 1-3 belong to that user.