This question is regarding design options / pros & cons to consider when building an Ethereum DAPP.
If we were to take the example of building a KYC DAPP on ethereum - then, before adding (or not) a customer into the system, one needs to make sure that the customer is not already present in the KYC system. This could imply doing a search for customer identity before deciding whether to add the customer or not. There could be (at least) 2 broad ways of designing this -
a.) 1.Create a customer db - outside of the BlockChain - say a Mongo db or any other such appropriate option, hosting say, SSN / DL or such information to identify the customer uniquely, 2. confirm whether the customer exists in the system or not, 3. and then decide on adding/rejecting the customer / and 4. update BlockChain with the outcome of the exercise. So, the BlockChain is used as a repository of KYC data, but not used for Search like operations in this context.
b.) Have the customer information in the Ethereum BlockChain - both as a repository as well as for searching purposes. So, no other DB needed.
Option a would then imply having support for Distributed Transaction semantics, to make sure that the customer DB and BlockChain are either both updated or neither is.
Is it appropriate to use Eth. Blockchain as a Db to search like one does in Transactional Databases? Any pointers / opinion on pros/cons on the approaches above in the context of Ethereum BC are welcome.