I want to create database table using mysql for transport application. Here I want to add columns which are not fixed for every record. They are added dynamically for every record. For example, record 1 contains PoliceFees & StateBoundry whereas record 2 does not have these fields. record 3 might have some others fields and so on. So how to design table for such data??
Dynamic fields and MySQL (relational database)? I think no-SQL is a better solution to your problem.
But if that fields is all known you can create a table with all of them and set as nullable. So you only insert needed data.
Related
Is there any alternative to add new column to table that has 50 millions data?
I tried it with migration, and my database is down after trying to add 45 mins.
Is there any other solution to handle this operation?
This is not a good choice to alter a table which is populated with a large data set. As alternative you can always create a new table with the required column and make a relationship on that column to the table. It will be a effective way to do this.
I am working with a existing database's table from another application. I want to query newly inserted records in a fixed interval.
Normally, in a table with AUTO INCREMENT id, I can store the last fetched id and use it in the query like WHERE id > :last_id. However, this table doesn't use AUTO INCREMENT id but use uuid as primary key. So is there any way to fetch new records only?
This DB is using MySQL. I can't change the database structure. The data size is quite huge so I don't think passing fetched uuids in query like WHERE uuid NOT IN (:fetch_uuids) will be a viable solution.
Edit:
There is created field, but unfortunately there is no warranty that the records with smaller created will be inserted first. So there is the risk of missing records using it.
The data were inserted by other application, and I only have read permission in this database.
Your question doesn't state whether there is a column containing the creation time of the record. If this exists then you could use this.
You have stated you cannot change the table structure, but are you sure you cannot add columns onto the existing structure? Your problem could be solved by adding an auto-increment 'secondary' ID and/or record creation timestamp. If you cannot modify the existing tables, could you perhaps create a new table with this additional information?
A solution to your problem may be in this answer. You may be able to either add an additional column to the existing table, or alternatively insert ids into a new table where you create an ID based on a TRIGGER from the original table
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)
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.
In my case I have many table in my database.
My goal is to create a search engine where user can create all logical search he wants.
So I need to find a solution to generate all join based on user search critera.
In some case table has (1:n) links in other case (n:1).
One solution is to image all links and create all join, but I thinks it's a worse solution.
So if you have an idea, I'll very happy to read that.
Thanks a lot.
You can manage it like this don't know it is good or bad but a solution.
Create a new table containing all the searchable fields from various tables and reference to the record id to that table should also be stored in this table.
Insert the new record in this table whenever a new record inserted in those tables.
Search in this single table containing data from all other tables.
OR
consider to use VIEW