Consider a simple relational database with two tables:
item_index: item_id|item_name item_property: item_id|property_name
Each item has several properties, and I want to iterate over the collection of items in my database. For this I need to write a function with the following signature, where database denotes the type of database handles:
contents : database -> (item_name * (property_name list)) stream
This signature means that the function
contents returns a stream of pairs whose first member is the item name and the second member its list of properties.
There is two simple options to implement contents:
Concurrently require the stream of items and the stream of properties from the database, sorted appropriately, and aggregate the data by examining the two streams.
Require the stream of rows of an inner join, so that each item with its properties is represented by several rows, like
item_id|item_name|property_nameand aggregate the items from this data.
The second seems to put more overhead on the database, because of the join – probably packed as a view – while the first is significantly harder to program because of the concurrent access to the database.
Am I right thinking that implementing the
contents functions using concurrently requests amounts to poorly implement a
join operation in the application? This would imply that the second design is superior to the first as it leads to comparable time complexity and simpler code.