Documentation

Setting up

Creating an account, connecting your database, and the schema and permission decisions that shape what Redbrix can do with it.

Redbrix account registration

To get started with Redbrix, you need to create an account, which you can do via the Redbrix registration page. You can create an account with an email address or you can log in with Google or GitHub.

Connecting your database

After logging in to your Redbrix dashboard, you will be prompted to connect your database. Redbrix currently supports MySQL and MariaDB databases only (though we will introduce support for PostgreSQL and MS SQL Server in the future).

Enter your connection details, specifically:

  • Host: The address of your database server (a hostname or IP address).
  • Port: The port number your database server is listening on (default for MySQL or MariaDB is 3306).
  • Database Name: The name of the specific database you want to connect to.
  • Username: Your database username.
  • Password: Your database password.

Once you have entered the required information, click the "Connect" button. Redbrix will attempt to establish a connection to your database. If the connection is successful, you will be taken to the main dashboard where you can start exploring your database and using Redbrix features.

Allowing external access

If you are hosting your database on a third-party provider, you may need to configure your database server to allow external connections and ensure that your firewall settings permit access from Redbrix's IP addresses. You should allow connections from the following IP addresses:

Address          Subnet Mask         Port
13.134.60.54     255.255.255.255     3306

or, if your provider allows CIDR notation, you can use:

13.134.60.54/32

Golden rules for database schema design

In order for Redbrix to provide the best possible experience, there are a few golden rules to keep in mind when designing your database schema:

Use a compatible MySQL or MariaDB version

Redbrix currently supports MySQL 5.7 and later, though 8.0 or later is recommended. For MariaDB, 10.3 is the minimum, though 12.0 or later is recommended.

Your mileage will vary with older versions. The basics should work fine but you should expect some rough edges and missing features.

Support for PostgreSQL and MS SQL Server are planned for the future, but there is no ETA at this time.

Use standard data types

Stick to standard MySQL data types for your columns. This ensures that Redbrix can properly interpret and display your data.

Redbrix interprets most MySQL data types and displays them in the application in the following formats:

  • varchar, char, int, smallint etc. are displayed in single-line text fields on edit forms.
  • date, timestamp fields are displayed in single-line text fields with an accompanying date picker.
  • blob fields are displayed as file upload inputs and their contents rendered accordingly on record details panels.
  • tinyint(1) fields are displayed as checkboxes.
  • text are displayed in a default format suitable for their data type.

Define clear relationships

You should define your foreign key relationships explicitly. You can check a table foreign key definitions by running the following SQL query:

SHOW CREATE TABLE your_table_name;

You will see the defined foreign keys towards the end of the output. If there are any missing, it is highly recommended that you create them using the following SQL command:

ALTER TABLE child_table_name
ADD CONSTRAINT fk_name FOREIGN KEY (child_column) REFERENCES parent_table(parent_column);

Or, if you're happy with a default constraint name, just

ALTER TABLE child_table_name
ADD FOREIGN KEY (child_column) REFERENCES parent_table(parent_column);

Properly defined relationships allow Redbrix to provide powerful features like automatic relationship mapping and intuitive data navigation.

Include primary keys

Ensure that each of your tables has a primary key defined. This allows Redbrix to uniquely identify records and provide features like editing and deleting records directly from the UI.

Avoid reserved keywords

Try to avoid using MySQL reserved keywords as table or column names, as this can lead to issues with query execution and may require additional escaping.

User permissions

Configuration permissions

Redbrix decides who sees the configuration tools (e.g. custom labels and title fields) from the database login's own permissions — there's nothing extra to configure inside Redbrix.

Admins

A login that can also change the database's structure. They additionally see the configuration tools.

You do not need a MySQL "root" or server-wide superuser for this, and you shouldn't use one for everyday work. Create an ordinary login and grant it structural rights on just the one database you use with Redbrix.

Regular users

A login that can read, and optionally add/edit/delete, data. They get the full data experience; the configuration tools are simply hidden.

Data permissions

The permissions assigned to the database user with which you connect to Redbrix will determine which functions are accessible within the application.

PermissionEffect in Redbrix
SELECTAllows the user to view records in a table. The table will be present in the table menu on the left-hand side of the application.
INSERTAllows the user to create new records in a table. The "New" button will be present on the table summary view function bar.
UPDATEAllows the user to edit existing records in a table. The "Edit" button will be present on the record details section.
DELETEAllows the user to delete records from a table. The "Delete" button will be present on the record details section.

You can assign these permissions to different users to control their access to various functions within the application. For example, if you want to create a user who can view and edit records but not delete them or create new ones, you can run the following statements:

CREATE USER 'your_user'@'%' IDENTIFIED BY 'your_password';
GRANT SELECT, UPDATE ON your_database.* TO 'your_user'@'%';

It is worth reading up on MySQL user management and permissions to understand fully the implications of these commands, particularly section 15.7.1 Account Management Statements in the MySQL documentation.