SQL Expressions for RADL Database

Click For Summary

Discussion Overview

The discussion revolves around formulating SQL expressions for a RADL database, addressing various queries related to personnel, customers, orders, and warehouse parts. Participants explore the syntax and structure of SQL commands, while also seeking clarification on the database schema and functionality.

Discussion Character

  • Technical explanation
  • Debate/contested
  • Exploratory

Main Points Raised

  • Some participants propose SQL expressions for retrieving personnel information, customer data, and warehouse parts based on specific criteria.
  • There is a suggestion that quotes are necessary around string values in SQL commands, with examples provided.
  • Participants express uncertainty about the RADL database and its schema, questioning the existence of certain columns like "Kto."
  • Some participants suggest using a SQL compiler or database program to test the queries directly.
  • There is a discussion about the correct use of quotes in SQL syntax, with a preference for single quotes over double quotes for string literals.
  • Participants explore how to check for the existence of orders for customers and discuss the need for queries involving multiple tables.
  • There is a debate about the correct formulation of SQL expressions for specific queries, particularly regarding minimum values and conditions.
  • Some participants question the results of their queries, particularly concerning the expected output based on the conditions set in the SQL commands.

Areas of Agreement / Disagreement

Participants generally agree on the need for correct SQL syntax, including the use of quotes. However, there are multiple competing views regarding the correct formulation of specific SQL queries, and the discussion remains unresolved on several points, particularly concerning the expected outcomes of certain commands.

Contextual Notes

Limitations include uncertainty about the RADL database schema and the definitions of certain columns. There are unresolved questions about the correct SQL syntax and the expected results of the queries.

  • #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
3K
  • · Replies 8 ·
Replies
8
Views
1K
  • · Replies 7 ·
Replies
7
Views
1K
  • Sticky
  • · Replies 2 ·
Replies
2
Views
504K