Comparative Analysis of Relational and Non-Relational Database Models: A Case Study on Travel Booking Systems
Bibliographic record
Abstract
Aim/Background The study aims to evaluate and compare relational and non-relational (NoSQL) database models in the context of travel booking systems. Traditional relational databases like MySQL are known for their data integrity and structured schema, while NoSQL models like ArangoDB, Apache Cassandra, Memcached, and MongoDB offer scalability and flexibility. This research investigates which model performs best across various database operations relevant to real-world scenarios. Methodology The research used both theoretical and practical methods. A literature review was conducted using sources such as Google Scholar, IEEE Xplore, and database documentation. The team implemented a travel booking system to perform standardized operations like insert, update, delete, retrieve, access control, and integrity checks using five selected DBMSs. Performance metrics included execution time, CPU usage, throughput, and constraint handling, and were analyzed using visualizations and comparative tables. Results Apache Cassandra showed the best overall performance for flight booking systems due to high throughput and scalability. MySQL performed exceptionally in data integrity and consistent performance under constraints. ArangoDB showed flexibility and low insertion time but required a learning curve. Memcached excelled in insert/delete throughput but lacked persistence. MongoDB offered schema flexibility but lagged in constrained scenarios and multi-document transactions. Discussion The findings reveal that database selection should align with specific application needs. NoSQL models are preferable for high-speed, flexible operations, while relational databases are superior for structured, integrity-focused use cases. The study corroborates prior research advocating NoSQL for big data applications, yet highlights the enduring value of RDBMSs in mission-critical systems. Conclusion Apache Cassandra is the most appropriate choice for large-scale, dynamic systems like travel booking due to its high availability and performance. MySQL and ArangoDB also have strong points for specific tasks. The research emphasizes that no one-size-fits-all model exists, and DBMS selection must consider operation type, data size, and performance requirements.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.002 | 0.000 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.002 | 0.002 |
| Science and technology studies | 0.001 | 0.000 |
| Scholarly communication | 0.000 | 0.003 |
| Open science | 0.001 | 0.001 |
| Research integrity | 0.000 | 0.000 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one teacher head, not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".