Я бы сказал, нет, это не так, как это должно быть сделано ...
Во-первых, DDB может хранить только 10 ГБ в одном разделе, а для 50-метровых строк они должны быть очень маленькими, чтобы уместиться.
Я бы порекомендовал vehicleID (UUID или VIN или STOCK #) в качестве хеш-ключа, а bookingID (UUID или Timestamp или ???) в качестве ключа сортировки.
Чтобы показать все заказы, вам нужно выполнить Query () для каждого идентификатора транспортного средства, но ваше приложение может выполнять параллельный запрос. Опционально, Scan () всегда просматривает каждый раздел.
Вы можете включить запись с hashkey = "VEHICLES", которая содержит список идентификаторов vechicleID, если у вас больше нет места для сохранения списка.
Кроме того, запись с vechicleID и sortley = "INFO", например, может использоваться для хранения сведений об автомобиле.
Но вы не предоставили достаточно информации для разработки DDB-решения.
С RDB вы должны знать, что вы планируете хранить.
С DDB вам не нужно точно знать, что вы планируете хранить, но вам нужно точно знать, каким образом эти данные должны быть доступны.