Do you have an existing database model you would like to work with in Vertabelo? If so, you've come to the right place! In this article, you learn how to export a DDL file from MySQL Workbench and import it into our modeling tool. We also take a look at other ways to import an existing database schema into Vertabelo and organize existing tables. How to Export a DDL File From MySQL Workbench First, let's see how to export an existing database.
Learn about Model Explorer, a new feature in Vertabelo Database Modeler. Have you noticed that a new feature has been introduced to Vertabelo Database Designer? In this article, we take a deep dive into Model Explorer, an innovative way of managing your database models. In short, Model Explorer allows for a comprehensive overview of the model and bulk editing of multiple elements at once. At this time, the functionality is available only for the physical model, but in the future, it will also be implemented in the logical model.
Learn how to design a database from scratch for a library system. Try your hand at database design! Are you interested in a job as a database designer? Imagine that we are planning to develop a software application to manage a local library. You need a library database model! The database designer needs to gather business requirements from the client and decide what data needs to be stored and how.
Have you already noticed the Vertabelo Database Modeler has a new look now? The entire graphic design changed significantly at the end of January. Over the past few years, we have been observing how the previous interface worked and paying great attention to the experience of our users. Equipped with the knowledge we have gathered, we developed a completely new graphic design of our ERD tool and implemented several ergonomic improvements to individual functional elements.
In dictionary tables, you often encounter the following column pattern: An artificial primary key (e.g., id of type integer). An artificial alternative key (e.g., code of type char(x)). Real data (e.g., name of type varchar(y)). This pattern can also be found in many other systems (such as Jira or Recurly). In our example, both tables have a numeric column id, which is a primary key, a code of type char, and real data, such as name or description field.
How do you solve the problem of storing temporary data in a database? Imagine a situation when you fill in a multi-page form. What happens if you pause and come back in a few days to finish it? It would be great if the data is saved, and if you can take it up right where you left it. However, this brings up a question: where should this temporary data be stored?
What do you do if your data needs to have a defined order? The database itself does not guarantee the order of records unless you explicitly use an ORDER BY clause. However, you can always use a numeric field to define the order in which the items should be displayed. To avoid duplicate positions, use a UNIQUE constraint on that field. In the example below, the database stores music albums. Each song on an album has its position that can be set in the seq field of the album_song table.
Cloud technologies are becoming more and more popular. Recently, Vertabelo added support for the Snowflake database. An additional feature, much awaited by our users, was support for materialized views in Snowflake. We are happy to announce that you can now model materialized views in a Snowflake database using Vertabelo. What Is a Materialized View? Materialized views are different from simple views. While simple views allow us to save complicated queries for future use, materialized views store a copy of the query results.
Fast storage is expensive. However, you can reduce costs by using a separate, slower disk space for tables that are not accessed very frequently. Examples include those with historical data. Below, you can see a database diagram with the historical account plans in a separate table. account_plan_history can be placed in a tablespace that uses slower storage, while more frequently accessed tables use separate, faster storage space. Note: if you use this solution, various objects related to these tables (such as indexes or BLOB data) must also be placed in the slower disk space.
Often, it is the case that certain data should no longer be modified once it reaches a particular state. Good examples are completed orders and issued invoices. In some cases, it is even considered a crime to modify such data. On one hand, we need to ensure immutable objects do not depend on operational data (for example, the current product catalog). On the other hand, they should be protected from accidental modification.