Is it possible to split MySQL table horizontally? I mean the situation is this:
I have table named Metals. Every metal has sub-group - iron,nickel,zinc and so on. I want this table to store all the metals but also to split their ID's. I want all products with Iron to start 1,2,3,4,5 as an ID but also products with nickel to start 1,2,3,4,5.
Is it possible or should I just split this into different tables.
enter image description here
This is the example. Both of info to be in 1 table, the difference is sub-group (nickel,iron)
I think before you consider your database design you might want to consider normalisation methods and some general design of your structure you can read more about that here
Related
I am storing one artist's name ('Pablo Picasso') and the titles of each painting he completed in a MySQL table.
For each title, I want to include the size, medium, year, etc as metadata that describes the painting itself.
Question:
How would you recommend storing this data for easy manipulation?
Would you create a new row for each painting with the respective metadata?
Or would you use one row and use commas to seperate the values of the metadata?
In other words, I'm curious to know any of the mysql best practices for storing data.
You could do it like this:
artists table
-------------
id
first_name
last_name
other_attributes
paintings table
---------------
id
name
artist_id
year
other_attributes
There are definitely best practices to store data. And the main purpose of Mysql is to have structured data that follows a very simple rule. One column contains one data. So the second option is definitely discouraged.
Depending on the number of attributes that you want to store about a picture the first option seems the solution. If you have a fixed number of metadata. Although if the number of metadata varies still one row for each painting
I'm having conception difficulties to implement something in a database. I have two solutions for a problem, and I was wondering which one is the best.
Problem :
Let's picture a table speciality with 2 fields : speciality_id and speciality_name.
So for example :
1 - Mage
2 - Warrior
3 - Priest
Now, I have a table user with fields such as user_id, name, firstname etc ...
In this table, there is a field called speciality. The speciality stores an integer, corresponding to the speciality_id of the table speciality.
That would be acceptable for users that have only one speciality. I want to improve the model to be able to have multiple specialities for a user.
Here are my two solutions :
Create a table 'solution1' which link the user_id with the speciality_id and remove the speciality field in the user table. So for a user which has 2 specialities, 2 rows will be created in the table 'solution1'.
Change the type of the field speciality in the user table to be able to write down the specialities, separated with commas.
For example 2;3
The problem I got with the second solution is for making foreign keys between my table user and my table specialities, to link them. I may have a bit more difficulties with the PHP in the future too, while wanting to get the specilities for a user (will need to use a parser I guess).
Which solution do you find is the best ?
Thanks.
Absolutely go with your first solution.
Create a third "Many-to-Many" table that allows you to relate a user to multiple specialties. This is the only way to go in your case.
When designing tables, you always want to have each column contain one and only one data element. Think about what querying your second solution would look like. What would you do when you wanted to see all users who had a given specialty?
You might try something like this:
select * from user where specialty like '%2%'
Well, what happens when you have specialties that go to 12? Now "2" matches multiple entities. You could devolve further and try to be tricky, but...you really should just make your data design as normal as possible to avoid all the mess, headache, and errors. Go with Solution 1.
i think the best way is to follow solution1 cause solution2 will end up will lot of complexity later on
I have this problem in a table where there are 4 columns which include terms describing the product. I want to make this terms editable (and you can add more) in my app and there are 4 groups of them obviously. I created a table who has all these terms altogether but the product table will have to create 4 relationships with the ID of the terms table.
Is this a good solution?
The main reason I don't want to make 4 different tables for the terms is because there aren't many of them and as the app progresses we might have even more different term groups, thus adding many small tables cluttering the database.
Any suggestion?
Update #1: Here is my current schema http://i.imgur.com/q2a1ldk.png
Have a product table and a terms (product_id, terms_name, terms_description) which will allow you to add as many or as little terms for each product as you want. You just need to retrieve all terms from the terms table with a particular product id.
You could try a mapping table:
apputamenti(id, ...)
term_map (apputamenti_id, term_id)
terms (id, text, type)
So you can add as many terms as you want.
Or if you want to specify the mapping with one more field, change:
term_map (apputamenti_id, term_id, map_type)
so you can use an enum for map_type like enum(tipologia, feedback, target) or whatever your original fields where
I have an existing mysql DB that manages regulations for 50 states. The current setup is relational - three tables for EACH of the 50 states:
state_table contains the chapter/sub-chapter headings
item_table contains the end records
department_table contains the ID's to relate the two.
all combined it handles around 620,000 records
I'm not a DB design expert and have always utilized this as-is and gotten-by however, the nature of tables for all 50 states limits searching across all states etc. and I'm wondering if there is a better approach.
I'm wondering if I should consider combining this into either a single set of 3 relational tables for the entire nation or even a single table to handle everything.
I've asked this on other forums and have been told to read various volumes of DB schema and structures etc. so if there is someone who can just suggest the direction to go in and the pro's and con's of what I have vs the alternative that would be great!
thanks!
Here's the way it is, X 50
alabama
ID
Name
State
Parent
Description
alabama_department
Department - ID's from "alabama"
Item - ID's from "alabama_item"
alabama_item
ID
Name
Description
Keywords
Doc_ID
Effective_date
...
...
The Queries: I step through the heirarchy of chapter/sub-chapter/end-record via links this works fine but I'm starting to focus more on search capability and also thinking what I have is overkill and it sounds like a couple of you think so (overkill)
If I am correct in thinking you have 150 tables (3 * 50 states) Then:
You should have a 'states' table which includes a stateID and stateName. Then use ONE table for chapter/subchapters, ONE for departments, and ONE for end records and use the stateID to relate different records to a state.
You should not have 3 tables for each state, you can use one of each and just relate to a state table. This brings you to four tables instead of 150.
I have a typical table, e.g.
id(int) name(varchar) address(varchar) date(datetime)
I also have a table that references validation functions for each one, e.g.
id(int) function(varchar) fail_message(varchar)
1 email Please enter a valid email address
2 required This field can not be left blank
I'd like to be able to associate each column from the first table with one or more of these validators.
The only way I can think of doing this is to stuff the ids into the column names e.g. (column name: email;1;2) and keep track of it through PHP, but that seems very messy.
Is there a good way to do this with relational databases? Would a NoSQL implementation suit this problem better?
Similar to what Dan said, a relatively easy way to implement an association in sql would be to do the following:
id(int) function_id(int) col_name(varchar)
1 1 address
2 1 second_address
3 2 address
4 2 name
And then when you want to do the failure check, use the above table to link the error message to the column name (e.g. 'select function_id from above_table where col_name="address"') and then query the failure table. These tables could subsequently be combined using a view with a join so that a single query would suffice.
Hope this helps.
put this in another table that describes the columns for tables oddly this is very much like extending the table that lists table columns with additional columns
let's say if you extend your example with say localized strings that would mean that the fail_message would become a fail_message_id and the table fail_message would have the columns (id, language, message)