Database Reference
In-Depth Information
paying the bills for a project can be required to pay for something they don't
have access to, project owners have some special rights. Project owners can
always modify object ACLs, so they can add themselves back to the dataset
ACL if necessary.
Projects and AppEngine
Google AppEngine automatically creates a project for developers when they
sign up. Older AppEngine apps may not have a one-to-one mapping to
projects, but newer ones should always have an associated project.
AppEngine creates a special nonuser account created for every project,
called a
service account
. This can be particularly useful in accessing
BigQuery because it can automatically communicate with BigQuery without
the need to manage credentials. However, the service account must be
explicitly authorized to access BigQuery by adding it to the project
permissions. Chapter 8, “Putting It Together,” walks through the
authorization options from AppEngine in more detail.
BigQuery Data
Data in BigQuery follows a strict hierarchy: Rows of raw data that follow a
schema are stored in a table; tables are grouped into datasets; and datasets
belong to projects. Projects belong to whoever is paying the bills for the data
storage. This hierarchy is visible in the URL paths used in the BigQuery
REST API, as well as in the names of objects. The REST paths are described
in much more detail in the next chapter; this section gives a rundown on
how BigQuery objects are named.
Naming in BigQuery
There are two ways to refer to objects in BigQuery: as
identifiers
and as
references
. In a query, the identifier of the object is used. Take, for example,
this query:
SELECT message FROM [bigquery-e2e:logs.latest]
The field
message
is selected from table
latest
in dataset
logs
in project
bigquery-e2e
. This syntax is used in queries because the table identifiers
need to be compact and easy to type by humans. Identifiers are usually
referred to as “IDs” and can be relative or fully-qualified. A relative ID
