I'm questioning my MySQL database best practices right now and trying to figure this out. I have a form that users will fill out YES/NO and in case of YES, there's an extra field to explain themselves. There's about 36 fields, and the table would be 1>1. Say 15 fields apply to (A) user, 8 apply to (B) user, 8 to (C) user and 5 apply to (D) user. Would it be better to have separate tables with 15, 8, 8 and 5 fields or one big 36 field table with some empty fields? I'm looking for performance and normalization.
In my option, the answer depends on whether the list will ever change. If not, one wide table will be "cleaner" (easier to query, etc). If you need to change the list, trying to rebuild a large existing table in MySQL is a nightmare, so you're better off with an attribute table.
Hope that helps.
To be properly normalized, create a separate junction table to link the users who answer "yes" with their explanations. You do not want to find yourself in a situation where you have to alter the Users table just because a 37th explanation is added to the system.
Related
I'm working on a project to make a digital form of this paper
this paper (can't post image)
and the data will displayed on a Web in a simple table view. There will be NO altering, deleting, updating. It's just displaying (via SELECT * of course) the data inputted.
The data will be inserted via android app and stored in a single table which has 30 columns in mysql.
and the question is, is it a good idea if i use a single table? because i think there will be no complex operation in the sql.
and the other question is, am i violating some rules for this method?
I need your opinion. thanks.
It's totally ok to use only one table, if that suits your needs. What you can do to make the database a little bit 'smarter' is add new tables for attributes in your paper that will be repeated. So, for example, the Soil Type could be another table where there are two columns, ID and Description, and you will use it as a foreign key in each record in the main table. You need this if you want your database to be in 3NF.
To sum up, yes you can have one table if that's all you need. However, adding more tables might help save some space and make your database more flexible. It's up to you to decide! :)
I struggling to create a table that sets table parameters as well as creating the columns.
I am using MySQL server.
I require that the table meets the following criteria:
The table should be Called CUSTOMER with the columns CUST, LOCX, LOCY.
The column CUST will be a 1 up serial starting 1001 and will be the primary key.
LOCX and LOCY will contain X and Y Integers no greater than +-11, and will be foreign keys to other tables.
For info: I then intend to add my data to the table using the INSERT INTO function in a separate query that I already have.
Any direction on the construction of a query to create a table meeting the requirements above will be greatly appreciated
you can create a new table with a MySQL-GUI if you have problems with that.
These GUI-tools usually provide a New-Table button that also allows you to define your table without writing any code. They are often limited but should be more than sufficient for your needs. there are 1-month trial versions for paid versions and even completely free GUIs so you don't have to buy anything.
after that use the following code to retrieve "perfect" SQL from MySQL:
show create table your_schema_name.your_table_name
do that a few times and study the code. Soon you will be able to write create-table statements and include more complex column definitions on your own. It will also be easier to understand the MySQL Documentation which can be confusing and somehow intimidating with its completeness for beginners.
This question already has answers here:
How do you know when you need separate tables?
(9 answers)
Closed 9 years ago.
I have a table called cars but each car has hundreds of attributes and they keep on increasing over time (horsepower, torque, a/c, electric windows, etc...) My table has each attribute as a column. Is that the right way to do it when I have thousands of rows and hundreds of columns? Also, I made each attribute a column so I facilitate advanced searching / filtering.
Using MySQL database.
Thanks
This is an interesting question IMHO, and the answer may depend on your specific data model and implementation. The most important factor in this case is data density.
How much of each row is actually filled up, in average?
If most of your fields are always present, then data scope partition may be the way to go.
If most of your fields are empty, then a metadata-like structure (like #JayC suggested) may be more attractive.
Let's use the case you mentioned, and do some simulations.
On the first case, scope partition, the idea is to implement partitions based on scope or usage. As an example of partitioning by usage, let's say that the most retrieved fields are Model, Year, Maker and Color. These fields may compose your main [CAR] table, the owner of the ID field which will exclusively identify the vehicle.
Now let's say that Engine, Horsepower, Torque and Cylinders are also used for searches from time to time, but not so frequently. These may exist on a secondary table [CAR_INFO_1], which is tied to the first table by the presence of the CAR_ID field, a foreign key. Proceed by creating as many partitions you need.
Advantage: Simpler queries. You may coalesce all information about a vehicle if you do a joint query (for example inside a VIEW).
Downside: Maintenance. Each new field must be implemented in the model itself, and you need an updated data model to locate where the field you need is actually stored (or abstract it inside a view.)
Metadata format is much more elegant, but demands more of your database engine. Check #JayC's and #Nitzan Shaked's answers for details.
Advantages: 100% data density. You'll never have empty Data values. Also maintenance - a new attribute is created by adding it as a row to the metadata identifier table. Data structure is less complex as well.
Downside: Complex queries, together with more complex execution plans. Let's say you need all Ford cars made in 2010 that are blue. It would be very trivial on the first case:
SELECT * FROM CAR WHERE Model='Ford' AND Year='2010' AND Color='Blue'
Now the same query on a metadata-structured model:
Assume the existence of this two tables,
CAR_METADATA_TYPE
ID DESC
1 'Model'
2 'Year'
3 'Color'
and
CAR_METADATA [CAR_ID], [METADATA_TYPE_ID], [VALUE]
The query itself would like something like this:
SELECT * FROM CAR, CAR_METADATA [MP1], CAR_METADATA [MP2], CAR_METADATA [MP3]
WHERE MP1.CAR_ID = CAR.ID AND MP1.METADATA_TYPE_ID = 1 AND MP1.Value='Ford'
AND MP2.CAR_ID = CAR.ID AND MP2.METADATA_TYPE_ID = 2 AND MP2.Value='2010'
AND MP3.CAR_ID = CAR.ID AND MP3.METADATA_TYPE_ID = 3 AND MP3.Value='Blue'
So, it all depends on you needs. But given your case, my suggestion would be the Metadata format.
(But do a model cleanup first - no repeated fields, 1:N data on their own table instead of inline fields like Color1, Color2, Color3, this kind of stuff ;) )
I guess the obvious question is, then: why not have a table car_attrs(car, attr, value)? Each attribute is a row. Most queries can be re-written to use this form.
If it is all about features, create a features table, list all your features as rows and give them some sort of automatic id, and create a car_features that with foreign keys to both your cars table and your features table that associates cars with features, maybe along with any values associated with the relationship (one passenger electric seat, etc.).
If you have ever changing attributes, then consider storing them in an XML blob or text structure in one column. This structure is not relational. The most important attributes will then be duplicated in additional columns so you can craft queries to search on them as the Blob will not be searchable from SQL queries. This will cut down on the amount of columns in that table and allow for expansion without changing the database schema.
As others as suggested, if you want all the attributes in a table, then use an attribute table to define them. Then will depend on your requirements and needs of the application.
I am developing HRM system using php/mysql. There is one table that has more than 30 coloums. Since there is no data repeating I didnt break it in to other tables. But after I design the designing part of the system, coustomer wanted to store data part by part. Now there are 6 form submittion instead of one form. But the problem is now I have to use one table for insearting six form's data.
I can continue this as I do. But I want to know whether it is technically ok. or do I want to break one table (35 coloums) in to 6 tables?
please share your thoughts.
Many form submissions that condense inte one table is not strange and should not be a reason to split the table.
30 columns in a single table should not matter either as log as the table is normalized
Splitting the table based on some UI feature would probably de-normalize the database
I am going to have a database with several (less than 10) "main" tables. Additionally to that I want to have hundreds or thousands tables of the same type (let same "user_1", "user_2", "user_3" and so on). Is it possible to put all these tables in a directory/folder? Or database itself is already considered as a "folder" for tables?
ADDED
Since I go a lot of questions about why I want to do that, I want to elaborate on that. I want to have many tables to optimize query to the database. If I put everything in one table, the table is going to be huge. Than, if I want to extract information about a particular user, I first need to find those rows in the table which have a given user in a given column. And it can be time consuming. I decided to create a table for every user. So, if I need to know something about a user I just read the required information from a "small" table.
To be more specific, I can have 10 000 user and information about a given user can contain 10 000 lines. I do not want to have one table with 100 000 000 lines.
The answer is—you shouldn't be doing this in the first place.
Don't have separate tables for each user—instead, use one table for all your user data, and add a column (e.g. userId) to store information on who it's about.
If you want separate tables based on the user, this tends to be done using an owner or schema concept. In other words, you use:
create table pax.table1 ...
and pax is them the owner of that table. Each user can then have their own data.
If you don't mind everyone seeing the data in each others "folders", you can opt for a single table with a column specifying the particular user but you tend to lose user-based protection in that case.
Having each user's data in their own schema (or owner) means that you can restrict access based on user name. Keep in mind that these are then separate tables so it becomes harder to consolidate data from them should you wish to do so.
It's pretty unusual to have hundreds of thousands of tables, even in the biggest database setups. You might want to consider the possibility that you're doing something unwise. Posting the "why" of this question instead of the "how" will help us in assisting you further.