I have a sql table A and i need to link it to 4(B,C,D,E) other sql tables of similar structure but different column names and types.I have two approach in mind:-
1.) I can make a single table(F) out of 4(B,C,D,E) and link it to main table(A) but then the number of columns will be too many and thus it will cause lots of empty spaces in table.
2.) I can link all the 4 tables B,C,D,E to A and that will save me empty spaces but it will make 4 foreign keys and the foreighn keys will take up unnecessary space in tables.
Not sure of this approach but i was thinking
I can make a dynamic table to merge all 4 tables to remove the extra spaces in approach 1.
Can anyone suggest me how can i make dynamic approach work or is there any other concept i can use?
Link to the db table snapshot http://i60.tinypic.com/23hopcy.jpg.
Related
So I have the following 4 Tables in here: SQL Fiddle with 4 Tables
I would like my 4th Table, Certificates to be automatically filled/updated since it doesn't have anything unique.
It just haves 3 Foreign Keys.
I want to be able to use that as a reference for linking my Tables with JOINs.
Thanks a lot!
It's a bad idea to duplicate data - but you can create a view. Views allow you to save a select statement and treat the result as a table (when running a select statement, insert/update/delete is a different question).
Can I use (and if yes -- then how) Yii2 Faker to fill entire table (all columns) with random data for n records without knowing table structure? Can Faker check schema and do this for me or do I have to write my own code, that will use it in this scenario?
I want, for example to test, how large my database will become, when I feed it with let's say millions of records. Since my database contains many tables and each table has different structure, I would like to use something automated rather than writing my own code for each table and each structure.
Is this possible with Faker or possibly any other extension to Yii2?
Take a look at Gii, it goes through all the columns on a table and does some things. You can also figure out that columns are foreign keys and get data from other tables.
I do not know of anything that does this for you automatically it is doable.
1 thing, you have to give it an order to fill in the tables, it will not work unless you fill the tables in a specific way especially with the foreign keys.
In my database there is one table 't_object' and one table 't_search_object'. These two tables are quite similar to each other.
Both tables have one column called 'properties' where the properties are stored separated with commas, e.g.: "1,4,8".
That's why there is an additional table called 't_object_properties' with two columns(id, name) and data records like: (1, propertie1) ...
The problem with having one column 'properties' and one additional table, is that I have several values in just one column.
So I want to know if this is a good way of designing a database..?
I am thinking if it wouldn't be better to have columns like 'is_propertie1', 'is_propertie2', and so on in both tables 't_object' and 't_search_object'? The problem would be to update two tables if another propertie would be added.
So what would you advise? 1) or 2) or is there another way to solve this issue?
It's always wise to have an extra table rather than a comma-separated list of values in MySQL (and all RDBMS systems) to represent one-to-many relationships like object-property. Relational data management is designed around this very concept. Read about "normalization."
Comma separated lists of values, and long lists of columns, both give rise to real peformance and usability problems, especially when your data base gets larger.
Go with your first choice, get rid of the properties column containing lists of values like '1,4,8', and don't look back.
I am editing a schema in MySQL workbench. I imported the schema from a mysqldump. Since it doesn't include any foreign keys, I am adding the relationships manually.
Here is my problem: When adding a relationship, workbench adds a column with the foreign key to one of the tables. However, the column is already present. I have to remove the current column and change the name of the new column to the name of the original column.
I illustrated it in the attached pictures:
The two original tables
The two tables after adding the relationship
After removing original column and renaming new column - this is what I want in one step
Is there a way to avoid this, and choose the target-column when adding the relationship, so that I don't have to edit a larger number of tables?
(Edited to add: The example tables are not the tables I want to connect, in case somebody recognizes the Drupal 8 tables - they were just short enough to aid as an example).
Most of the relationship commands automatically create columns to host the new relationship. However, there's one tool that allows to select existing columns for a 1:n relationship. See in the tools toolbar. The last icon contains a picker symbol. This is the one to use. For quick access simply press '6'.
I do have a datbase with multiple tables.
this multiple table is related to single name for example..
Table 1 contains name of the person, joined date,position,salary..etc
Table2 contains name of the person,current projects,finished,assigned...etc
Table 3 contains name of the person,time sheets,in,out,etc...
Table 4 contains name of the person,personal details,skill set,previous experiance,...etc
All table contains morethan 50000 names, and their details.
so my question is all tables contains information related to a name say Jose20856 this name is unique index of all 4 tables. when I search for Jose20856 all four table will give result and output to a front end software/html.
so do I need to keep multiple table or combined to a single table??
If so
CASE 1
Single table -> what are the advantages? will result will be faster? what about the system resource usage?
CASE 2
Multiple table ->what are the advantages? will result will be faster? what about the system resource usage?
As I am new to MySQL I would like to have your valuable opinion to move ahead
You can combine these into a single table but only if it makes sense. It's hard to tell if the relationships in your tables are one-to-one or one-to-many but seem to be one-to-many. e.g. A single employee from table 1 should be able to have multiple projects, skills, time sheets in the other tables. These are all one-to-many relationships.
So, keep the multiple table design. You also should consider using an integer-based primary key for the employee rather than the name. Use this pkey as the fkey in your other tables and you'll see performance improvement. (Also consider the amount of work you need to do if and when you want to change the name. You have to change all the names in all the tables. If you use a surrogate key, the int pkey, as suggested above, you only have to update a single row.)
Read on the web about database normalization.
E.g. http://en.wikipedia.org/wiki/Database_normalization
I think you can even add more tables to it. It all depends on the data and the relations.
Table1 = users incl. userdata
Table2 = Projects (if multiple users work on the same project)
Table3 = Linking user to projects (if multiple users work on the same project)
Table4 = Time spent? Contains the links to the user and to the project.
I think your table 4 can be merged into table 1 cause it also contains data specific to 1 user.
There is probably more you can do but as already stated it all depends and the relations.
What we're talking about here is vertical table partitioning (as opposed to horizontal table partitioning). It is a valid database design pattern, which can be useful in these cases:
There are too many columns to fit into one table. That's pretty obvious.
There are columns which are accessed relatively often, and some that are accessed relatively rarely. For example, if you very often need to display columns joined date,position,salary and columns personal details,skill set,previous experiance very rarely, then it makes sense to move these columns to separate a table, as it will (probably) improve performance in accessing those most commonly used. In MySQL this is especially true in case of TEXT and BLOB columns, since they're stored apart from the rest of the fileds, so accessing them takes more time.
There are NULLable columns, where majority of rows are NULL. Once again, if it's mostly null, moving it to a separate table will let you reduce size of your 'mani' table and improve performance. The new table should not allow null values and have entries only for rows where value is set. This way you reduce amount of storeage/memory resources as well.
MySQL specific - You might want tom move some of your columns from nnoDB table to MyISAM, so that you can use full text indexing, while still being able to use some of the features InnoDB provides. It's not a good design gnerally speaking though - it's better to use a full text search engine like Sphinx.
Last but not least. I'd suggest using a numeric field as a key joining all these tables, not a string.
Additional reading aboout MySQL partitioning (a bit outdated, since MySQL 5.5 added some new features)