I made an EER diagram in MySQL. The end goal is to be able to have a few tables (fleet1, fleet2, fleet3) that are comprised of a unique certificate id, but have multiple vendors and multiple vessels. In each fleet, the vendor can appear more than once, but each vessel only once. When everything is complete, I will connect this database to mail merge and be able to query data from each fleet.
I want to see all of the columns from the vendor table, as well as all of the columns from the vessel table inside of each fleet table
Would a linking table suffice to link the tables?
I tried a one-to-many (creating a linking table which would be each fleet table), but I want each fleet table to comprise of all of the vendor information and all of the fleet information, so that when I do a mail merge I see certificate id, all vendor info, and all vessel info.
I am in 2NF, but can I simplify further into 3NF?
Related
I want to create a database for my football (soccer) manager/training program:
I want it to store players and managers in the database, they will all have their own username and passwords etc. they should also have a position in which will be listed as an attribute along with their name, password etc.
Each position has different attributes (If possible I would want these to be stored in a separate table i.e. a goalkeeper table, a defender table, a midfielder table and a striker table), for example, a defender would have jockeying, clearing, heading, strength.
I'm using the MySqlite3 in python when creating these databases. I can figure out how to write the code once I know what structure my database (ERD) should be in.
My image shows the relationship between the different members of the team, however, my teacher and I both can't seem to figure out how to structure it
I would only create two entities because they share common attributes. I will merge the manger with player to team member and merge all the positions to position entity. the team_member has a postion_id as a foreign key.
I'm designing the database schema for a CRM. It has the following tables: users, organizations, contacts, addresses, organization_types.
organizations might be a company, a non-profit or a individual.
users have a many to many relationship with organizations. The reason is because one company, for example, can have a salesman and a manager on the app with two different logins. On the other hand, there is the possibility that a salesman is doing sales for two different companies.
contact and addresses have a one to one relationship with organizations. My client only want a organization to have one of each of those.
I designed it in a way that a organization can also be a client, that would belong to another organization. That would mean that the organization table had a one to many relationship with itself.
That made sense to me because they seem to be the same entity. A client will also need a contacts and addresses table and it could also be a company, non-profit or individual.
The point to consider that another developer raised is that with time, it would be expensive to query the database to differentiate organizations that are our clients from the ones that are clients from our clients.
What is the best approach? Would it be better the make a client_organizations table and separate those two?
I will keep one table and create a column named parent_organization. Parent_organization will be nullable and store primary key of parent organization that child organizations belong to
I am designing a product that is mainly to be used by small organizations. The idea is for every member of the organization to have their own accounts (known as subaccounts). At the same time, there needs to be data that can be accessed by anyone with that organization. I am trying to decide between two courses of action.
Separate Table for Organizations
In this design, there would be a organizations table and a users table. The users would be connected to organizations via foreign key, and the shared data would use the foreign id of the organization.
User Conglomerate
Here an additional field in the users table would point to another row in the table (the parent) that represents the primary account for the organization and is linked to all the shared data.
Which approach would be superior in this situation?
Both approaches seem reasonable and workable, but I would lean towards having a separate table for organizations as ultimately the idea of an 'organization' is different to that of an 'user'. You may need to have different attributes for an organization than you would a user (e.g. you may need to have more than one 'superuser' for an organization at some stage), and so having this data in a separate table would make it (a) easier to code against (b) more extensible and future-proof (c) more efficient and normalized in storage.
Hi I'm drawing an ER Diagram using MySQL Workbench for my final year project. It's about a shipping company, where buyer & shipping agent are involved in a shipping process with my client.
So far the buyer and agent have same attributes. So I decided to keep both of their data in a table and differentiate them using an attribute (type in my case).
As you see in my picture I couldn't able to make a N:M relationship between shipping table and external table. It always give me 1:M relationship. When I try to do the relationships manually it creates a another relational table and make a 1:M relation with it.
Can anyone assist me with my problem? Further how efficient to have a relational table in my case.
The following screenshot is ERD for one application or one business. If you have used QuickBooks youll know that it has starting form called company so in one application we can create many companies and maintain company accounts
if I add a column companyid to all table then I can add many companies in one application
what is the good practice:
Adding company key and exacting company info with company key
Creating database for each company if thrs 100 companies 100 mysql databases
please advice !
Creating a separate database per company is almost assuredly not what you want to do (unless you have a really good reason to need to do so). Adding a company_id to your tables and ensuring that columns you query against are indexed with company_id along with whatever other column you will typically be querying would be wise.
You'll also need to ensure that your application is designed to correctly inadvertent (or purposeful) access from one company to another company's data.
EDIT - Now that I see your ERD has been added: I would add a "company" table containing a company_id, name, and whatever other data you like, then ensure your other tables have an additional company_id field as well.
Since you want to maintain all companies' businesses and accounts within the same application, then there is no need to create a database for each company, just add a Companies table, then add a foreign key company_id to the other database tables