SQL Expressions for RADL Database

Click For Summary
SUMMARY

This discussion focuses on formulating SQL expressions for the RADL database. Key SQL queries discussed include retrieving personnel information for specific employees, filtering employees based on salary and location, and querying warehouse parts based on quantity. The participants emphasized the importance of using correct syntax, particularly regarding string quotations and the use of aggregate functions in SQL queries. The conversation also touched on the interpretation of "volume" in the context of SQL queries, clarifying that it may refer to the total amount of parts sold or the total price of orders.

PREREQUISITES
  • Understanding of SQL syntax and commands
  • Familiarity with PostgreSQL 9.6 or similar SQL environments
  • Knowledge of database schema concepts, specifically for the RADL database
  • Ability to interpret SQL query results and troubleshoot syntax errors
NEXT STEPS
  • Learn how to use PostgreSQL aggregate functions like SUM and GROUP BY
  • Explore SQL query optimization techniques to improve performance
  • Understand the differences between INNER JOIN and WHERE clauses in SQL
  • Investigate the structure and schema of the RADL database for better query formulation
USEFUL FOR

Database developers, SQL learners, and anyone involved in data analysis or management using the RADL database will benefit from this discussion.

  • #61
mathmari said:
Why do we need the DISTINCT only at the first query, without EXISTS ?

The query with EXISTS will find a name once if there exists at least 1 employee in Nurnberg that helped them.
Suppose there are 2 employees in Nurnberg that helped a particular customer.
Then the query with EXISTS will find the customer once, but the first query will find the customer twice. (Worried)
mathmari said:
So we create a table that includes that data that we want and then we print the column of this table as usual, right?
Yep. (Nod)

We may want to pick a VIEW that makes sense to have, such as one with all "interesting" columns from teilestamm and lager.
Then we can have a SELECT query that selects a specific column from it. 🤔
 
Physics news on Phys.org
  • #62
mathmari said:
The cost is the "gehalt" or are there also other costs besides the salary?

If we consider only the salary, do we write the following ?

CREATE VIEW KosteN AS
SELECT sum(p.gehalt)
FROM personal p;

SELECT *
FROM KosteN

I think it's indeed only the salary. (Nod)

We might give the column an understandable name.
We could do for instance

CREATE VIEW KosteN AS
SELECT sum(p.gehalt) AS 'Jährliche Personalkosten'
FROM personal p;

🤔

mathmari said:
For the annual costs per employee do we write ?

CREATE VIEW KosteNP AS
SELECT p.name, p.gehalt
FROM personal p
GROUP BY p.name, p.gehalt;

SELECT *
FROM KosteNPOr does it mean to create the two tables but when we write what the output shuld be we write it in one expression?

The GROUP BY clause should not do anything, should it?
Does anything change if we leave it out? (Wondering)

The only thing it could conceivably do, is merge rows together if they have the same data.
This could happen if there is more than 1 employee with the same name, and perhaps also the same salary.
Then it would be undesired to merge them together in any way! :eek:

Instead we should probably include the persnr in the view to make sure we treat employees with the same name as different. 🤔
 
  • #63
Klaas van Aarsen said:
I think it's indeed only the salary. (Nod)

We might give the column an understandable name.
We could do for instance

CREATE VIEW KosteN AS
SELECT sum(p.gehalt) AS 'Jährliche Personalkosten'
FROM personal p;

🤔

Since it is the total annual personnel costs do we have to multiply the sum of all p.gehalt by $12$ ? :unsure:
Klaas van Aarsen said:
The GROUP BY clause should not do anything, should it?
Does anything change if we leave it out? (Wondering)

The only thing it could conceivably do, is merge rows together if they have the same data.
This could happen if there is more than 1 employee with the same name, and perhaps also the same salary.
Then it would be undesired to merge them together in any way! :eek:

Instead we should probably include the persnr in the view to make sure we treat employees with the same name as different. 🤔

Do you mean that we have to write it either as above without GROUP BY, i.e.

CREATE VIEW KosteNP AS
SELECT p.name, p.gehalt
FROM personal p

SELECT *
FROM KosteNP or with GROUP BY but with persnr instead of name? :unsure:
 
  • #64
mathmari said:
Since it is the total annual personnel costs do we have to multiply the sum of all p.gehalt by $12$ ?

That depends on whether the gehalt is per month or per year.
Does it have a description anywhere? 🤔

mathmari said:
Do you mean that we have to write it either as above without GROUP BY, i.e.

or with GROUP BY but with persnr instead of name?

I meant without GROUP BY and with an persnr extra as the first column. 🤔
 
  • #65
Klaas van Aarsen said:
That depends on whether the gehalt is per month or per year.
Does it have a description anywhere? 🤔

In that column we have :
1638743001800.png


Can these be the salary per year? They seem to be the salary per month, don't they? :unsure:
Klaas van Aarsen said:
I meant without GROUP BY and with an persnr extra as the first column. 🤔

Do you mean nit as follows ?

CREATE VIEW KosteNP AS
SELECT persnr, p.name, p.gehalt
FROM personal p

SELECT *
FROM KosteNP :unsure:
 
  • #66
mathmari said:
Can these be the salary per year? They seem to be the salary per month, don't they?

Yep. Looks like a salary per month. So then we must multiply by 12. (Nod)
mathmari said:
Do you mean nit as follows ?

CREATE VIEW KosteNP AS
SELECT persnr, p.name, p.gehalt
FROM personal p

SELECT *
FROM KosteNP

Yep. (Nod)
 
  • #67
Klaas van Aarsen said:
Yep. Looks like a salary per month. So then we must multiply by 12. (Nod)

Yep. (Nod)

So should it be as follows? CREATE VIEW KosteN AS
SELECT sum(p.gehalt)*12 AS 'Jährliche Personalkosten'
FROM personal p;

SELECT *
FROM KosteN
CREATE VIEW KosteNP AS
SELECT persnr, p.name, p.gehalt*12 AS 'Jährliche Personalkosten Pro Mitarbeiter'
FROM personal p

SELECT *
FROM KosteNP :unsure:
 
  • #68
I think so yes. (Nod)
 

Similar threads

  • · Replies 9 ·
Replies
9
Views
1K
  • · Replies 35 ·
2
Replies
35
Views
2K
  • · Replies 8 ·
Replies
8
Views
1K
  • · Replies 7 ·
Replies
7
Views
1K
  • Sticky
  • · Replies 2 ·
Replies
2
Views
503K