I have a list of records to be stored in database table, but I'm facing some difficulty in designing the database. The following would be the data to be stored:
The Class (Rows) and The Day (Column) will be continue to grow in future. My initial idea have 2 designs.
The table design for the database design will be exactly same with the current table. But the problem would be how if want to add Day13? It would be suffer in future in the column keep continue to grow.
Add 1 column as result:
It look better to solve the problem of Day column to be growing in future, but the problem is it will keep large amount of data records in database which make query become slower when more and more data insert.
Any idea or technique on how to optimize the database design? Thank you.
So a Class can have a result and a date. Just make sure to have a unique primary key on your Class table and make the correct data types for your fields.
What I think you need is a ClassId for primary key and then make a ClassName field (varchar) to store the class name. Don't write Day1 it should be a date format.
Maybe something simple like this.
One table for Classes (ClassID, ClassName)
One table for Day/Period/whatever you call it (DayID, DayName, DayInMonth etc..)
One table for Results(ResultId,DayId,ClassId, Result)
Related
I would like know the best way of designing a table structure for dependent column values.
If i have a scenario like this this
if the status of the field is alive nothing to do
if the status is died some other column values are stored somehow.
What is the best way to handle this situation
whether to create table containing all columns ie 'Died in the hospital','Cause of death','Date of Death' and 'Please narrate the event' and let it be null when status is alive
or
to use seperate table for storing all the other attributes using Entity-attribute-value (EVA) concepts
in the above scenario signs and symptoms may be single, multiple or others with specification. how to store this .
what is the best way for performance and querying
either to provide 15 columns in single table and store null if no value or to store foreign key of symptoms in another table (in this strategy how to store other symptom description column).
In general, if you know what the columns are, you should include those in the table. So, a table with columns such as: died_in_hospital, cause_of_death, and so on seems like a reasonable solution.
Entity-attribute-value models are useful under two circumstances:
The attributes are not known and new ones are added over time.
The number of attributes is so large and sparsely populated that most columns would be NULL.
In your case, you know the attributes, so you should put them into a table as columns.
Entity-attribute-value models is the best method, it will be helpful in data filtering/searching. Keeping the columns in the base table itself is against Normalization rules.
I'm working on a project where I need to be able to create custom fields on employees. These fields would be things like First Name, Last Name etc.
I'm required to optimize this to work for 10,000 employees with 200 fields.
Right now I have an "employee" table, a "field" table and pivot table ("employee_field"). The pivot table stores the employee's data for each of the fields in the nullable column with the data type required for that field. It also contains the employee id and the field id.
I'm finding that joining these tables takes about 0.5 seconds to load 500 employees with 50 fields.
I'm about to try creating another table that keeps all of the joined data I need for the application. This would basically be a table that contains the employee id, field id, the field label, the formatted data, and the field type alias. This table would be kept up to date using database triggers.
Question: Am I following the best practice for doing this kind of join, and is there any way to optimize this for reading this data?
You have an entity-attribute-value data model. There is nothing per se wrong with such a model, but it seems like overkill for your purposes.
MySQL should be able to readily handle a table with 200 columns. My recommendation is to eschew the joins and just define the table that you need.
Now, your situation might be a bit more fluid. Perhaps new columns need to be added. In this scenario, new fields are fine . . . if adding them is infrequent and they apply to all employees.
If you frequently need to handle new fields, or different employees have different subsets of fields. If this is the case, then I would recommend a hybrid model. Put the dozens of common fields into a single table and then build a more flexible EAV model for new attributes.
After further testing I've come to the conclusion that it has something to do with my apps binding to SQL and not the SQL schema.
I had one single table that had lots of problems. I was saving data separated by commas in some fields, and afterwards I wasn't able to search them. Then, after search the web and find a lot of solutions, I decided to separate some tables.
That one table I had, became 5 tables.
First table is called agendamentos_diarios, this is the table that I'm gonna be storing the schedules.
Second Table is the table is called tecnicos, and I'm storing the technicians names. Two fields, id (primary key) and the name (varchar).
Third table is called agendamento_tecnico. This is the table (link) I'm goona store the id of the first and the second table. Thats because there are some schedules that are gonna be attended by one or more technicians.
Forth table is called veiculos (vehicles). The id and the name of the vehicle (two fields).
Fith table is the link between the first and the vehicles table. Same thing. I'm gonna store the schedule id and the vehicle id.
I had an image that can explain better than I'm trying to say.
Am I doing it correctly? Is there a better way of storing data to MySQL?
I agree with #Strawberry about the ids, but normally it is the Hibernate mapping type that do this. If you are not using Hibernate to design your tables you should take the ID out from agendamento_tecnico and agendamento_veiculos. That way you garantee the unicity. If you don't wanna do that create a unique key on the FK fields on thoose tables.
I notice that you separate the vehicles table from your technicians. On your model the same vehicle can be in two different schedules at the same time (which doesn't make sense). It will be better if the vehicle was linked on agendamento_tecnico table which will turn to be agendamento_tecnico_veiculo.
Looking to your table I note (i'm brazilian) that you have a column called "servico" which, means service. Your schedule table is designed to only one service. What about on the same schedule you have more than one service? To solve this you can create a table services and create a m-n relationship with schedule. It will be easier to create some reports and have the services well separated on your database.
There is also a nome_cliente field which means the client for that schedule. It would be better if you have a cliente (client) table and link the schedule with an FK.
As said before, there is no right answer. You have to think about your problem and on the possible growing of it. Model a database properly will avoid lot of headache later.
Better is subjective, there's no right answer.
My natural instinct would be to break that schedule table up even more.
Looks like data about the technician and the client is duplicated.
There again you might have made a decisions to de-normalise for perfectly valid reasons.
Doubt you'll find anyone on here who disagrees with you not having comma separated fields though.
Where you call a halt to the changes is dependant on your circumstances now. Comma separated fields caused you an issue, you got rid of them. So what bit of where you are is causing you an issue now?
looks ok, especially if a first try
one comment: I would name PK/FK (ids) the same in all tables and not using 'id' as name (additionaly we use '#' or '_' as end char of primary / foreighn keys: example technicos.technico_ and agendamento_tecnico has fields agend_tech_ and technico_. But this is not common sense. It makes queries a bit more coplex (because you must fully qualify the fields), but make the databse schema mor readable (you know in the moment wich PK belong to wich FK)
other comment: the two assotiative (i never wrote that word before!) tables, joining technos and agendamento_tecnico have an own ID field, but they do not need that, because the two (primary/unique) keys of the two tables they join, are unique them selfes, so you can use them as PK for this tables like:
CREATE TABLE agendamento_tecnico (
technico_ int not null,
agend_tech_ int not null,
primary key(technico_,agend_tech_)
)
I have two tables set up in phpmyadmin- table userid and table data. The userid table has a single column userid which is the primary key. The table data has id|name|src| and a bunch of other information. The issue right now is that the column id which is a 16 character long string acts as a primary key in table userid and foreign key in table data. Now if the same user wants to upload more than one image then i am having to repeat the id in the table data and the table is becoming very large. Is there any other way to go about this(i am relatively new so im sorry if this sound rather stupid.). Finally is there actually any performance boost in this situation by indexing the id of the user in the other table as to me it seems like just a waste of space as im haveing to repeat the user id one more time in the table userid as compared to having a single table to hold both data and user id.
This is the case with One to Many Relations. I don't think that the table will grow that large to give you issues. This would be the way to go.
Alternatively, a strategy used by many cms and platforms to store settings. You can store JSON object having src of image into the image column. But this will add the overhead of updating image information every time a image created and deleted.
Short answer: No. You will have to repeat the userid otherwise you won't know who it belongs to.
I am trying to create a simple Registration Program using VB.Net and MySQL for its database. Here's my simple table for the basic Information
However, I am attempting to improve my basic knowledge in normalization of table and that's why I separated the Date field to avoid, let say in one day, the repeated insertion of the same date. I mean, when 50 individuals registered in one day, it will simply add a single date(record) in tblRegDate table instead of adding it up for 50 times in a table. Is there any way to do this? Is it possible in VB.Net and MySQL? Or rather, should I add or modify some field? or should I make a condition in VB.Net? The table above is what my friend taught me but I discovered that it doesn't eliminate the redundancy. Kindly give me any instruction or direct me to site where there's a simple tutorial for this. Thanks in advance!
here's my MySQL codes:
CREATE TABLE tblInfo(
Number INT AUTO_INCREMENT,
LastName VARCHAR(45),
FirstName VARCHAR(45),
MiddleName VARCHAR(45),
Gender ENUM(M,F),
BirthDate DATE,
PRIMARY KEY(Number));
CREATE TABLE tblRegDate(
IDRegDate INT AUTO_INCREMENT,
Date TIMESTAMP,
Number INT,
PRIMARY KEY(IDRegDate),
FOREIGN KEY(Number) REFERENCES tblInfo(Number));
As I see it in this case you don't have advanages of seperating a single field. You'll loose a lot of performance.
Table normalization isn't about don't having any redundant value. It's more about "Seperating the concerns"
Also it is important to not have an exploding complexity in your database. seperating single fills would end up in a database no one would be able to understand.
The Question is: Are there more informations on registration ? For Example Webpage, IP, .....
Than you should have two tables for example "Person" and "Registration". Then you would have two semantic different things which shouldn't be mixed up.
There are a lot of examples and information you can find via google. and wikipedia
http://en.wikipedia.org/wiki/Database_normalization
Actually it is not a good idea to seperate timestamp from the table.
You would need another table namely i.e timeTable. It would have two columns id and timestmap and you should reference this id in your tblRegDate table as foreign key.
Foreign key is an integer and has the size 4 bytes. Date on the other hand 3 bytes.
Therefore I would recommend you to keep date in your tblRegDate and not in a extra table
When you normalize DB structures, always keep it mind of ACID - http://en.wikipedia.org/wiki/ACID
Based on the fields you have, you should just keep it as a single table. Separating out the registration date is not a good design because you'll have to do a look up every time. In real life, you can consider indexing the reg date if your app always search or sort by regdate.
And if you FK RegDate table to the user table, it is also not efficient.
p.s. Also keep in mind that there are 4 levels of DB normalization. If you are new to DB design, you should consider learning how to move a DB design from 1st to 2nd, and 2nd to 3rd normal forms.
We rarely use 4th normal form in real life situation. Transaction systems usually stay at 3rd most of the time.
Hope that make sense.