Database Schema Changes Research Articles

ANALISA PERBANDINGAN TINGKAT EFISIENSI ALGORITMA DATA DEFINITION LANGUAGE COPY, INPLACE, INSTANT DATABASE MYSQL

<p><em>MySQL database schema changes are becoming more frequent than ever, Four out of five application updates (releases) require appropriate database changes, For Database schema changes are more often a repetitive task, it may be a request from the application team to add or modify a column in a table and many cases other. This study aims to measure the level of time efficiency to modify the sales transaction table schema which consists of 50000 number of records in the MySQL database with the Data Definition Language (DDL) Copy, Inplace and Instant algorithm on the MySQL database.</em><em></em></p>

Identifying architectural technical debt, principal, and interest in microservices: A multiple-case study

Background:Using a microservices architecture is a popular strategy for software organizations to deliver value to their customers fast and continuously. However, scientific knowledge on how to manage architectural debt in microservices is scarce. Objectives:In the context of microservices applications, this paper aims to identify architectural technical debts (ATDs), their costs, and their most common solutions. Method:We conducted an exploratory multiple case study by conducting 25 interviews with practitioners working with microservices in seven large companies. Results:We found 16 ATD issues, their negative impact (interest), and common solutions to repay each debt together with the related costs (principal). Two examples of critical ATD issues found were the use of shared databases that, if not properly planned, leads to potential breaks on services every time the database schema changes and bad API designs, which leads to coupling among teams. We identified ATDs occurring in different domains and stages of development and created a map of the relationships among those debts. Conclusion:The findings may guide organizations in developing microservices systems that better manage and avoid architectural debts.

Data perspectives of workflow schema evolution

Purpose – Most literature on workflow (WF) adaptation considered the control flow correctness like absence of dead lock, live-lock, etc. during adaptation. The data aspect of WF adaptation like data flow, database schema changes and their correctness are less studied. When the WF schema is modified, their data flow and the database schema changes. The existing approaches used for adapting these data changes in the underlying database schema are time consuming and/or affect the old data persistence. The purpose of this paper is to concern the dynamic adaptation of the WF schema and implementing its data changes in the existing database schema. Design/methodology/approach – A conceptual framework developed to adapt on-the-fly, the concomitant data changes during WF adaptation. The framework consists a set of data schema compliance criteria (DSC) which identify the data changes that can be directly accommodated in the existing database schema. Data adaptation algorithm (DAA) is developed to handle the data changes that does not conform to the DSC in the existing database schema. Findings – In this approach the existing database schema is dynamically evolved without re-creating it, after WF schema adaptation. Therefore the WF schema changes can be implemented on-the-fly without stopping the running system. It also ensures the persistence of old data residing in the existing database. Originality/value – A novel approach developed to adapt the data changes in the existing database schema, without requiring recreation or migration the data. This automated consistency checking of data attribute changes in the database schema and implement them dynamically.

Graceful database schema evolution

Supporting graceful schema evolution represents an unsolved problem for traditional information systems that is further exacerbated in web information systems, such as Wikipedia and public scientific databases: in these projects based on multiparty cooperation the frequency of database schema changes has increased while tolerance for downtimes has nearly disappeared. As of today, schema evolution remains an error-prone and time-consuming undertaking, because the DB Administrator (DBA) lacks the methods and tools needed to manage and automate this endeavor by (i) predicting and evaluating the effects of the proposed schema changes, (ii) rewriting queries and applications to operate on the new schema, and (iii) migrating the database. Our PRISM system takes a big first step toward addressing this pressing need by providing: (i) a language of Schema Modification Operators to express concisely complex schema changes, (ii) tools that allow the DBA to evaluate the effects of such changes, (iii) optimized translation of old queries to work on the new schema version, (iv) automatic data migration, and (v) full documentation of intervened changes as needed to support data provenance, database flash back, and historical queries. PRISM solves these problems by integrating recent theoretical advances on mapping composition and invertibility, into a design that also achieves usability and scalability. Wikipedia and its 170+ schema versions provided an invaluable testbed for validating PRISM tools and their ability to support legacy queries.