UsurpingBean said:
- actually it was you about your friend. How does he figure? in both hsc ipt textbooks this is clearly disputed for instance LinQ and if you take Heinemann it is clear SQL is a more advanced query language than is required in flat file databases I quoted this before but it was ignored
- Heinemann HSC IPT (page59)
The logic is simple. There needs to be a way to get stuff out of a flat-file DB lol.
As for SQL, well you need to understand databases here. SQL is basically a set of specifications. They can be followed entirely, mostly or used for something else.
For example, MySQL, MSSQL and Oracle are all SQL-compatible RDBMSes, however they each use slightly different syntax for certain things, and sql queries are not compatible between them.
There are a lot of query languages, which can loosely be defined as SQL. Just like a router can be loosely defined as a "dsl modem".
UsurpingBean said:
OK sure lets say that SQL is infact the most efficient query language
It's not something we say, it's fact. Ask anyone whom does databases. There's not even any alternative. SQL is IT.
UsurpingBean said:
Not actually sure what you mean here. A report can be activated as a simple sql query can and is dynamic to changing data in tables.
In my understanding, a report is sort of like a formatted output of a query. For example, it could be a .doc or even a .pdf.
UsurpingBean said:
I'll take this opportunity to say, that just because it's an option, doesn't mean it's possible. BoS often puts in fake options of things which don't exist, or aren't even possible.
UsurpingBean said:
It does not mention that it uses SQLs to find the total but we both know it has to and it states that it does find the totals so how it does it is irrelevent.
I would agree that there are two ways of looking at that. One is yours, but the way I see it, is that the option implies that it's in fact the report - and nothing else - which does the producing of results. And this isn't possible.
UsurpingBean said:
Now that is saying that an SQL is to be run on each age group so for instance on the age group 12-15 with its total. Therefore lets assume there are 5 age groups. The answer b is saying that you must run an SQL for every age group, meaning 5 SQls must be run and totals are then perhaps added together manually.
I wouldn't say that's the best way of doing it. There are moderate sql instructions which can do the task in one query. However I ask you to consider the following:
1. These complex queries are totally outside the scope of the course
2. They may not be possible, because this is in fact a flat-file database and it does not implement SQL in full
3. Although it's not the most efficient way, from my perspective, it's the only way of doing it. Just because it has to be repeated a few times, does not automatically disqualify it as an option, if it's the only possible or logical option.
UsurpingBean said:
So what? If you read the answer b it clearly mentions multiple SQLs and does not suggest a single SQL can be used for all totals combined whereas a single report, by simply designing it with all the SQLs in basic design view, or perhaps some other method the BOS decided on can produce these totals in a single document. This document can be used every week and is as mentioned earlier able to dynamically change to report new results if the data was to change
Pretty much what we have stated. So what? The fact that it's not possible - that's what. The easiest option isn't the correct option if it's impossible to achieve.
UsurpingBean said:
A report is the formatted output of an SQL
Yes, the output from an SQL queries is generally referred to as a result set.
UsurpingBean said:
- what are you basing that on, how do you define run? A report most certainly can be run to display the results from the SQL queries that are incorporated in it as for the instructions or pulling figures out of arses you will need to clarify that for me
What can be ran? Very single. Executable programs can be ran. Instructions can be ran in/against vertain environments.
Something which is a bunch of text and figures with formatting - which is what a report is - is neither an instruction set, nor an executable program.
UsurpingBean said:
You appear to have accidently increased the text size coloured it red and underlined it because I fail to see how this has relevance to the answer of the question.
Yes....accidentally >_>
The relevance is this, I am outlining why a report cannot be "ran" and why a report cannot "produce" anything, which is relevant to option A of the question.
UsurpingBean said:
Of course a report is constructed using queries...how could it not be? I think more focus needs to be put on the comparison of the answers a and b (not d as you once suggested it could be that is clearly an incorrect answer). A problem that appears to be confusing you is my addressing some peoples belief that SQLs are the only method of data extraction and whilst you are free to comment on that stick to arguing for your answer which is what we are here for and argue as to why my logic above about specific wording of the answers is incorrect
Your statement of "a report is constructed using queries" is ambigous and incorrect. It is not constructed using queries, but it is constructed (although a better word would be generated),
using the
results obtained from
running an SQL query.
I will take this opportunity to state, that a report cannot in any way connect with and extract any information out of the database. It is possible to extract information out of the database using other means (even looking at it) to create the report, yes. But a report itself consists
only and only of:
- Control characters for formatting
- Binary data representing values
It
cannot contain:
- Executable Code
- Instructions
UsurpingBean said:
A) suggests placing those multiple SQLs into a single report thus meaning that instead of activating 5 separate SQLs one must only activate a single report
This logic is false and incorrect. SQLs cannot be "placed" into a report. SQLs are instructions, if you place them in a report, it would look something like this:
Ages of Students
14 Year Olds
Boys: SELECT SUM(id) FROM students WHERE gender='boy' AND age='14';
Girls: SELECT SUM(id) FROM students WHERE gender='girl' AND age='14';
Furthermore, the option
doesn't even mention SQL.
So I cannot at all agree with your logic there.