I'm building a database for characters that would be analogous to DnD character sheets. There are a lot of fields for any one particular character. Like 100+.
Would it be more efficient to have one table with all the columns then save/load what I need, or separate out the columns into tables by category (like stats, equipment, skills, etc), then just join the one-to-one tables whenever I need certain info?
TDLR: Better to have 1 table with 100+ columns, or like 10 tables each with 10-20 columns?
Related
I have a question about a database design in MySQL.
There are two groups of people i have a separate table for. Call them TABLE student and TABLE professor.
I can give each of them assignments from TABLE assignments.
Each person in each group can have multiple assignments, and each assignment can have multiple people. So to keep track of these, I have two mapping tables, call them TABLE student_assignment and TABLE professor_assignment.
My question comes here. I have a single table TABLE assignment_results that I want to store the results from all the assignments in. I would like for each line of each mapping table to have a single record...so it seems to make more sense to have a separate results table for each group of people??? TABLE prof_assign_results and TABLE stud_assign_results
Or would it make sense to combine the mapping tables and avoid splitting altogether? Is it possible to define a unique index containing three columns? Would the NULL values (in either the student or professor columns) interfere with that?
I am developing a MySQL db for a user list, and I am trying to determine the most efficient way to design it.
My issue comes in that there are 3 types of users: "general", "normal", and "super". General and normal users differ only in the values of certain columns, so the schema to store them is identical. However, super users have at least 4 extra columns of info that needs to be stored.
In addition, each user needs a unique user_id for reference from other parts of the site.
So, I can keep all 3 users in the same table, but then I would have a lot of NULL values stored for the general and normal user rows.
Or, I can split the users into 2 tables: general/normal and super. This would get rid of the abundance of NULLs, but would require a lot more work to keep track of the user_ids and ensure they are unique, as I would have to handle that in my PHP instead of just doing a SERIAL column in the single table solution above.
Which solution is more efficient in terms of memory usage and performance?
Or is there another, better solution I am not seeing?
Thanks!
If each user needs a unique id, then you have the answer to your question: You want one users table with a UserId column. Often, that column would be an auto-incremented integer primary key column -- a good approach to the implementation.
What to do about the other columns? This depends on a number different factors, which are not well explained in your question.
You can store all the columns in the same table. In fact, you could then implement views so you can see users of only one type. However, if a lot of the extra columns are fixed-width (such as numbers) then space is still allocated. Whether or not this is an issue is simply a question of the nature of the columns and the relative numbers of different users.
You can also store the extra columns for each type in its own table. This would have a foreign key relationship to the original table, using the UserId. If both these keys are primary keys, then the joins should be very fast.
There are more exotic possibilities as well. If the columns do not need to be indexed, then MySQL 5.7 has support for JSON, so they could all go into one column. Some databases (particularly columnar-oriented ones) allows "vertical partitioning" where different columns in a single table are stored in separate allocation units. MySQL does not (yet) support vertical partitioning.
why not build an extra table; but only for the extra coloumns you need for super users? so 2 tables one with all the users and one with super users's extra info
If you want to have this type of schema. try to create a relation
like:
tb_user > user_id , user_type_id(int)
tb_user_type > user_type_id(int) , type_name
this way you will have just 2 tables and if the type is not set you can set a default value to a user.
I have to create a system to save user's vote for two different type of module: News and Video.
This table should have the same fields:
id
entry_id
vote
user_id
So I tought to add a new field to save also the name of the module (module), in this way I can have just one table in the DB and filter it when needed and create two views for statistic purpose.
I don't really know if the best solution is one table with the new field or is better have two different table.
Let's assume that I have 1000 news and 1000 users and all of them will vote each news I will have 1000000 rows in the table.
Now assume that I have also 1000 videos and also in this case all my users will vote it, other 1000000 rows for an amount of 2000000 rows in a single table.
Do I have any performance problem in this case? And If I will have much more video, news an users?
Operation that I should do:
Insert
Update
Search
If you need more infos please ask
I think the way to answer this question is based on entry_id. The votes are going to be about something and that something is going to reference another table.
So, if you have two separate tables for News and Videos, then you should have two separate votes tables. Neither will have entry_id. One will have news_id and the other video_id.
If you have one table, say Entries for both News and Videos, then have one table.
In other words, I am advising against having one table conditionally reference multiple other tables. It becomes very difficult to express foreign key restraints, for one thing. In addition, join operations are cumbersome to express. Someone else might visit the table and not realize that entry_id can refer to multiple tables, and incorrectly set up queries.
All of these problem can be overcome (and there are situations where one table may be the preferred solution). However, if the original entities are in different tables, then put the votes in different tables.
I have to join multiple tables, some with one to many mappings, and convert every entry in the joined table to a single row entry in a csv file using PHP.
I know I am basically going from a 3D to 2D representation, but it is a formatting requirement for the csv file.
The MySQL structure consists of tables "questions", "people" and "trips". "people" table is linked to "questions" table by the id of "questions". Also in the same way "trips" is linked to "people" by the id of "people". There are one to many relationship between both "questions" to "people" and "people" to "trips"
The idea is to have a csv file with one "question" entry per row. This row entry will be the joined result of all 3 tables. The number of people and trips per questions entry is not consistent, therefore spaces are required if there are fewer people in some "questions" entries than other. The same with the trips.
What is the best way to get this done in PHP, except for brute force coding this with many queries, for loops etc. I am trying to get the MySQL query going, but cannot wrap my head around this problem.
I think you're looking for mysql GROUP_CONCAT function.
Select data with joins, group it by question_id and use group_concat on people and trips columns.
I've got this database with about 26 tables (field names are the same in each table) and i was wondering how simple it would be to do a general search on my website based on a keyword which will search through all tables?
Eg Each table has title, author etc etc so if i had a keyword of hairspray - whats the best way to look for the keyword through all tables..
Preferably not through a join or union due to the amount of tables
Cheers in advance
Its a very bad way, of creating tables.
If they share a common schema they should be one single table, with some additional field to separate or distinguish the data.
If this is not going to be an option for you, you might want to create a temporary table, which will hold all the data from all 26 tables, then query this table for the search.