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
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! :)
Currently, I have 48 fields.
I'm completely new to access. This is how I decided to connect everything together.
It doesn't seem to be very effective. Could somebody help me understand how to normalize this database?
Should I try to put employee information in one table, job information in another table and then have an equipment lookup table?
The current job, last job, and previous job can all the SAME table. If you sort this table by descending job start date, then then you have current, last and previous. You thus don’t need nor want a separate table for each of these which really amounts to the concept of a “job”. If sorting by date is not enough, then you could add a column called Job Type (current, previous, etc.). Again, we still only using the one table.
The same goes for Equipment. You really don’t care if the limit is 3 last, or 300 last. By building a normalized table, then ONE form can edit all types and you save MASSIVE amounts of coding and building of tables, User interface software, and that of building quires to retrieve + show the last 3 jobs in a form.
The fact that your design with FAR LESS cost of development allows 3 or 300 last jobs is really moot. More important if some manager comes along and now wants you to save the last 4 jobs, you don’t have some massive re-design here. And you can on the fly add new job types. So in place of current, and say previous, you can also have un-completed, or failed jobs. So adding new business rules means again you don’t add a new type of job table, but only a “type” to the one column you already using to define the job as current or previous.
Identify like objects and make one table to store all of them. In your design you have three tables for equipment but each item of equipment has the same fields; they should be one table. Similarly for jobs, each job is pretty much the same; they should be one table. The same for departments.
Figure out one or more column in each table that can uniquely identify the row in the table (that is, if you know the values for those columns it is impossible for there ever to be two rows with those values). These are your primary keys for your tables.
Identify cases in which an item in one table needs to "point to" (refer to) an item in another table. In this case, make sure that the referring table has a set of columns that match the referred-to table.
When you've done that, you'll have the beginnings of a correctly factored relational database design.
Which one would be better (performance wise and maintenance), a database which creates table dynamically or just adding rows dynamically?
Suppose I am building a project in which I let users to register. Say I have a table which store only basic personal infos, like name, dob, Date of joining, address, phone, etc. Say 10 columns.
Now is the tricky part.
Scene 1: Creating multiple tables
When a user complete registration, a message table is created. So each table is created for each users. The rows of each message table varies for each user.
In the same way there is a cart table for each user like the message table.
For this scene 1, 2 tables are created with every registration.
Scene 2: Adding Rows
The scenario is same here as well, but in this case I have 2 tables for message and cart. Rows are added only when there is an activity.
Note:
You must assume that the number of users is more than 2000 and expect 50+ users to be active all the time. Which means the message and cart tables are always busy for both the cases. Like there is always a query for update, add, delete, insert, select etc. simultaneously.
Also which scene will consume more disk space.
While writing this, it make me wonder what technique would Facebook and others use. If they use the Scene 2 style (all users (billions) use the same big long message table)... Just wondering
Databases has some basic rules defined for Database Design called
"Database Normalization", These basic rules allow us eliminating
redundant data.
1st Normal Form
Store One piece of information in only One Column, A column should store only One piece of information.
2ns Normal Form
A Table should have only the columns that are related to each other. All the related columns should be in One table.
Now if you look at your advised design, A Separate Table for each USER
will split SAME information/Columns about all the user in 1000's of
tables. Which violates the 2nd Normal Form.
You need to Create One Table and put all the related Columns in that
one table for all the users. and you can make use of normal t-sql to
query your data but if you have a table for each user my guess is your
every query that you execute from your application will be built
dynamically and for every query you will be using dynamic sql. which
is one of the Sql Devils and you want to avoid using it whenever
possible.
My suggestion would be read more about Database Design. Once you have
some basic understanding of database design. Draw it on a piece of
paper and see if it provides you everything that your business
requires / expects from this application , Spend sometime on it now it
will save you a lot of pain later.
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.
I've created a table name 'combined_data' using data from two tables 'store_data' and 'hd_data'. The two tables share a common column which I used to link the data when creating the new table and that is 'store_num'. What happens is when a user submits information to 'store_data' I want info from that submit such as store_num, store_name, etc to move into the 'combined_data' table as well as pull information from the 'hd_data' that pertains to the particular store_num entered such as region, division etc. Trying to come up with the structure to do this, I can fill in table names and column names just fine. Just curious if this is doable or if another solution should be sought out?
This is a common situation when saving data and requires to be split into 2 or more different repositories. I would create a stored procedure, and pass everything into a transaction, so if at any time something fails, it would roll back, and you would have consistency between your tables.
However, yes you can also do it with a trigger on insert of data on either store_data, or hd_data, if you would like to keep it simple.