I'm having trouble assembling the tables where I will search powers of attorney for several companies.
where:
Prosecutor will belong to several companies (X, Y, Z)
Companies have several branches (EU, Brazil, USA, etc ...)
The branches will have multiple units. (Energy, Oil, etc. ..)
The attorney will also have various powers (signing, trading, etc.).
The intention is that in the end, I can find an attorney who is able, for example, to sign the contract by energy unit of Brazil subsidiary company X.
Can someone help me with the and hasMany tables and with logic? Thanks!
Just create those tables as usual and then you will have to create relational tables.
prosecutors_to_companies (they may belong to several companies, right?)
prosecutor_id | company_id
1 2
1 4
2 6
Then create the next relational table:
companies_to_branches
company_id | branch_id
1 4
1 3
Then with help of JOINs retrieve the needed data.
This example may help you - http://www.sitepoint.com/understanding-sql-joins-mysql-database/
Related
I have tried reading Laravel documentation and other, similar posts about Laravel database relationships, but I cannot seem to wrap my head around it and how it applies to my use case.
I run a web site for high school athletics. I have 5 tables:
schools - Standalone list of all schools in the state.
sports - Standalone list of all sports sanctioned by the state.
seasons - Standalone list of seasons (one season per school year).
leagues - Standalone list of leagues/conferences.
league_divisions - List of divisions for leagues that have multiple divisions (think "Big Ten East" and "Big Ten West") where leagues = parent and league_divisions = child. Note: A league would only have child records in this table if it had divisions; Most high school athletic conferences/leagues do not have divisions, and therefore would not have a corresponding record in this table.
Every so often, schools change leagues, or may change which division of a league they are a part of. (think "school_leagues")
Similarly, a school may begin to field a new sport (School A never had girls soccer in the past, but now they have a team) or discontinue an old one (School B no longer has a football team). (think "school_sports")
Also, while the state may sanction 25 sports, a league itself may only sanction 10. My web site is for the League itself, so I would also need a way to list which sports a league sanctions. (think "league_sports")
In my old (pre-Laravel) data model, I just had a "school_leagues" table that stored what league (and division, if applicable) a school belonged to for a particular range of seasons (via start_season_id, end_season_id). Additionally, in the HTML, I simply hard-coded a static list of which sports a league sanctioned and which teams should appear in that sport's standings.
However, as I rebuild my data model, I'm thinking I may need a more complicated relationship table(s) that joins Schools, Sports, Seasons, Leagues, and (optional) League Divisions.
Additionally, instead of using start_season_id and end_season_id (where end_season_id IS NULL if the relationship is still valid), will Laravel conventions force me to have 1 record per school per sport per season per league/division? (This would directly join to season_id as opposed to having start/end_season_id columns)
Any help is appreciated!
I could simply go with 3 relationship tables: school_leagues, school_sports, and league_sports, and all would join to season by either season_id (1 record per year) or start/end_season_id.
OR I would have 1 master table that joins school_id, sport_id, season_id, league_id, and (optional) league_division_id. It would have 1 record per instance, so each year I'd generate a new group of records.
Laravel / Eloquent has a serviceable scheme for many-to-many relationships. https://laravel.com/docs/5.8/eloquent-relationships#many-to-many In your app you have several many-to-many relationships, for example schools >----< sports . Eloquent uses a join table (called something like schools_sports to represent this in the DBMS.
To handle the complexity here, you probably need a new entity in your database design. Let's call it teamseason. There's one of these for each school, sport, season, and league. It relates to one each of those entities, and it might have attributes like won, lost, captain, and other data points relating to the team and season.
For example,
Stuyvesant High School (school) had a
Precision Air Rifle (sport) team
In Spring 2018 (season) playing in the
New York City Geeksports League (league)
They won 10 and lost 3 matches, and the captain was Deadeye Robinson (attributes)
You'll need another of these entities for the Spring 2019 team.
A table for it might look like this:
teamseason_id PK
school_id FK to school.school_id
sport_id FK to sport.sport_id
season_id FK to season.season_id
league_id FK to league.league_id
won int
lost int
captain varchar(128)
I'd throw in division, but I don't understand the structure.
This looks like it might be some kind of four-way join table, but it's more than that. I added the won/lost/captain attributes to emphasize that it's its own entity.
The trick is to identify an entity for each real thing in the world of your app, then identify the relationships between entities. (It takes practice to do this well.)
Im new to programming and databases in general. I've read PHP.MYSQL for DUmmies 4th edition thus far, and am trying to create a database of my own which stores the Menus/Inventories of shops. I am currently using XAMPP/MYSQL.
Sample tables of my database are as follows:
SHOPINFO
Shopname Outlet Category Subcategory Item
PizzaHut Main Drinks Carbonated Cola
PizzaHut Main Drinks Non-carbonated Orange Juice
BurgerKing Central London Burgers Beef Whopper
BurgerKing South London Burgers Beef Whopper Jr.
BurgerKing South London Drinks Carbonated Cola
I am currently wondering if i should split the above table up into :
SHOPINFO
Shopname Outlet Category Subcategory Item
PizzaHut Main 1 1 1
PizzaHut Main 1 2 3
BurgerKing Central London 1 5 4
BurgerKing South London 1 5 7
BurgerKing South London 3 3 2
Where the Categories,Subcategories and Items are all split up into different tables where they are identified by their CategoryID,SubCategoryID and ItemID respectively.
The 2 Major Questions i have regarding this decision are:
1.Would it really be beneficial to split the table up? I am asking this as would it not be far easier to query the first table rather than the second table? E.g i could simply do something like
$query="SELECT * FROM SHOPINFO WHERE Shopname='BurgerKing' AND
Outlet='South London' AND Category='Drinks' AND
Subcategory='Carbonated'";
$result=mysqli_query($cxn,$query) or die("Error");
while($row=mysqli_fetch_assoc)
{
extract($row);
echo "$Item";
}
instead of the query that would have to be done if the table was split(Which i have no idea how to do, and which makes my mind hurt).
2.If i were to split the table up, i'm guessing that i would have to create separate tables for each shop for the Category,SubCategory and Item, using the Shopname & Outlet as primary keys, which i would then link to the SHOPINFO table with foreign keys, probably using ON DELETE CASCADE & ON UPDATE CASCADE. The main question is, exactly what benefits would doing this bring about, apart from making the querying more complicated?
PS: My concerns are regarding future scalability.(E.g Adding countries,Cities,States to Outlets in the future)
Advice,Help,Opinions,Insults and Flaming are appreciated.
Thanks!
I think that your entire structure is wrong. You need to split everything up into separate tables, starting with a table of companies - Pizza Hut and Burger King are the only entries which you have shown. Then you need a table of branches which would contain a foreign key to the company along with atomic data about each branch, like its branch number, address etc. Then you need a category table, whose data seems to be either drinks or burgers, followed by a subcategory table (carbonated, non-carbonated, beef, chicken, etc) which contains a foreign key to the category. The you need a products table (cola, orange juice, whopper, whopper jnr) which has a foreign key to the subcategory. Finally, there would be a branch-products join table which has two fields (branch number, product number).
This structure, whilst seemingly cumbersome, is the most flexible and allows one to write all kinds of queries with little difficulty - total sales by company, total sales by branch, etc. This may not be clear when you are defining your database but you will appreciate this in the future when you are asked for some data aggregation which you had not foreseen.
Keeping everything in one table is a very bad idea: let's say that Burger King is taken over by The Grill Master (an invented name): this way you only have to change one record to reflect the change, whereas when using one huge table, you would have to update many records.
The 'huge one table' approach comes from people who use Excel as their database manager and basically have no experience of anything more complicated. The professional answer is to use a relational database with everything split up into tables.
I apologise if the above seems condescending; I am a doctoral candidate who is looking at the use of Excel within companies which use relational databases, so I am somewhat biased in my views.
I'm coding a Classified Ads web application. The application has several types of Ads:
General ads(electronics, toys, pets, books...)
Real estate (houses, apartments, terrains...)
Vehicles (motocycles, cars, vans, trucks...)
Each type has several common fields (id, title, description) and also some that are exclusive to its kind:
General Ads (no exclusive fields)
Real estate (area, type-of-property...)
Vehicles (type-of-vehicle, cubic-capacity, kilometers...)
What is the most recommended approach to this situation?
A table that contains all fields and leave empty the fields that
don't apply to the current recordset.
A main table with the fields common to all Ads, and an additional table for each type of Ad that has exclusive fields.
One table for each type of Ad.
Other
I would build a solution depending on various criteria :
If you believe the table will be large in the future (a lot of ads to be published), you may want to minimize the number of JOINs for better performance => option 1. "one table with empty fields when not relevant to ad type"
Previous comment applies especially if your data storage cost is low.
If you have to query the data against certain field values (e.g. house size, car kilometers), you might avoid the solution described by phpalix (ad_type | property | value) or Andy Gee since your SQL syntax will be a nightmare, and prefer to have all your data in the same table (again).
If there are A LOT of custom fields per ad type, you might prefer to separate each ad type in their own table, for easier maintenance and data storage optimization. Then you can either JOIN or UNION to query your ads lists.
I'll add to my answer if i think of something else.
You can normalise (a table for the abstract concept and a table the the specialised one) or denormalise (a table with all the fields)
As always, the choice must be done according to the cost of each solution, reprensented by the speed of the queries (normalised model means more joins (buffer/cpu) whereas denormalised more disk reads usually because the columns are sometimes retrieved when it is not necessary) or the storage required in both cases.
All solutions are acceptable and a matter of preference, performance, complexity and design needs. The terms for what you are discussing are Table-Per-Type, Table-Per-Class and Table-Per-Hierarchy. If you google on these you are guaranteed to get a ton of Entity Framework results, but the underlying design considerations are much the same.
For flexibility I would have all the field in a separate table then allow the assigning of each field to each ad type. This would also allow you to add and remove fields easily at a later date.
Each field may have different types of data so this information should also be in a separate table.
Something like this (not very clear sorry)
Table: fields
field_id, field_type, field_name
1 1 title
2 1 price
3 2 size
4 3 description
5 1 square meters
Table: field_types
field_type_id, type
1, textbox
2, select_box
3, text_area
Table: field_data
field_data_id, ad_id, field_id, field_type_id, field_data
1 1 1 1 Cool t-shirt
2 1 2 1 5.99
3 1 3 2 L,XL,XXL,XXXL
4 1 4 3 Some description
5 2 1 1 Nice house
6 2 2 1 250000
7 2 4 3 Some description
8 2 5 1 1024sq/m
Table: ad_types
ad_type_id, ad_type_name, fields
1 general 1,2,3,4
2 real_estate 1,2,4,5
Well, store the values in columns and not in rows, so create a table and have 3 columns:
ad_type, property, value
define your properties for each type of ad and query the ad type for its fields.
Hope that helps
I'm developing a site like "yellow pages" with more complex DB than I had ever experienced before.
For example:
This DB has 3 tables:
1. organisations – with some general information.
2. services - with list of all services that can be provided.
3. relation table.
Organisations table structure:
id name city phone etc.
1 CompanyName Farewell 987-65-43
Services table structure:
id ServiceType
1 purchase
-----
2 sale
-----
3 exchange
etc..
you get the point
And relation table structure:
id OrganisationID ServId
1 1 2
----
2 1 3
----
3 1 6
----
4 2 3
In website output I need a list of all organisations with all the services they provide.
I can't fully understand (even after reading Linking Models Together section in the CookBook) how I should combine all this tables using Cake's syntax and conventions.
I'll be glad if anyone can provide me a Cake's model/model's (how many I need?) example with ability to retrieve this data.
I can't comment on your question so I'll ask here...
Organisations can have many services and services can have many organisations? Is it HABTM relationship? (Just checking...)
If it is, I'll then edit this and try to give you the answer. :)
EDIT:
TABLES
1. table: organisations
2. table: services
3. table: organisations_services (sorted alphabetically)
1. table: id, name, city...
2. table: id, service_type
3. table: id, organisation_id, service_id (singular, sorted alphabetically)
MODELS
Organisation - inside your organisation model you must have:
var $hasAndBelongsToMany = array('Service');
Service - inside your service model you must have:
var $hasAndBelongsToMany = array('Organisation');
And that's all. Everything else leave to the beautiful Cake. :) If you don't understand something, feel free to ask and here you can get more information.
I'm trying to build a searchable database of acronyms and their definitions that are specific to a certain industry. It has been years since I've done any real programming, so I'm a little behind the learning curve.
I'm writing the code in PHP, and I'm using MySQL as the database. If this can be done easier in Postgres, I'm not opposed to switching DBs, but I can't use Oracle or any other commercial system.
So here's the question:
I'd like to set it up so that each acronym can: (1) apply to 1, multiple, or no specific organizations; (2) have 1 or more associated definitions.
The complexity--at least in my mind :D--comes in that it is conceivable that some organizations might have a single acronym with multiple definitions that all relate to that one organization. At the same time, the acronym may have 1 or more definitions that relate to OTHER organizations as well.
Am I over complicating this?
I'd like to better understand how to setup the table structure and relationships in MySQL--what fields and relationships would be in each table.
A SQL statement would be helpful if anyone feels so inclined, but I'm hoping to at least get a solid grasp on the database schema so I can get the tables created and some sample data imported.
Many, many thanks to all...
Dan
The solution should contain 4 tables: Acronyms, Definitions, Organizations, and AcronymOrganization.
Acronym(id, acronym, definition_id)
Definitions(id, definition)
Organizations(id, organization)
AcronymOrganization(id, acronym_id, organization_id)
If I understand your question, you can use three separate tables. First, have the table of acronyms/definitions, then have a table of Organizations. Finally, have an AcronymOrganization table, that just references a key from the acronym table, and a key from the organization table. This way, you can have as many acronyms for an organization as you please.
After you set up the database, you need to use a couple inner joins to join the three tables, collecting only the acronyms for the appropriate organization ID.
I'd just create an acronym table, an organization table, and a definition table. Put two foreign keys in the definition table: one for the entry in the acronym table, and the other for the entry in the organization table.
If you want to have a n:m relationship between tableA and tableB, then you need a third table.
table A. Fields : ID,name
table B. Fields : ID,name
table AB. Fields : A,B (A is a reference to A.ID, B is a reference to B.ID)
[TABLEA]1-----*[TABLE_AB]*-----1[TABLEB]
Example
Contents of table a:
ID Name
1 John
2 Mary
3 Piet
Contents of Table b:
ID Name
1 Microsoft
2 Google
3 Philips
Contents of Table ab:
ID Name
1 2
1 3
2 2
3 1
3 3
Then select everything like this:
select a.name,b.name
from a,b,ab
where a.id=ab.a and b.id=ab.b
Result:
a.name b.name
John Google
John Philips
Mary Google
Piet Microsoft
Piet Philips