CiviCRM has a complex Database structure which this chapter will examine in more depth. CiviCRM for various reasons has the Schema struture of its database written out in XML files store in `xml/templates/schema` These files are used to define all Core CiviCRM tables that are installed when CiviCRM is installed. CiviCRM maintains a number of tools and scripts such as `GenCode`, `bin/setup.sh`, `bin/regen.sh`, the purpose of these tools is to update any current database with the lastest information stored in the XML files, Re-create the installation .mysql files that live in `sql/civicrm*.mysql` which are not commited to the Git Repo but found in the Donwloadable package. Also They update the "DAO" Files which contain a reference of what files and what relationships are there in the Datbase.
## Tools
<Insertdocumentationonhowtousevarioustools>
Documentation on tools to interact with the CiviCRM Database still to come.
## Why a Entity Relationship Diagram may *not* be helpful
As some coders are visual learners, ER Diagrams maybe a waste of time for thsoe coders to understand the CivCRM Database modle and structure. Fundamentally CiviCRM's Schema diesgn is way too complex, with at least 150 tables and loads of Foriegn Key Constraints linking tables togeher any such graphic or design document that tries to map out the CiviCRM database design would most likely be more confusion than help, espeically for visual learners.
As some coders are visual learners, ER Diagrams maybe a waste of time for thsoe coders to understand the CivCRM Database modle and structure. Fundamentally CiviCRM's Schema diesgn is way too complex, with at least 150 tables and loads of Foriegn Key Constraints linking tables together any such graphic or design document that tries to map out the CiviCRM database design would most likely be more confusion than help, espeically for visual learners.
## Aleternate Methods to ERDs to explore CiviCRM's Database Design
Another method ofr viewing CiviCRM's Database model is to use one of various MySQL coding tools e.g. PHPMyAdmin or [MySql WOrkbench](https://www.mysql.com/products/workbench/). These tools allow coders to inspect the Table Structure more easily and look at all the constraints attached to tables very easily.
Another method ofr viewing CiviCRM's Database model is to use one of various MySQL coding tools e.g. PHPMyAdmin or [MySql Workbench](https://www.mysql.com/products/workbench/). These tools allow coders to inspect the Table Structure more easily and look at all the constraints attached to tables very easily.
## MySQL Workbench Workflow
...
...
@@ -25,6 +25,6 @@ When we look at CiviCRM Tables there are a few patterns that generally hold true
- Every table has a id column which is Auto Increment and therefore unique key for that table
- Columns which reference other tables generally speaking will be named in the format of `other table name` + `_id`. For example in `civicrm_country` there is `address_format_id` which indicates that is references `civicrm_address_format.id`
- Many-to-many relationships use "join tables" as intermediary tables. For example, a contact can have many activity records, and an activity can have many contact records. So the table `civicrm_activity_contact` is used as the glue because it has foreign keys to both.
- In some places CiviCRM defines schema using a construct called [pseudoconstants](framework/database/schema-definition/#table-field-pseudoconstant) which produces some slightly more complex logic
- In some places CiviCRM defines schema using a construct called [PseudoConstants](/framework/database/schema-definition#table-field-pseudoconstant) which produces some slightly more complex logic
- Lots of columns reference `civicrm_option_values` when they just need a simple (and user-configurable) list of options. For example, look at `civicrm_contribution` which has a column called `payment_instrument_id`. You'll notice there's no table called `civicrm_payment_instrument`. So in this case the `payment_instrument_id` column actually references the value column in `civicrm_option_values` (but only for records in `civicrm_option_values` with the appropriate `option_group_id`.) Here there is no foreign key, so referential integrity is managed at the application layer, not the database layer.
- Some tables use "dynamic foreign keys". For example, look at `civicrm_note` which has columns `entity_id` and `entity_table`. This is because a note can be attached to different entities (e.g. contact, contribution, etc). So two columns are used to indicate what the note references. Here again, the application layer is responsible for ensuring referential integrity, so you won't find any foreign keys.
