Database Reference
In-Depth Information
| FU1 | Fuses | 3.42 |
| SLING | Sling | 4.49 |
| TNT1 | TNT (1 stick) | 2.50 |
| TNT2 | TNT (5 sticks) | 10.00 |
| FB | Bird seed | 10.00 |
| FC | Carrots | 2.50 |
| SAFE | Safe | 50.00 |
| DTNTR | Detonator | 13.00 |
| JP1000 | JetPack 1000 | 35.00 |
| JP2000 | JetPack 2000 | 55.00 |
+---------+----------------+------------+
Note
Presentation of Data SQL statements typically return raw, unformatted data. Data
formatting is a presentation issue, not a retrieval issue. Therefore, presentation (for
example, alignment and displaying the price values as currency amounts with the curren-
cy symbol and commas) is typically specified in the application that displays the data.
Actual raw retrieved data (without application-provided formatting) is rarely displayed
as is.
In addition to being able to specify desired columns (one or more, as seen pre-
viously),
SELECT
statements can also request all columns without having to list
them individually. This is done using the asterisk (
*
) wildcard character in lieu
of actual column names, as follows:
▼
Input
SELECT *
FROM products;
▼
Analysis
When a wildcard (
*
) is specified, all the columns in the table are returned. The
columns are in the order in which the columns appear in the table definition.
However, this cannot be relied on because changes to table schemas (adding
and removing columns, for example) could cause ordering changes.
Caution
Using Wildcards As a rule, you are better off not using the
*
wildcard unless you really
do need every column in the table. Even though use of wildcards might save you the
time and effort needed to list the desired columns explicitly, retrieving unnecessary
columns usually slows down the performance of your retrieval and your application.
