doc/modules/cassandra/pages/data_modeling/data_modeling_queries.adoc - cassandra - Git at Google

 = 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::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._
	= 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::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._