I'm about to extend a system containing two separate systems. Or domains, if we see the system as a domain level.
One domain is used internally. The other is public, which means it is more exposed to whatever can happen "out there". Services of some kind (few options apply) perform operations between the two separate systems. The public and internal system have separated database storages, and are not related to each other. Let's call the domains client and store.
I'm into a new application that will have lots of more user-specific information at the client domain. The design may be comparable to a 'private database' that has a facebook-account-link as a key. This compares to a database that held user actions, but had no user specific data (such as address, date of birth, email and so on), just a key to the Facebook-server. On the other side, the STORE database (compared to Facebook-server in this case) doesn't know anything about the user actions.
Approximately 85-90% of the queries will be within their own domain (client if client, store if store). Though, there are some situations where the client need to get data from the STORE database and the STORE needs to create/handle users in the CLIENT database.
Questions out from my head
- Is this a good way to go?
- Pros/cons? Orphans? Database Performance? Problematic .NET coding?
- Principles of the choice for the boundaries of data?
.. and other things you may know or think of
An example of structure
- userid (PK)
- emailAddress -> Wallet (another table)
- walletid (PK)
- createddate -> BankAccount (another table, not typed)
- storeUserId (unique, non-inc) <-- corresponds to dbStore.User, no restraint
- actionid (PK)
- installationid (PK)
We won't collect bank-account information, it just to give a picture of the data structure and its importance in keeping it in separate systems. I hope this Q is comprehensible enough.