I have 4 tables, "Player", "Crafting", "Battling", "Gathering".
I made a relationship rule for Crafting, Battling and Gathering to share information to the Player table.
The problem is that when I go to the player table it makes me choose which other table's information to display instead of showing all 3.
How can I make a relationship so that I can view all three other tables from the player table?
It's impossible and you don't need this. You already have all relationships you need. Just create a form based on Player table with 3 subforms and link them on form, no additional code required in simple case.
Also I would recommend do not use username as primary key, use Autonumber data type instead.
Related
The database i'm trying to create have four tables. tblPatient information, tblparasitology tests, tblserology tests and tblbiochemical tests. All the later three tables are related to patient information table. What i want to ask is that, is there a problem if i use the primary key in the table patient information to foreign keys of all the other tables? in other words how many tables (foreign keys) can be related to a primary key on one table?
There is really no practical or particular limit here.
however one tip, one concept to keep in mind?
While you can setup all these related tables, to create forms that edit the data?
Each form is STILL based on the one base table.
So you can create a form based on tblPatients.
So allow view and editing and adding of say tblserology results?
That will become a sub form. NOTE VERY careful here that the form tblPaitent is based ONLY on that one table. And the child table (and child form (ie: sub form) tblserology will ONLY be based on tblserology table. So the forms to hook up, wire up the relatonships between the tables are STILL only based on the single table.
To allow editing of related data, you thus use sub forms. If you do this correctly, then no code is required to edit and display and maintain say display of test results for a given patient.
So each and all tables will have a primary key (auto number id).
To realate a child table back up to a parent table, you create a plane jane long number column. This value will be automatic setup for you if you follow the above advice for a main form, and then a sub-form for the child table data.
In relational databases, if we want to create a database for a football tournament for example, we consider the tournament as the mini-world (the unit for which we want to create a database and collect data). Therefore, we may create tables such as matches, teams, and so on. And, we don't create a table called tournament since we have only THE TOURNAMENT for which we are doing all this.
In practice, that's what I used to do. But, what if I want to save in my database some attributes about the tournament, such as its name, the date and the country in which it takes place... What can I do? Is it a good practice to create a table tournament that has only one record? And if yes, what about foreign keys? Is it good in this case to add the ID of the tournament as a foreign key in the tables matches, teams...? If not, what can be the best practice?
Why I want to store the tournament information in the database? Because I want to create a webpage that reads only dynamic data. I don't want to add those information (tournament name, date...) as static data on the web page.
I am also thinking about the benefit from the possibility of future evolution of the product. Later on, I may have more than one tournament and having the tournament table part of the database will allow a smooth integration of more tournaments without modification of the metadata.
Yes, it is typical to use a row to store relevant single values. (Frequently this is done for parameter settings). But you don't need an id in this row for the tournament or foreign keys to it in other tables until you have multiple tournaments.
Yes, this helps extend to multiple tournaments. It also helps in extending to a "temporal"/historical version of the database where we timestamp each row by when it held so that we can query about the state that was current at a given time. (This typically involves further normalization to have separate tables for columns that change together but possibly at different times from other column sets.)
In moving to multiple tournaments, as with any schema change, it is helpful to redefine the names of old tables as views of new tables. Unfortunately updates through views are typically poorly supported by SQL DBMSs so in that respect it can be useful to have a multiple-tournament-capable design right from the beginning.
So I am building out a set of tables in an existing database at the moment, and have run into a weird problem.
First things first, the tables in question are called Organizations, Applications, and PostOrganizationsApplicants.
Organizations is a pre-existing table that is already populated with lots of data in regards to an organization's information which has been filled out in another form on another portal. EDIT: I cannot edit this table.
Applications is a table that records all information that a user inputs in the application form of the website. It is a new table.
PostOrganizationsApplicants is basically a copy of Organizations. This is also a new table.
The process goes:
1. Go to website and choose between two different web forms, Form A pertains to companies who are in the Organizations table, and Form B pertains to companies who are not in that table.
2a. If Form A is chosen, a lot of the fields in the application will be auto-populated because of their previous submission.
2b. If Form B is chosen, the company has to start from scratch and fill out the entire application from scratch.
3. Any Form B applicants must go into the PostOrganizationsApplicants table.
Now I am extremely new to SQL and Database Management so I may sound pretty stupid, but when I am linking the Organizations and PostOrganizationsApplicants tables to the Applications table, FK's for the OrganizationsID column and PostOrganizationsApplicantsID columns will have lots of empty spaces.
Is this good practice? Is there a better way to structure my tables? I've been racking my brain over this and just can't figure out a better way.
No, it's not necessarily bad practice to allow NULL values for foreign key columns.
If an instance of an entity doesn't have a relationship to an instance of another entity, then storing a NULL in the foreign key column is the normative practice.
From your description of the use case, a "Form A" Applications won't be associated with a row in Organizations or a row in PostOrganizationsApplicants.
Getting the cardinality right is what is important. How manyOrganizations can a given Applications be related to? Zero? One? More than One? And vice versa.
If the relationship is many-to-many, then the usual pattern is to introduce a third relationship table.
Less frequently, we will also implement a relationship table for very sparse relationships, when a relationship to another entity is an exception, rather than the rule.
I'm assuming that the OrganizationsID column you are referring to is in the PostOrganizationsApplicants table (which would mean that a PostOrganizationsApplicants can be associated with (at most) one Organizations.
I'm also assuming that PostOrganizationsApplicantsID column is in the Applications table, which means an instance of Applications can be associated with at most one PostOrganizationsApplicants.
Bottomline, have a "zero-or-one to many" relationship is valid, as long as that supports a suitable representation of the business model.
Why not just add a column to the Organizations table that indicates that the Organization is a "Post" type of organization and set it for the Form B type of applicants? - then, all your orgs are in one table - with a single property to indicate where they came from.
If you can add a new record to Organizations (I hope you can) just
create FK from Organizations as PK of PostOrganizationsApplicants. So
if Organizations has corresponding record in PostOrganizationsApplicants - it's "Post"!
Thanks everybody, I think I found the most efficient way to do it inspired by all of your answers.
My solution below, in case anyone else has a similar problem...
Firstly I will make the PK of PostOrganizationsApplicants the FK of Organizations by making a "link" table.
Then I am going to add a column in PostOrganizationsApplicants which will take in a true/false value on whether they completed the form from the other portal or not. Then I will ask a question in the form whether they have already done the other version of the form or not. If the boolean value is true, then I will point those rows to the Organizations table to auto-populate the forms.
Thanks again!
I have a table called "games" in which will have games.id, games.name and games.modus fields. I know the ID should be auto increnment and integer, games.name a text value and the problem is I don't know what to make games.modus, because it will have "multiple options", another tables called "modes" will be created with modes.id and modes.name, the modes.name will have the following rows: "Singleplayer","Multiplayer","LAN","Online","LAN Co-op","Online Co-op","Offline Co-op",
and I need to be able to select multiple of those rows into the "games.modus" field. How would I achive this?
What you are describing is an N-to-N relationship. You need to model a third table so that you can have an 1-to-N and an N-to-1 relationship. N-to-N cannot be modeled otherwise, to my knowledge.
In your case, that means that you would need a table like modes_per_game which would contain a foreign key to the game id and to the mode id. If you want to make the result a bit more friendly then a simple query and form will do the job but it has to be structured with a middle table to make the links.
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.