mirror of https://github.com/apache/cassandra
61 lines
3.1 KiB
Plaintext
61 lines
3.1 KiB
Plaintext
= Defining application queries
|
|
|
|
Let's try the query-first approach to start designing the data model for
|
|
a hotel application. The user interface design for the application is
|
|
often a great artifact to use to begin identifying queries. Let's assume
|
|
that you've talked with the project stakeholders and your UX designers
|
|
have produced user interface designs or wireframes for the key use
|
|
cases. You'll likely have a list of shopping queries like the following:
|
|
|
|
* Q1. Find hotels near a given point of interest.
|
|
* Q2. Find information about a given hotel, such as its name and
|
|
location.
|
|
* Q3. Find points of interest near a given hotel.
|
|
* Q4. Find an available room in a given date range.
|
|
* Q5. Find the rate and amenities for a room.
|
|
|
|
It is often helpful to be able to refer to queries by a shorthand number
|
|
rather that explaining them in full. The queries listed here are
|
|
numbered Q1, Q2, and so on, which is how they are referenced in diagrams
|
|
throughout the example.
|
|
|
|
Now if the application is to be a success, you'll certainly want
|
|
customers to be able to book reservations at hotels. This includes steps
|
|
such as selecting an available room and entering their guest
|
|
information. So clearly you will also need some queries that address the
|
|
reservation and guest entities from the conceptual data model. Even
|
|
here, however, you'll want to think not only from the customer
|
|
perspective in terms of how the data is written, but also in terms of
|
|
how the data will be queried by downstream use cases.
|
|
|
|
You natural tendency as might be to focus first on designing the tables
|
|
to store reservation and guest records, and only then start thinking
|
|
about the queries that would access them. You may have felt a similar
|
|
tension already when discussing the shopping queries before, thinking
|
|
“but where did the hotel and point of interest data come from?” Don't
|
|
worry, you will see soon enough. Here are some queries that describe how
|
|
users will access reservations:
|
|
|
|
* Q6. Lookup a reservation by confirmation number.
|
|
* Q7. Lookup a reservation by hotel, date, and guest name.
|
|
* Q8. Lookup all reservations by guest name.
|
|
* Q9. View guest details.
|
|
|
|
All of the queries are shown in the context of the workflow of the
|
|
application in the figure below. Each box on the diagram represents a
|
|
step in the application workflow, with arrows indicating the flows
|
|
between steps and the associated query. If you've modeled the
|
|
application well, each step of the workflow accomplishes a task that
|
|
“unlocks” subsequent steps. For example, the “View hotels near POI” task
|
|
helps the application learn about several hotels, including their unique
|
|
keys. The key for a selected hotel may be used as part of Q2, in order
|
|
to obtain detailed description of the hotel. The act of booking a room
|
|
creates a reservation record that may be accessed by the guest and hotel
|
|
staff at a later time through various additional queries.
|
|
|
|
image::images/data_modeling_hotel_queries.png[image]
|
|
|
|
_Material adapted from Cassandra, The Definitive Guide. Published by
|
|
O'Reilly Media, Inc. Copyright © 2020 Jeff Carpenter, Eben Hewitt. All
|
|
rights reserved. Used with permission._
|