Forewarning, I am new to SQL. Sorry in advance if this question doesn't make sense or my concept of what I'm trying to do is just completely off.
That aside, I'm trying to add in multiple columns from varying tables into a set of columns in a centralized table, and ideally I'd do this simultaneously. Am I on the right track thinking this should be accomplished through joins? Maybe unions?
I'd appreciate it if someone could show me an example or point me in the right direction. Thank you!
Edit for clarification: I've got 3 tables. The old one, a new one, and a mapping table connecting the two,. I need to know how to populate the new table's columns simultaneously with the old table's values, via the mapping table.
I think maybe you should look more into Primary and Foreign Keys, and i suppose your table could have as foreign keys the other table primary keys, so this table would represent a relation from multiple tables.
Related
I have been tasked with creating a database but first i have to create a design of it as an erd, i am using for this a program named toad data modeler, but i have one problem with the foreign keys and relations in general.
As seen by this picture(the database is in Polish but you should understand what i mean) :
https://i.ibb.co/Qj6r7Dk/436343664.jpg
The row id_pacjenta shows up in entity9 without a reason, i didn't create a relation between pacjenci and entity9, only entity 9 and Wizyta, Why such a behavior occurs? Also i can't delete it because it automatically deletes also the row that i need (id_wizyty) What i suppose happen is that it takes that row that i don't want (id_pacjenta) from the relationship that i made between Pacjenci and Wizyta, but i don't know why and if it should work that way, what steps should i take to fix this? Thanks a lot in advance!
There's nothing weird about it.
entity9 references wizyta and the primary key of wizyta includes a column id_pacjenta, so of course there has to be a corresponding column for wizyta.id_pacjenta in entity9, which is part of the foreign key referencing wizyta.
So the tool is correct to add both columns, when you introduce a relationship between the tables.
I have different tables in my scheme with different columns, but I want to store data of when was the table modified or when was the data stored, so I added some columns to specify that.
I realized that I had to add the same "modification_date" and "modification_time" columns to all my tables, so I thought about making a new table called DATA_INFO so I won't need to do so, but every table has a different PRIMARY KEY and I don't know which one to add as FOREIGN KEY to the DATA_INFO table.
I don't know if I have to maybe add all of them or is there another way to do what I need.
It's better to have the same "modification_datetime" column in all tables, rather than trying to keep that data in a central table.
That's what we have done at every shop I've worked in.
I want to emphasize that a separate table is not reasonable for this purpose. The lack of an obvious foreign key is a hint.
Unlike Tab Allerman, tables that I create are much less likely to be updated, so I have three additional columns on most tables:
CreatedBy -- the user who created the row
CreatedAt -- when the row was creatd
CreatedOn -- the system where the table was created
The most important point is that this information can -- in many databases -- be implemented using default values rather than triggers. That is a big advantage of working within a single row. The fewer triggers, the better.
I have a "Groups" table, a "GroupMembers" table, and a "MemberType" table. In the "GroupMembers" table I have a foreign key for "Group", a foreign key for "MemberType", and a lookup field called "Member", which is a lookup to one of one of 3 tables: "JobTitle", "LaborDepartments", of "LaborSubDepartments".
Basically, members of the groups can come from one of 3 tables, so I added the "MemberType" column so I know which table the link comes from.
So I guess my question is: is this normal? Is there a better way to do this?
Just looking for other people experience. I hope the situation makes sense.
I am using SQL Server 2008.
Thanks,
Tim
in case anyone stumbles upon this, here is a good discussion of what I'm up against Foreign key referring to primary keys across multiple tables?
I should have searched better first.
Relationship tables mostly contain two columns: IDTABLE1, and IDTABLE2.
Only thing that seems to change between relationship tables is the names of those two columns, and table name.
Would it be better if we create one table Relationships and in this table we place 3 columns:
TABLE_NAME, IDTABLE1, IDTABLE2, and then use this table for all relationships?
Is this a good/acceptable solution in web/desktop application development? What would be downside of this?
Note:
Thank you all for feedback. I appreciate it.
But, I think you are taking it a bit too far... Every solution works until one point.
As data storage simple text file is good till certain point, than excel is better, than MS Access, than SQL Server, than...
To be honest, I haven't seen any argument that states why this solution is bad for small projects (with DB size of few GB).
It would be a monster of a table; it would also be cumbersome. Performance-wise, such a table would not be a great idea. Also, foreign keys are impossible to add to such a table. I really can't see a lot of advantages to such a solution.
Bad idea.
How would you enforce the foreign keys if IDTABLE1 could contain ids from any table at all?
To achieve acceptable performance on joins without a load of unnecessary IO to bring in completely unrelated rows you would need a composite index with leading column TABLE_NAME that basically ends up partitioning the table into sections anyway.
Obviously even with this pseudo partitioning going on you would still be wasting a lot of space in the table/indexes just repeating the table name for each row.
Isn't it a big IF that you're only going to store the 2 ID fields? If I have a StudentCourse (or better yet Enrollment) table that has StudentID & CourseID, but wouldn't EnrollmentDate go in this table as well since not all students enroll on the first day of class. Seems like a bad idea to add this column to an already bloated table where most records will be null.
The benefit of a single table could be a requirement that the application has the ability to allow user/admin to create these relationships with data (Similar to have a single lookup or reference list table) and avoid having to create a new table to address these User Created References. Needing dynamic querying may benefit as well. An application that requires such dynamic data structure requirements might be better suited for a schemaless or nosql database.
Is there a way to map one of the the columns contents of a MySQL table to an enum on another table in MySQL? I thought this would be a no brainer, but there doesn't seem to be any info that I can find on the subject.
Any advice or help on this matter would be cool and if it's not possible, does anyone know of an internal reason why it wouldn't be possible?
Best regards everyone :)
Gary
The enum type is handy as a one-off, but it doesn't scale well to multiple tables and isn't standard SQL either.
Best thing to do here is to use normal tables and relations:
Define a new table to hold the list of possible values; let's call it Master1
In the other two tables (let's call them Table1 and Table2), don't make the field an enum; just make it a normal field with a foreign key relation to Master1.
The foreign key relation will do the job of restricting to a list of possible values; and because foreign keys and relations are absolutely standard SQL, this approach will have other benefits - for example reporting tools can recognise the foreign key and understand how to use the related data.
If it doesn't do it, don't do it
Surely you just want a table of possible keys and then a foreign key mapping to that.
If you want a table with possible enum values and restrictions, go for groupings via another table or a groupid in the same table (if group members are unique).
Smells like table-stink though JOIN wise. Maybe best doing this in a stored procedure or in the app code and mapping it to a native value?