# AMANDA: A Middleware for Automatic Migration between Different Database Paradigms
## 5 Take Outs  
AMANDA reads a configuration file containing the migration characteristic, such as table and attribute definitions for the migration process, and then migrates the tables and attributes. First, AMANDA turn the tables into graph nodes and, after that, creates the relationships between nodes.  
To compare AMANDA with other methods proposed in the literature, we present a brief comparison and a table to summarize it. It is important to note that not all of the proposed works in the literature can be compared with ours. Some works, such as [11; 18; 21; 34; 35; 38; 43], do not use the same dataset that we have used. However, the works [36; 37; 42] use the same dataset. Therefore we compare AMANDA with the works that use the same datasets and database paradigms as ours.  
Starting with the Northwind dataset, when comparing the migration time taken by AMANDA and the work proposed by [42], AMANDA took 1 s to migrate 1107 Northwind dataset tuples, which is considerably faster than [42], whose migration tool would take 2610 s to complete the same process. The authors in [36; 37] did not measure the time of the migration between database with the Northwind dataset.  
Regarding the IMDB database, when comparing the migration time taken by AMANDA and the work proposed by [42], AMANDA took 168 h to migrate 174,728,704 tuples, whereas the proposed method by [42] would take 992 h. The authors in [37] did not measure the time of the migration between database with the IMDB dataset, while the proposed work in [36] does not have experiments with IMDB dataset.  
It is important to note that the dataset sizes of Northwind and IMDB, when compared with the proposed works [36; 37; 42], are different. AMANDA migrates 1107 tuples of the Northwind dataset, whereas [37; 42] migrate 3308 tuples. This is because, in our approach, associative tables do not need to be migrated, but they are used to build the edges between graph nodes. Similarly, for the IMDB dataset, we used a dataset with 174,728,704 tuples, whereas [42] used a subset of IMDB with 1,673,074 tuples. Therefore, to make the comparison in the above paragraphs, we used the _rule of three_.  
Regarding the usage of computer resources, none of the proposed works that use the same dataset as ours have provided such metrics, e.g., CPU and RAM. Therefore, we cannot compare the resources used by AMANDA with the proposed works in the literature. Table 6 summarizes the performance comparison among works.  
Figure 14: Q6 example for IMDB.  
AMANDA has some qualitative features; for example, the configuration file _schema.json_ provides enhanced flexibility when compared to [18], which uses the database's metadata, or [37], which uses ER diagram traversal.  
Our migration technique allows for querying the data in the form of a graph, as performed in [43]. AMANDA's architecture is straightforward, formed by three elements of architecture: the source database, migration script, and the target databases needing no other interfaces to make the migration or make the data available for querying.  
AMANDA's superior performance demonstrates that relying on a schema.json, which is provided beforehand, and contains every table and attribute to be migrated, is superior to relying on an algorithm-based approach that will instead seek the database metadata or traverse the ER diagram.  
Our solution demonstrates the best performance and flexibility compared with most previous studies that provide similar test information.