Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><em>Hi - not sure if I'm covering the exact points you want answered - but it's a start; ask for clarification if you want, and I'll update my answer accordingly.</em></p> <p>In terms of <strong>data management</strong> you might want to start thinking along <a href="http://en.wikipedia.org/wiki/Master_Data_Management" rel="nofollow">Master Data Management</a> lines. The first thought that leaps to mind is that you don't want inconsistent <a href="http://en.wikipedia.org/wiki/Reference_data" rel="nofollow">Reference Data</a>; this would suggest you use a single shared instance of the data - alternatively you could have multiple copies assuming the management and custodial processes around that data is crystal clear.</p> <p>In terms of <strong>integration</strong>, reuse depends on the Non-Functional Requirements of the various systems. A single shared service makes it easy to manage the data (in that there's only a single copy to worry about) but it means that it can become a bottle-neck; further more the "weakest link in the chain" rule applies - what's the impact if the shared service goes down?</p> <p><strong>Possible Solution Options</strong></p> <p>It's hard to know what to recommened without more info, but my thoughts are: </p> <ul> <li>Keep your three apps separate.</li> <li>Use a single shared service for shared data.</li> <li>Access to the shared data can be via a "service" - this would give you the most control and options.</li> <li>The shared service might exist as a single instance - or - you might have mutliple instances of the service deployed (but only one instance of the DB).</li> </ul> <p>The key point is tht you should be able to abstract out the shared service without affecting the other apps - specifcially, you shouldn't be thinking of making an uber app.</p> <p>One more thing - thinking of there being one "service" in a business sense doesn't preclude having multiple ways of technically exposing and consuming it. </p>
    singulars
    1. This table or related slice is empty.
    1. POWhen to combine multiple apps to simplify their data integration?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USAdrian K
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COHi Adrian, thank you for the thoughtful answer. You are correct in thinking that we wish to avoid inconsistent reference data. In the "one giant app" model this is ensured by having one module control all access to a data model, and all read/writes going through that module's API. In the distributed messaging model, this is ensured by making messages transactional and ensuring that local caches of the data are read-only. Any writes must be done through the "owner"/system of record app.
      singulars
      1. PO
      1. USrcampbell
    2. COSo in the "giant app" model, there is only one instance of the data, read & written by one module. In the distributed messaging model there is one master instance of the data, read & written by one "owner"/system of record app, but there are multiple read-only "caches" of that data in any other system that needs that data as a reference. You are 100% in saying that in the distributed model, the process for distributing, caching, and referencing of that data must be crystal clear. This is simplified (a little) by having the message broker (JMS/ActiveMQ) clearly displaying Producers & Consumers.
      singulars
      1. PO
      1. USrcampbell
    3. COYour answer seems to suggest the distributed app model, but instead of implementing it w/async messaging + local data caches, to implement it with sync services (RMI, web services, etc). This synchronous model has the benefit of avoiding the need for local data caches, but as you correctly point out it's more brittle. The purpose of async messaging was that when the system of record app goes down, it doesn't take down all of the consumers of that data as well since they have their own local cache. Local caches also solve the performance problem of large data models being sent over the wire.
      singulars
      1. PO
      1. USrcampbell
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload