Cake has its conventions for automating some functionality interaction between it's models and the tables they reference. Foreign keys should be called people_id, if they reference a table called people. How do I handle a case where a row holds two people, and needs foreign keys for both people? It's obvious that I can't duplicate the column names, having two people_id columns.
Consider a competition where you have two competitors. Each competitor is represented by a row in the competitor's table. The competitions table needs to refer to both of those competitors. How can I do this wouldn't breaking the automatic functionality that Cake offers?
I found a link that describes how to do this perfectly.
http://book.cakephp.org/2.0/en/models/associations-linking-models-together.html#hasandbelongstomany-habtm
Related
I have multiple tables in a Laravel app with 1-to-1 relationship such as users , users_settings , user_financial
And some 1-to-many relationships such as users_histories
My questions are:
1. Should I always include incremental id at the first?
for example is the id necessary in the Table #2 below?
Table 1:
id (primary,increments) , name, email, password
Table 2:
id (primary,increments), user_id, something_extra
^ why does every guide include this? // e.g. https://appdividend.com/2017/10/12/laravel-one-to-one-eloquent-relationships/
Can't I just use user_id as primary key and skip the incremental key? because I want to auto insert it on table 2 as soon as data is inserted in table 1.
2. How should I name 1-to-1 and 1-to-many tables in Laravel? `
I searched but didn't find any naming convention for different type of relationships...
Currently I do:
users table with primary key id is the base.
1-to-1: users_settings with foreign key user_id
1-to-many: users_histories foreign_key user_id
many-to-many: users_groups foreign_key user_id
should the first two tables be named settings/setting , histories/history instead? sorry I'm a little confused here.
I actually asked a similar question around 2 days ago. Its up to you but I'd say yes. In my case if I don't auto_increment all my ids in the related tables, data won't be associated with the correct user. However, there is an argument for saying auto_increment columns should not be used in this case, but they are useful for other things. According to some, the relationships might not be as meaningful so it'd be up to you and down to the specifics of you data tables for how meaningful the relationship will be. Regardless, you should research more into the advantages of auto_incrementing all your ids in related tables, as well as possible disadvantages before deciding what you want to do. Either way is fine, but they offer different advantages and disadvantages- which you'll need to compare and what works best for your specific case.
This is a well debated topic about the primary key. IMHO, No, you shouldn't. Every column in database should have a purpose. Following this, for your example, I agree that the auto_increment id is redundant and this is simply because it doesn't have a purpose. The second table is still uniquely describing the user so that the primary key should be the user_id.
Beside the above, there is another principle for me to decide whether I need the auto_increment id: whether I can see a table as an entity. For example, user is clearly an entity, but a relationship is not (in most cases), i.e., composite key can serves the purpose. But when an relationship table is extended to have more attributes and it starts to make sense for it to have an auto_increment id.
I don't have much experience on Laravel, but the naming for a database table should not be dictated by a framework. Comparing history and user_history, what a new DBA or developer expect from the two names without looking its data? user_history describes the table more precisely
Is it possible to add a constraint that checks that TWO columns are unique in PostgreSQL 10? I've looked around but I can't find anything related to my specific need.
My issue is that I have to keep track of individual IDs (tag), associated to secondary IDs (hub). I can't set my tag IDs to be unique because they'll appear multiple times associated to hub IDs. I also can't set hub IDs unique because they'll have a bunch of tag IDs associated to them.
Is there a way to say (tag 123 and hub 456) unique, but tag 123 can still be logged if hub is 789, and vice versa?
The root of this is because the ON CONSTRAINT DO UPDATE doesn't seem to work without unique constraints, and I'm now stuck.
References, solutions, other related problems that were solved, any help is appreciated!
You need to define a primary key made of those two columns. This way you can have two or more rows in your table with the same value on the first column of the primary key, but different values on the second column, and vice versa.
Also, if you don't already, you can use pgAdmin, which is a visual tool that helps you create a database and defining tables, columns, data types, constraints, primary keys, etc. with an easy user interface.
indexes can be on multiple columns
CREATE UNIQUE INDEX name ON table (tag,hub);
11.6. Unique Indexes
I have a question about a database design in MySQL.
There are two groups of people i have a separate table for. Call them TABLE student and TABLE professor.
I can give each of them assignments from TABLE assignments.
Each person in each group can have multiple assignments, and each assignment can have multiple people. So to keep track of these, I have two mapping tables, call them TABLE student_assignment and TABLE professor_assignment.
My question comes here. I have a single table TABLE assignment_results that I want to store the results from all the assignments in. I would like for each line of each mapping table to have a single record...so it seems to make more sense to have a separate results table for each group of people??? TABLE prof_assign_results and TABLE stud_assign_results
Or would it make sense to combine the mapping tables and avoid splitting altogether? Is it possible to define a unique index containing three columns? Would the NULL values (in either the student or professor columns) interfere with that?
I am developing a MySQL db for a user list, and I am trying to determine the most efficient way to design it.
My issue comes in that there are 3 types of users: "general", "normal", and "super". General and normal users differ only in the values of certain columns, so the schema to store them is identical. However, super users have at least 4 extra columns of info that needs to be stored.
In addition, each user needs a unique user_id for reference from other parts of the site.
So, I can keep all 3 users in the same table, but then I would have a lot of NULL values stored for the general and normal user rows.
Or, I can split the users into 2 tables: general/normal and super. This would get rid of the abundance of NULLs, but would require a lot more work to keep track of the user_ids and ensure they are unique, as I would have to handle that in my PHP instead of just doing a SERIAL column in the single table solution above.
Which solution is more efficient in terms of memory usage and performance?
Or is there another, better solution I am not seeing?
Thanks!
If each user needs a unique id, then you have the answer to your question: You want one users table with a UserId column. Often, that column would be an auto-incremented integer primary key column -- a good approach to the implementation.
What to do about the other columns? This depends on a number different factors, which are not well explained in your question.
You can store all the columns in the same table. In fact, you could then implement views so you can see users of only one type. However, if a lot of the extra columns are fixed-width (such as numbers) then space is still allocated. Whether or not this is an issue is simply a question of the nature of the columns and the relative numbers of different users.
You can also store the extra columns for each type in its own table. This would have a foreign key relationship to the original table, using the UserId. If both these keys are primary keys, then the joins should be very fast.
There are more exotic possibilities as well. If the columns do not need to be indexed, then MySQL 5.7 has support for JSON, so they could all go into one column. Some databases (particularly columnar-oriented ones) allows "vertical partitioning" where different columns in a single table are stored in separate allocation units. MySQL does not (yet) support vertical partitioning.
why not build an extra table; but only for the extra coloumns you need for super users? so 2 tables one with all the users and one with super users's extra info
If you want to have this type of schema. try to create a relation
like:
tb_user > user_id , user_type_id(int)
tb_user_type > user_type_id(int) , type_name
this way you will have just 2 tables and if the type is not set you can set a default value to a user.
I have two preexisting tables that were created by a CMS. I've mapped them in Symfony2 and I am trying to establish a relationship between two of the tables but I am now noticing that the CMS created these tables without a foreign key. This table table_uploads has a column that every other table is related to called column_table_name and column_record_num.
So assuming we have three tables... table_students, table_uploads, and table_teachers, the table table_uploads will have a value of either students or teachers in column_table_name to show its relation to the other two tables as well as a number in column_record_num that corresponds to the other table's primary key. Neither of the three tables actually have a defined foreign key however.
In Symfony, I'd like to call a table
$students = $this->getDoctrine()->getRepository('SchoolBundle:Students')->findAll();
and then load the related records from another table in such a way like (I know select_related doesn't actually exist, but this is essentially the functionality I'm looking to create)
$students->select_related()
Is this at all possible without the existence of a foreign key? The only way I can think of doing it is grabbing the column values from $students and running another query to other table with these values and merging the two results.
You could create a custom repository method that would join unrelated tables. DQL join between unrelated entities?