mirror of
https://github.com/directus/directus.git
synced 2026-04-03 03:00:39 -04:00
Docs updates
This commit is contained in:
@@ -1,3 +0,0 @@
|
||||
# Collections
|
||||
|
||||
> TK
|
||||
87
docs/concepts/database-mirroring.md
Normal file
87
docs/concepts/database-mirroring.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# Database Mirroring
|
||||
|
||||
> Instead of using a predefined "one-size-fits-all" data model to store your content, Directus "mirrors" your actual SQL database in real-time.
|
||||
|
||||
## Advantages
|
||||
|
||||
The principle is akin to a database client (eg: _phpMyAdmin_), but includes far mor advanced tools, and is safe and intutive enough for non-technical users. This approach has many unique advantages:
|
||||
|
||||
* A custom SQL database schema, tailored to your exact requirements
|
||||
* Significant performance improvements through optimizations and indexing
|
||||
* Complete transparency, portability, and security for your data
|
||||
* Direct database access and the full power of raw/complex SQL queries
|
||||
* Allows importing existing databases, unaltered and without any migrations
|
||||
|
||||
## Collections
|
||||
|
||||
A Collection is a grouping of similar Items. Each collection represents a table in your database. Directus automatically uses a built-in [title formatter](#) to display your database table names prettified, and you can use [translations](#) to completely rename them if needed.
|
||||
|
||||
::: tip Usage
|
||||
Collections can be organized in any way that is appropriate for your project. You can architect them platform-specific (eg: _pages_ of a website), or in a more platform-agnostic way (eg: raw _customers_ of your business). While there's no right or wrong way to structure your data-model, we recommend keeping your data as agnostic as possible so it is easier to repurpose in the future. In short, **learn to see your data as its own asset — not only through the lens of your immediate project needs**.
|
||||
:::
|
||||
|
||||
### Relevant Guides
|
||||
|
||||
* [Creating a Collection](#)
|
||||
* [Deleting a Collection](#)
|
||||
|
||||
## Fields
|
||||
|
||||
A Field is a specific type of value within a Collection. Each field represents a database column. Directus automatically uses a built-in [title formatter](#) to display your database column names prettified, and you can use [translations](#) to completely rename them if needed.
|
||||
|
||||
Each field also mirrors other characteristics from the column, including its `type`, `default`, `length`, `allow_null`, etc.
|
||||
|
||||
::: tip Usage
|
||||
You might have `title`, `body`, `author`, and `date_published` fields within an `articles` collection.
|
||||
:::
|
||||
|
||||
::: tip Aliases
|
||||
Not all fields in Directus map directly to an actual database column within their table. Some relational fields, like One-to-Many (O2M) and Many-to-Many (M2M), represent data that is stored in different tables. Other fields are only for presentation and don't save data at all, such as a divider. These are called "alias" fields.
|
||||
:::
|
||||
|
||||
::: tip Relational Fields
|
||||
Fields that reference other items (in the same collection or different) are called relational fields. Linking or connecting data relationally is an immensly powerful feature of relational databases and SQL queries.
|
||||
:::
|
||||
|
||||
### Relevant Guides
|
||||
|
||||
* [Creating a Standard Field](#)
|
||||
* [Creating a Presentation Field](#)
|
||||
* [Creating a Many-to-One Field](#)
|
||||
* [Creating a One-to-Many Field](#)
|
||||
* [Creating a Many-to-Many Field](#)
|
||||
* [Creating a Many-to-Any Field](#)
|
||||
* [Creating Translated Fields](#)
|
||||
* [Duplicating Fields](#)
|
||||
* [Adjusting Field Layout](#)
|
||||
* [Deleting Fields](#)
|
||||
|
||||
## Types
|
||||
|
||||
Directus has built-in database abstraction for managing all SQL database vendors. However, each of those vendors has a different list of supported column datatypes. To standardize all of these differences, Directus has a single superset of types that each map to the more specific vendor ones.
|
||||
|
||||
* String
|
||||
* Text
|
||||
* Boolean
|
||||
* Integer
|
||||
* Big Integer
|
||||
* Float
|
||||
* Decimal
|
||||
* Timestamp
|
||||
* DateTime
|
||||
* Date
|
||||
* Time
|
||||
* JSON
|
||||
* CSV
|
||||
* UUID
|
||||
|
||||
## Items
|
||||
|
||||
An Item is an object containing the field values within a Collection. Each item represents a database record. Similar to a "row" within a spreadsheet.
|
||||
|
||||
### Relevant Guides
|
||||
|
||||
* [Creating an Item](#)
|
||||
* [Archiving an Item](#)
|
||||
* [Reordering Items](#)
|
||||
* [Deleting an Item](#)
|
||||
@@ -1,3 +0,0 @@
|
||||
# Fields & Aliases
|
||||
|
||||
> TK
|
||||
@@ -1,3 +1,23 @@
|
||||
# Internationalization
|
||||
|
||||
> TK
|
||||
> Directus is maintained by people all over the world. Not only does Directus allow you to author and manage multilingual content, the App itself also supports multiple languages and locales.
|
||||
|
||||
## App Translations
|
||||
|
||||
Directus supports internationalization across its entire Admin App. Many languages are currently supported, with more are being added all the time. Help the communtiy by adding or refining your language through our [CrowdIn](https://locales.directus.io/) integration.
|
||||
|
||||
## Schema Translations
|
||||
|
||||
Directus uses [database mirroring](#) to dynamically pull in your schema's tables and columns, however this only covers one language. Therefore our platform supports schema translations for these names, allowing you to properly support different locales for your Collection and Field names.
|
||||
|
||||
::: tip Overriding Technical Names
|
||||
If your project requires more _technical_ table/column names (eg: `cust` or `f_name`), you can also use schema translations to override those defaults (eg: `Customers` or `First Name`) in the primary language.
|
||||
:::
|
||||
|
||||
## Content Translations
|
||||
|
||||
One of the most important features in Directus is the ability to author and manage multilingual content. While you can accomplish this by creating _standard_ fields in the parent collection for each language, it is more extensible to use our relational translation fields to dynamically manage content in as many languages as is required. Mixing standard and translated fields also allows language-agnostic data (such as dates or toggles) to remain within the parent collection.
|
||||
|
||||
::: tip Custom Interfaces
|
||||
For more advanced use-cases, such as connecting to a third-party translation service, you can read our extension guide on [creating a custom interface](#).
|
||||
:::
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
# Items
|
||||
|
||||
> TK
|
||||
3
docs/concepts/title-formatter.md
Normal file
3
docs/concepts/title-formatter.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# Title Formatter
|
||||
|
||||
> TK
|
||||
@@ -1,3 +0,0 @@
|
||||
# Types
|
||||
|
||||
> TK
|
||||
Reference in New Issue
Block a user