Projects vs Domains vs Tables

Table of Contents

  1. Projects, Domains and Tables

Projects, Domains and Tables

Projects are a collection of Domains, Domains are a collection of Tables, however simple this seems, it is not so… Domains are also inter-related by tables, a good example of this is the following schematic.

Projects, Domains and Tables shown

Projects are separate databases structures in the underlying database system (monsterDB) and although the User Interface can open any number of projects, it can only talk to one at a time. Projects could also be on different installations of Custodian on different machines, in this case a different installation will be required to support this model. All the data in one project is only accessible (or visible) via that project, it is physically separated on the same machine.

A table is a list of interrelated objects such as products, countries, suppliers etc, but these tables need t be able to relate to other tables (as in a foreign key relationship in relational modeling) and in most cases these relationships need to cross the boundaries of a domain. A domain is a logical (and in fact physical) set of tables that describe a certain part of a business such as suppliers, products, customers etc and store information that would be matchable within that domain (ie suppliers could be considered to be matchable to locations and in fact this discovery could be useful!)

As such in EntityStream we model a domain, we call it a domain and we store all tables together in this domain but allow cross domain relationships into other domains enabling an ownership of data within a domain but not creating a silo of information.