Browsing by Subject "Impedance mismatch"

Now showing 1 - 2 of 2

Integrating programming languages and databases via program analysis and language design
(2009-12) Wiedermann, Benjamin Alan; Cook, William Randall; Batory, Don; Blackburn, Stephen M.; Lin, Calvin; McKinley, Kathryn S.
Researchers and practitioners alike have long sought to integrate programming languages and databases. Today's integration solutions focus on the data-types of the two domains, but today's programs lack transparency. A transparently persistent program operates over all objects in a uniform manner, regardless of whether those objects reside in memory or in a database. Transparency increases modularity and lowers the barrier of adoption in industry. Unfortunately, fully transparent programs perform so poorly that no one writes them. The goal of this dissertation is to increase the performance of these programs to make transparent persistence a viable programming paradigm. This dissertation contributes two novel techniques that integrate programming languages and databases. Our first contribution--called query extraction--is based purely on program analysis. Query extraction analyzes a transparent, object-oriented program that retrieves and filters collections of objects. Some of these objects may be persistent, in which case the program contains implicit queries of persistent data. Our interprocedural program analysis extracts these queries from the program, translates them to explicit queries, and transforms the transparent program into an equivalent one that contains the explicit queries. Query extraction enables programmers to write programs in a familiar, modular style and to rely on the compiler to transform their program into one that performs well. Our second contribution--called RBI-DB+--is an extension of a new programming language construct called a batch block. A batch block provides a syntactic barrier around transparent code. It also provides a latency guarantee: If the batch block compiles, then the code that appears in it requires only one client-server communication trip. Researchers previously have proposed batch blocks for databases. However, batch blocks cannot be modularized or composed, and database batch blocks do not permit programmers to modify persistent data. We extend database batch blocks to address these concerns and formalize the results. Today's technologies integrate the data-types of programming languages and databases, but they discourage programmers from using procedural abstraction. Our contributions restore procedural abstraction's use in enterprise applications, without sacrificing performance. We argue that industry should combine our contributions with data-type integration. The result would be a robust, practical integration of programming languages and databases.
What can the .NET RDBMS developer do? A brief survey of impedance mismatch solutions for the .NET developer
(2009-12) Fiduk, Kenneth Walter, 1980-; Julien, Christine, D. Sc.; Khurshid, Sarfraz
Nearly all modern software applications, from the simplest website user account system to the most complex, enterprise-level, completely-integrated infrastructure, utilize some sort of backend data storage and business logic that interacts with the backend. The ubiquitous nature of this backend/business dichotomy makes sense as the need to both store and manipulate data can be traced as far back as the Turing Machine in Computer Science. The most commonly used technologies for these two aspects are Relational Database Management Systems (RDBMS) for backend and Object-Oriented Programming (OOP) for business logic. However, these two methodologies are not immediately compatible and the inherent differences between data represented in RDBMS and data represented in OOP are not trivial. Taking a .NET developer’s perspective, this report aims to explore the RDBMS/OO dichotomy and its inherent issues. Schema management theory and algebra are discussed to gain better perspective of the domain and a survey of existing solutions for the .NET environment is explored. Additionally, methods outside the mainstream are discussed. The advantages and disadvantages of each are weighed and presented to the reader to help aid in design implementations in the future.