dbi is an abstraction that has been equated to a table in a relational database here. that's a loose analogy as there's no enforcement of any schema ootb, on a dbi. we have to exercise restraints in our application code to suit this need.
eg, if a domain logic tracks trees planted by people, we could restrict the application to crud tree/people/... objects in their respective dbis only.
aside: there's still no way to configure lmdb to reject writes of an object, deviant to a dbi, ie, one that doesn't conform to the schema attached to it. (eg in a manner, say firestore collections are tunable to the same effect)
doubt if our application logic is sophisticated enough, might we as well do away with dbis, and just use one, unnamed dbi?
iow, what particularly, are dbis good for?
dbi is an abstraction that has been equated to a table in a relational database here. that's a loose analogy as there's no enforcement of any schema ootb, on a dbi. we have to exercise restraints in our application code to suit this need.
eg, if a domain logic tracks trees planted by people, we could restrict the application to crud tree/people/... objects in their respective dbis only.
doubt if our application logic is sophisticated enough, might we as well do away with dbis, and just use one, unnamed dbi?