## 4 Performance Tests
### DELETE Operation  
Generally, two types of deletion operations can be applied to each element: soft delete, when the item is marked as deleted (deleted = true), and hard delete when the item is completely deleted. The soft delete approaches, where a hundred elements were deleted, is presented in Table 9.  
In MySQL, for relational as well as for non-relational, the elements were marked as deleted by an update in which the deleted field was set as true. For CouchDB, by default, all documents that do not  
Figure 11: Performance time (ms) for select with four inner joins. \begin{table}
\begin{tabular}{l} \hline \hline
**RELATIONAL MYSQL: Soft delete operation** \\ \hline @Query(value = “update country inner join continent on country.continent\_id= continent.id set \\ country.deleted = 1 where continent.name=:name”, nativeQuery = true) \\ @Modifying(clearAutomatically = true) \\ @Transactional void softDeleteByContinentName(@Param(”name”) String name); \\ countryRepository.softDeleteByContinentName(”Asia”); \\ \hline
**DOCUMENT-BASED MYSQL: Soft delete operation** \\ \hline collection.modify(”name = “Asia’ and country.name is not null”).change(“deleted”, true).execute(); \\ \hline
**CouchDB FIRST STRUCTURE: Soft delete operation** \\ \hline List\textlessMap\textlessString\textgreater{}; String\textgreater{}\textgreater{}\textgreater{} updatedList=responseDTO;getDocs().stream().filter \\ (doc \textgreater{  
have the deleted field were not deleted, so there is no need to enter a new field, therefore, in order to mark a document as deleted, it is required to enter this new field with an update. In the case of CouchDB's first structure, a select is used after which an update request with the _deleted_ field added was made. In this case, all the countries on continent \(x\) were marked as deleted. Using the second structure, the steps were similar, only when the list of cities was taken, the field _deleted_ was set as true and a new request with these documents was called. Because the soft delete operation was made as an update, by which only the concerned elements are marked as deleted, in this case, the second structure in CouchDB becomes more efficient as the number of elements increases, as shown in Figure 12.  
The first structure in CouchDB is inefficient due to a large number of requests, whereas MySQL is efficient only at a small number of items, for large numbers becoming very inefficient. To permanently delete an item, the commands were presented in Table 10. If there is any reference to this object when using relational MySQL an exception will appear because this is not a cascading delete, is a simple delete of an element. \begin{table}
\begin{tabular}{l} \hline \hline \multicolumn{2}{c}{**RELATIONAL MYSQL: Hard delete operation**} \\ \hline @Query(value = “delete from country c where cid = :countryId”, nativeQuery = true) \\ void delete(@Param(“countryId”) int id); \\ countryRepository.delete(444); \\ \hline \multicolumn{2}{c}{**DOCOUNT-BASED MYSQL: Hard delete operation**} \\ \hline collection.removeOne(“444”); \\ \hline \multicolumn{2}{c}{**CouchDB FIRST STRUCTURE: Hard delete operation**} \\ \hline Map\textless{String, Object\textgreater{}} resultMap = db.find(Map.class, “444”); \\ if (resultMap!= null) \{ db.delete(resultMap); } \\ \hline \multicolumn{2}{c}{**CouchDB SECOND STRUCTURE: Hard delete operation**} \\ \hline Map\textless{String, Object\textgreater{}} resultMap = db.find(Map.class, “444”); \\ if (resultMap!= null) \{ db.delete(resultMap); } \\ \hline \hline \end{tabular}
\end{table} 
Table 10: Hard delete operations. Figure 12: Performance time (ms) for soft delete. In the case of relational MySQL, before deleting an element, the element is searched and checked to verify if it is not used as a foreign key by another table and then is deleted. There is no check in CouchDB or in document-based MySQL. The actual deleting of an element is made using the same command in CouchDB for both structures, thus, they have similar performance.