I have two tables, having many-to-many relationship between them (user, shop) and a pivot table (visit) that links them together:
table user {
id,
name
}
table shop {
id,
name
}
table visit {
id,
user_id,
shop_id,
date
}
On the user's backend page, I'd like to be able to add multiple visits to the same shop. I use relation config, and a table is displayed, having an "Add" button on top. The problem is that when I press the "Add" button, the list of shops appears, but that won't contain any shop, which has already been added to the pivot table for the current user.
How could I resolve this in the simplest way?
In the RelationController it's being prevented to add multiple times the same link in the pivot table (https://github.com/wintercms/winter/blob/develop/modules/backend/behaviors/RelationController.php, lines 936-945). One solution would be to extend the RelationController, to override that method and to delete these lines.
I used a different approach, where I transformed the pivot table to a regular table. Now there are one-to-many relationships between visit-user and visit-shop. This way it's possible to add the same relationship multiple times.
Related
I'm working on the database (MySQL) - car dealership. Since the product (car) has a lot of features and unique values (gearbox, model, manufacturer...), I wonder, how to create a well designed database for it.
Should I use:
Table cars
columns -> id, name, manufacturer, model, gearbox...
Or:
Table cars
columns -> id, name, manufacturer_id, gearbox_id...
Table manufacturers
columns -> id, name
Table gearbox
columns -> id, name
There are a lot of unique values as I mentioned and I think it's not good to store them again and again, but if I create a lot of tables + link them with link table to product table (car), there will be a lot of joins when I make a query to get all of the values.
And these are only few of them, there are much more values I need to store for every product in the database.
You have 3 options here:
You could store each car as a separate table and then have a row corresponding to the gearbox, etc. This is awful, no one does it, don't do it.
You could serialize all the gearbox, etc. data as json strings and put them in your car cells. This is also awful, some people have stupidly done this, but not that often. Don't do it.
You could do things the normal, good way and implement separate tables for every class of object with foreign keys linking them. This is the way to go.
So I'm trying to work on a small app that would allow you to have a grocery list that can be edited by multiple people via their mobile phone. So I'm trying to design the database I will use on the backend. I'm having trouble figuring out how to relate all the tables. User will be able to be apart of multiple lists, and each list will be accessible by multiple people. ( I believe this is called a many-to-many relationship?)
So far my tables look as follows:
User(id, name)
List(id, Name)
List_item(id, List_id(key), name, amount)
The list to list_item ID relationship is easy enough, but how do I go about modelling the relationship between Users and Lists? Do I need a separate join table:
User-to-List(User ID,List ID)
I'm trying to come up with the most efficient structure as possible, Thanks!
Edit: Only the user needs to know about all the lists he is associated with, the list doesn't need to keep track which user are associated with it. At least for the initial app!
Many-to-many:
CREATE TABLE ListsUsers (
list_id ...,
user_id ...,
PRIMARY KEY(list_id, user_id),
INDEX(user_id, list_id)
) ENGINE=InnoDB;
Then use suitable JOINs to connect the tables when doing a SELECT.
I need to create a mySQL database that keeps information about vehicles. My instincts were to create one table with as many columns as I need, but then I read about the problems in doing so. After researching, I think I'm on the right track with the following structure:
Vehicles Database
Motorcycles Table
id|road|cruising|touring|
Cars Table
id|sedan|coupe|hatchback|
Colours Table
id|green|red|blue|black|silver|white|yellow|etc..
Make Table
id|ford|chevrolet|gm|toyota|bmw|etc..
Quadrant Table (1-4)
id|motorcycle|car|truck
So basically I have a table for the objects - cars, motorcycles, trucks - and then tables for the fields/properties - Colour, Make, etc. and then a table for the Quadrant the vehicle is seen in, with a value of 1-4 where each row is an instance of only one vehicle.
The problem I'm having is understanding where the primary and foreign keys need to be in order for me to be able to organize the data:
By each individual vehicle selected along with its fields
By quadrant, showing each vehicle and their respective fields
The user counting cars should be able to input the vehicle type, the field values and the quadrant it's seen in and the db gets populated - and then I need to call the data by quadrant to analyze the data.
I don't know if or how a JOIN statement will be used? How do I go about structuring this database to suit my needs?
FWIW, dba.stackexchange says basic SQL questions belong here, so I hope I'm in the right place.
Can you tell, what is your exact need for the database i.e what functionality you need.
I suggest tables like following:
1) Vehicle table:
id|type which might contain info like 1|Motorcycle, 2|Car
2) category table:
id(foreign key)|category|color which contain info like 1|touring|Black, 2|Car|Hatchback
3) Make table: (if you need to create another table)
id (foreign key to table 1)|Make
I have not understood the functionality of quadrant table but with these 3 table you can create views according to your needs and play around with it.
From my point of view:
I will create a table CarBrands, with columns Id, BrandName, Description, which will serve as a look up.
Then I will create another table Cars with Id, CarBrandId, ColorId (From Colors Table), Description, which is your table with user records.
Same with your other entities. I suggest you search about Entity Relationship Diagrams, a good way of helping you come up with a good design.
Also look at this old StackOverflow question, this will help you.
A new requirement has come into an existing application. Current, we have an organization table, and it has a child table CalendarEvents. Now, the request is to allow either the User table, the Organization table, or the Division table own calendar events. I am thinking something needs to change because right now, this would leave me with creating the following table structure:
Organization (organization_id)
User (user_id, organization_id)
Division (division_id),
Calendar (calendar_id, organization_id, user_id, division_id),
CalendarEvents (calendar_event_id, calendar_id)
I am trying to avoid linking Calendar to multiple parents. Is there are better way to do this that I am missing? (An organization/user/division can have multiple calendars, but only one org/user/division can own a calendar)
Thanks for any input.
Since User instances and Organization instances can have their own events, I'd be inclined to make separate tables:
Organization
OrganizationCalendarEvents (with FK to Organization)
User
UserCalendarEvents (with FK to User)
In this way, the two entities can control their own events. In addition, if you keep the structure the same, you could use a single base class in your middle-tier which can load from either table.
If the CalendarEvents for each entity (User, Organization, and Division) are mutually exclusive, I might start out with three identical tables of events: UserCalendarEvents, OrganizationCalendarEvents, and DivisionCalendarEvents.
A better solution, though, may be to define those as three tables of links:
UserCalendarEvents
user_id
calendar_event_id
OrganizationCalendarEvents
organization_id
calendar_event_id
DivisionCalendarEvents
division_id
calendar_event_id
Yes. There is a technique called "morphing" which is appropriate for your case. Your CalendarEvents table should have a field called "owner_type" and another field called "owner_id". "owner_type" would indicate the table to which "owner_id" is a foreign key for the particular row. If owner_type is 1, then owner_id is a user_id; if owner_type is 2, then owner_id is an organization_id. And so forth.
One table column for many fk tables? .
and
multiple tables need one to many relationship .
If you want the DBMS to enforce the integrity rule that any calendar event is always either for an X, or a Y, or a Z (and just one of them), then you'll have to create three tables.
You can always create a view of "all calendar events" by UNIONing them together (after projecting away the owner column, of course). Obviously, that view is not updatable.
If you set up three separate tables with only a "link" to a "shared" events table, you still won't be guarded from having "orphaned" events.
I have two tables (persons and projects) which are in a many-to-many table, thus linked together by a third table persons_projects
In ms access I now created a form showing data from the projects table.
What I want is to have a subform showing all persons- datasets which participate in this project. In this subform it should also be possible to add (or delete) persons from this project—a drop-down seems the best choice here.
How can I do this? I’m able to show all participants, but I’m not able to add them. seems like I have the “insert into view” problem again, since I need persons and persons_projects to show the correct datasets. but as I’m only changing/adding rows in a single table (persons_projects) I don’t see why access is bitchy again.
You should not need persons, only persons_projects. I assume that persons_projects consists of:
person_id -> FK ) Combined as PK, perhaps, if not, an autonumber PK
project_id -> FK )
and (recommended) a datetime stamp and user field.
The subform is set-up with a Link Child and Master Field of project_id, which will be automatically completed by Access, and a combobox similar to:
Control Source: person_id
Row Source: SELECT person_id, surname & " " & forename, some_field FROM persons
Bound Column: 1
Column Count: 3
Column Widths: 0cm;2cm;2cm
Edit re Comments
It is possible, though often a little more difficult, to include both tables and have an updatable recordset, the query (view) should include both project_id and person_id from the junction table.
Sounds like persons is the driving dataset here since you want to be able to link it to multiple projects as well as delete the person record.
Base your form on the Persons table. A subform should be based on the person_projects table and linked by the corresponding id's. You can use a combo box on the projectid in the subform and have some other field displayed so the user can identify the project (name?). You may want to show all the project data for each project on this form, but you may find it getting very confusing to the user. Having a separate form that you can 'pop-up' to give more project information may be a better choice.
If you want to delete a person, you can just delete from the persons table, but you need to decide if you want any orphan records in the person_projects table (Which you shouldn't). It's easy in Access to establish a link with referencial integrity (cascading update and delete optional). It's up to you as to how robust this needs to be.