Approach 1- We have a different factories with the same code base structure. But different factories are storing different set of information like Factory A stores Parameter and its Values eg: Current = 110 and Factory B stores different parameter (eg:- Voltage = 10, etc) and its values. So we decided to go with different tables approach for different factories to avoid NULL values and defined Parameter as Columns (Eg:- Table_For_Factory_A Columns are Current, ParameterB,etc) Values of these parameters are stored as Rows in the database. If there are 10 parameters then one row was inserting into the database with its values.
Approach 2- Now, We are seeing a different approach from one of our team member saying that Keep the one Big table for factories with differentiating column called (Factory Name) and stored the Parameter and its values in one single table as rows.So if there are 10 parameters for one factory then insert the 10 parameters and its values as rows in tables where the table is growing exponentially.
Eg:- Table Columns are Parameter, value, FactoryName,...)
Kindly suggest which approach is better and why.we believed keeping the table smaller and minimal inserts will boast the performance and load on the database server. Also in Approach 2 parameter name gets repeated in every time user updates or saves it which is not good as per normalization. Please help us in deciding the approach.
factories table
---------------
id
name
...
parameters table
----------------
id
name
...
factory_values table
--------------------
factory_id
parameter_id
value
Related
For databases that support arrays -- for example, Postgres -- what would be the difference between the following two items:
`name` `field_a` (row array)
Tom [1, 2, 3]
And:
`name` `field_a` (single column)
Tom 1
Tom 2
Tom 3
The above would be two 'variations' of combining two tables:
name
`name`
Tom
numbers
`field_a`
1
2
3
If the array version vs the other version are not interchangeable, what are the main differences between the two?
Array stores the data in a single row and it needs some kind of processing (Different for different databases) before accessing/searching/sorting the particular value. It saves the size of table as repeating data occurs in single row but ultimately had more processing time when it comes to updating/searching/sorting and many more operations on the data stored as array.
Single values in each row is more preferred in databases as it is easy to find the record, update particular data, sort the data and many more operations.
So according to me only insertion of array is faster than the individual values and it saves some space of the table but all other operations will be time consuming. So it is better to store individual values in each row for database.
Databases are designed to handle single values more easily and operations on single values are faster than the arrays.
Simple example of complexity from your question: Replace 2 with 5 in field_a for name = 'Tom'
Another way of thinking about it is that an array named column is effectively column0, column1, column2 etc which the DB handles for you, whereas the table is normalized (1st Normal Form) into rows.
It is, however, harder to enforce a fixed size array in a normalized structure. You can enforce a maximum by defining a third table with numbers 0,1,2 and foreign-keying the child table on that. You cannot enforce a minimum like this (except in certain DBMSs with DB level constraints).
Rarely are fixed size arrays actually necessary. The majority of cases when they are used just break 1st Normal Form
I want to create a dynamic fields system. The idea is that the owner will be able to create dynamic fields for let's say, the customers of his company. The problem is that with the database structure that I came up with, requires the use of polymorphic association.
My structure is the following:
The fields table that consists of the following columns:
ID, FieldName, FieldType (The field type can be avoided, probably)
The field value tables (There are multiple value tables, one for every data type of the dynamic fields ex. A table to store the values that are DATETIMES, a table that stores the values that are DECIMALS and so on.).These tables have identical structure but with a different data type for their value column! They consist of the following columns:
ID, FieldID, CustomerID, FieldValue
Now, in order to get the field value I have to do a bunch of LEFT JOINs between the Value Tables and the Fields Table and keep only the value column that its value is not NULL, since that only one value column if any will have a value! Of course this isn't efficient at all and I am trying to avoid it. Any suggestions even if they require a completely different database structure at all are welcome. I am also using MySQL along with EntityFrameworkCore.
I have the following problem.
I have a table Entries that contains 2 columns:
EntryID - unique identifier
Name - some name
I have another EntriesMapping table (many to many mapping table) that contains 2 columns :
EntryID that refers to the EntryID of the Entries table
PartID that refers to a PartID in a seprate Parts table.
I need to write a SP that will return all data from Entries table, but for each row in the Entries table I want to provide a list of all PartID's that are registered in the EntriesMapping table.
My question is how do I best approach the deisgn of the solution to this, given that the results of the SP would regularly be processed by an app so performance is quite important.
1.
Do I write a SP that will select multiple rows per entry - where if there are more than one PartID's registered for a given entry - I will return multiple rows each having the same EntryID and Name but different PartID's
OR
2.
Do I write a SP that will select 1 row per entry in the Entries table, and have a field that is a string/xml/json that contains all the different PartID's.
OR
3. There is some other solution that I am not thinking of?
Solution 1 seems to me to be the better way to go, but I will be passing lots of repeating data.
Solution 2 wont pass extra data, but the string/json/xml would need to be processed additionally, resuling in larger cpu time per item.
PS: I feel like this is quite a common problem to solve, but I was unable to find any resource that can provide common solutions or some pros/cons to different approaches.
I think you need simple JOIN:
SELECT e.EntryId, e.Name, em.PartId
FROM Entries e
JOIN EntriesMapping em ON e.EntryId = em.EntryId
This will return what you want, no need for stored procedure for that.
I have a very large database I would like to split up into tables. I would like to make it so when I run a distinct, it will make a table for every distinct name. The name of the table will be the data in one of the fields.
EX:
A --------- Data 1
A --------- Data 2
B --------- Data 3
B --------- Data 4
would result in 2 tables, 1 named A and another named B. Then the entire row of data would be copied into that field.
select distinct [name] from [maintable]
-make table for each name
-select [name] from [maintable]
-copy into table name
-drop row from [maintable]
Any help would be great!
I would advise you against this.
One solution is to create indexes, so you can access the data quickly. If you have only a handful of names, though, this might not be particularly effective because the index values would have select almost all records.
Another solution is something called partitioning. The exact mechanism differs from database to database, but the underlying idea is the same. Different portions of the table (as defined by name in your case) would be stored in different places. When a query is looking only for values for a particular name, only that data gets read.
Generally, it is bad design to have multiple tables with exactly the same data columns. Here are some reasons:
Adding a column, changing a type, or adding an index has to be done times instead of one time.
It is very hard to enforce a primary key constraint on a column across the tables -- you lose the primary key.
Queries that touch more than one name become much more complicated.
Insertions and updates are more complex, because you have to first identify the right table. This often results in overuse of dynamic SQL for otherwise basic operations.
Although there may be some simplifications (security comes to mind), most databases have other mechanisms that are superior to splitting the data into separate tables.
what you want is
CREATE TABLE new_table
AS (SELECT .... //the data that you want in this table);
What I need is to re-arrange the columns in a table by the order specified in a row.
So if I had:
one four two three
1 4 2 3
How could I get:
one two three four
1 2 3 4
I have considered creating a new table and looking at each of the elements and its neighbor individually and copying the lowest element to the new table and repeating throughout the table until all the elements have moved.
Would this method work?
If so is it necessary I do it in VBA (I don't have much experience with this)?
Or is there a method in SQL?
Thanks for any help.
SQL is based on the relational model of data. One of the principles of the relational model is that the order of columns is meaningless.
But if you absolutely have to do this in Access, use a query, a form, or a report. You can put the columns in any order you like in any of these three, and it won't affect the base table at all.
If the order of items is important, they are typically stored in rows, not columns, for example, a table with the following fields : StudentID, ExamID, ExamDate can be sorted by StudentID and ExamDate to give a useful order, regardless of the order of entry. Furthermore, a crosstab query will allow the presentation of data in columns.
If the order of columns has become important, it is nearly always an indication of an error in the table design. You may wish to read Fundamentals of Relational Database Design, Paul Litwin, 2003