How to model entities in Google’s Datastore

Question

The Datastore used by Google’s App Engine, unlike a relational database engine, does not enforce schemas – instead of rows and columns, it stores entities with various properties. Nevertheless, should one still use a traditional database design?

For example, let’s say I have an application that tracks various rental vehicles. In a traditional database, I may have a Buses table, which tracks the length and number of seats for each bus in the fleet, and Trucks, which has a column for the load capacity and horsepower for each truck. Each bus and truck also has a color and license plate number. (If I want to normalize the database, I could break out these attributes in a Vehicle table).

In Google’s Datastore, I’d be tempted to simply store buses and trucks as Vehicle entities, as they share common properties, and add whatever properties are specific to the type of vehicle.

What are the advantages/disadvantages to using a traditional database model, where each Datastore entity represents a database table?

Is it more efficient to break large entities into smaller entities?

EDIT:

Also, any recommendations regarding which API to use: JDO, JPA or the Datastore low-level API?

Thanks!

Answer 1

You should not be thinking about tables at all. Think about entities. The documentation states that:

Datastore entities are schemaless: Two entities of the same kind are not obligated to have the same properties, or use the same value types for the same properties. The application is responsible for ensuring that entities conform to a schema when needed.

The best performance is usually achieved by de-normalizing data. So you are probably better off with two distinct entity types, Bus and Truck and ignoring the fact that they share some properties.