Clase Teórica 1

Introduction to the Course

Overview of the Subject Matter

• The instructor welcomes students and provides a brief introduction, noting that many have attended previous classes.

• This course differs from others by focusing on practical experience rather than solely theoretical content.

• The primary goal is to equip students with the knowledge to develop criteria for addressing information storage problems.

Course Structure and Approach

• The course will build upon existing knowledge while introducing new concepts, such as databases and software architecture.

• Emphasis is placed on real-world experiences drawn from the instructor's 25 years in industry projects.

Course Dynamics and Participation

Interaction Guidelines

• Students are encouraged to engage actively; they can ask questions by raising their hands or speaking up during class.

• Classes will be held synchronously every Thursday at 9 AM, allowing for discussions and sharing of anecdotes.

Additional Resources

• The instructor offers supplementary materials like articles and papers for those interested in exploring topics beyond the course scope.

Practical Work and Assessment

Practical Assignments Overview

• Assessment will consist of a series of practical assignments rather than traditional memorization tests.

• Students will use Java as a platform for practice, focusing on basic reading and writing skills rather than advanced efficiency.

Assignment Details

• The first assignment involves saving information in a database using a mapper based on provided models.

• Subsequent tasks include retrieving data through queries, progressing from simple to complex requests.

Database Technologies Focus

Introduction to NoSQL Databases

• After initial assignments, students will transition to working with NoSQL databases due to their simplicity and power.

Practical Application Context

• Students will learn how to interact with databases via command-line interfaces, emphasizing practical application over theoretical DBA roles.

Application Architecture and Course Structure

Overview of Application Architecture

• Discussion on the architecture of an application that accommodates growth in mapping and object management, emphasizing the importance of reusability and minimal coding.

Course Requirements and Practices

• Students are encouraged to read the provided document thoroughly; each practice has a defined follow-up and submission process necessary for course completion.

• After completing the coursework, students will interact with teaching assistants (TAs) before being eligible to take the final exam.

Final Exam Structure

• The final exam consists of theoretical-practical questions based on class discussions and practical experiences gained throughout the course.

• Emphasis is placed on understanding concepts rather than rote memorization; students are expected to seek solutions independently as they would in a professional setting.

Oral Exams During Pandemic

• Due to pandemic conditions, finals will be conducted orally via platforms like Meet or Zoom, marking a shift from traditional examination methods.

Alternative Assessment Options

• Students can opt to enhance existing practical work or create new projects using tools discussed in class, particularly focusing on relevant topics such as Big Data.

• The instructor encourages integrating knowledge from other subjects into current projects, potentially aligning them with thesis topics in the future.

Class Logistics and Communication

• Classes are scheduled every Thursday at 9 AM; sessions will be recorded for those unable to attend live due to connectivity issues.

Student Engagement and Understanding

• The instructor invites questions during lectures, ensuring clarity on foundational concepts such as Java programming and design patterns.

Understanding Design Patterns in Software Development

Introduction to Design Patterns

• The speaker emphasizes the importance of understanding design patterns as they will be applied throughout the course.

• Clarification is provided that if anyone has questions or needs repetition on topics, they are encouraged to pause and ask for clarification.

Paradigms in Software Development

• The discussion transitions to paradigms, highlighting that developers will face dilemmas regarding which tools and methods to use during development.

• The speaker stresses the need for thoughtful decision-making when selecting tools, rather than defaulting to familiar options like MySQL without considering their appropriateness.

Object-Oriented Programming (OOP)

• A strong foundation in object-oriented programming is noted, suggesting that most students will likely choose OOP due to their academic background.

• The speaker discusses various interpretations of objects in programming, from basic class definitions to complex designs involving multiple patterns.

Choosing Appropriate Tools

• It’s highlighted that while OOP is common, other paradigms such as functional or procedural may also be applicable depending on specific contexts.

• Developers often mistakenly assume new technologies are better suited for their needs without considering existing systems and practices.

Ecosystem Considerations

• Emphasis is placed on recognizing that software systems rarely exist in isolation; they often interact with other systems.

• The speaker warns against neglecting integration with existing applications when developing new solutions.

Real-world Examples and Challenges

• Real-world challenges are discussed, including outdated technology still being used by organizations (e.g., mainframes).

• An example of a major bank migrating within an old system highlights the difficulties faced when trying to implement modern solutions alongside legacy systems.

Conclusion on Paradigm Choices

• Ultimately, the choice of using object-oriented paradigms and relational databases is reinforced as a practical approach based on client needs and existing infrastructure.

Understanding Relational Databases and SQL Standards

The Myth of Database Alternatives

• The speaker discusses the misconception that there are numerous alternatives to relational databases, emphasizing that in practice, the options are limited.

• An exercise is proposed where participants would struggle to name more than a handful of commonly used relational database systems, highlighting the concentration of major players in the market.

Historical Context and Market Consolidation

• A historical overview reveals how major database systems like MySQL and Oracle have merged or been acquired, leading to fewer distinct options available today.

• The existence of SQL standards (specifically SQL 92) is introduced as a framework that facilitates easier transitions between different database engines when adhering to these standards.

Licensing Challenges in Database Systems

• The speaker explains that using standardized SQL should theoretically allow for easy migration from one database engine to another; however, practical challenges often arise due to licensing issues.

• An anecdote about a national human resources system illustrates how licensing costs can hinder implementation across various organizations.

Implementation Difficulties and Costs

• A case study shows that despite having a developed HR system available for use, many organizations could not implement it due to high Oracle licensing fees exceeding their annual budgets.

• This example underscores the importance of evaluating total costs associated with software solutions before committing to them.

Technical Limitations and Real-world Implications

• Even if an organization uses SQL 92 compliant code, transitioning away from Oracle may be complicated by proprietary coding practices embedded within applications.

• The speaker emphasizes that sometimes rewriting an application from scratch may be more feasible than attempting to adapt it for a new database engine due to deep integration with specific technologies.

Learning from Anecdotes

• Anecdotal evidence serves as a teaching tool throughout the discussion, illustrating real-world scenarios where technical decisions lead to unexpected outcomes.

• The aim is for participants to recognize potential pitfalls in technology adoption and management through shared experiences.

Understanding Object-Oriented Programming and Databases

The Importance of Object Thinking

• The speaker emphasizes the need for students to rethink their approach to objects, particularly in scenarios where object-oriented programming is applicable.

• Acknowledges that students previously did not consider the origins of objects, highlighting a disconnect between theoretical knowledge and practical application.

Challenges with Data Handling

• Discusses the issue of managing data from databases, noting that while working with graphical interfaces, transactions should remain open only as long as necessary.

• Raises concerns about how modifications to in-memory objects affect database integrity when transactions are prematurely closed.

Balancing Object Models and Database Efficiency

• Stresses the importance of maintaining a pure object model while ensuring efficient database interactions without sacrificing performance.

• Points out that technical solutions must prioritize user experience; users care more about functionality than underlying design patterns.

Mapping Objects to Relational Databases

• Introduces the concept of mapping object-oriented models to relational databases, emphasizing the need for effective translation between these paradigms.

• Explains "marshalling," which involves converting objects into a relational structure and vice versa, stressing its complexity in concurrent environments.

Practical Application with Hibernate

• Outlines an upcoming practical exercise where students will implement a given model using both theoretical and practical mapping techniques.

• Mentions Hibernate as a widely used industry standard for object-relational mapping (ORM), indicating that while they will use it, the focus will be on manual implementation rather than direct product usage.

Understanding Entity Relationships

• Highlights the simplicity of understanding entities and relationships within relational databases compared to complex object-oriented concepts.

• Encourages students to grasp basic entity relationship principles quickly, suggesting that even novices can understand fundamental concepts like entities and relationships within minutes.

Understanding Data Modeling and Relationships

The Concept of Data Boxes

• The speaker introduces the idea of "data boxes," which can be enhanced with markers (like a "rulito") to signify stored information, such as a person's DNI (National Identity Document).

• This method aids in requirement specification meetings where users may not fully understand their needs or technical possibilities.

Importance of Clarity in Domain Understanding

• Clear communication about domain relationships is crucial; for example, understanding that multiple genes can exist across various chromosomes.

• Simplistic models can lead to inefficiencies, especially when trying to represent complex structures like graphs within relational databases.

Challenges with Recursive Structures

• Storing graph data in a single table often results in self-referencing nodes, complicating queries and making them costly in terms of performance.

• Recursive data modeling poses significant challenges due to its complexity and inefficiency when querying related nodes.

Generalization vs. Specialization in Object-Oriented Design

• The discussion transitions into generalization and specialization concepts using "cajitas" (boxes), highlighting how inheritance works at both structural and behavioral levels.

• In object-oriented programming, inherited attributes are automatically available to subclasses, unlike relational databases where manual joins are necessary.

Performance Implications of Database Design Choices

• When generalizing entities into tables, each query may require costly joins between parent and child tables, impacting performance significantly.

• Adding attributes to superclasses automatically propagates these changes to subclasses in OOP but requires manual updates in relational database schemas.

Documentation Challenges

• Relational databases lack inherent mechanisms for representing hierarchical relationships between tables; this leads to reliance on documentation that may become outdated or inaccurate.

• As systems grow complex with thousands of tables, tracking relationships becomes increasingly difficult without clear documentation practices.

Understanding Complex Data Structures and Design Principles

Challenges in Data Attribute Assignment

• The complexity of determining the correct attributes for data tables is highlighted, especially when unusual names are introduced, complicating the assignment process.

Practical Application of Algebra in Work

• A reflective question is posed regarding the last time participants applied algebra or tuple calculus in their work experience, indicating a disconnect between theoretical knowledge and practical application.

Critique of Common Practices

• The speaker emphasizes that while mathematical proofs can validate queries, many professionals rely on trial and error rather than rigorous methods to ensure query accuracy.

Importance of Normalization

• Normalization is discussed as a critical design principle; however, the speaker admits to occasionally storing collections within single columns for practicality despite its deviation from best practices.

Evolution of Storage Costs

• The historical context of normalization principles is provided, noting that past high storage costs influenced design decisions which may no longer be relevant due to modern affordability of storage solutions.

Designing Efficient Systems: Balancing Normalization and Performance

Trade-offs Between Normalization and Speed

• An example illustrates how normalized systems can lead to slower performance (e.g., 40 seconds login time), whereas denormalized systems can significantly improve speed (milliseconds).

Microservices Architecture Considerations

• The discussion introduces microservices architecture where each service has its own database. This approach contrasts with traditional object-oriented programming paradigms.

Patterns in Object-Oriented Design

Root Object Pattern Explained

• The root object pattern is introduced as a design principle advocating for objects that facilitate access to other objects within a system.

Modeling Real-world Entities

• When modeling entities like banks, it’s crucial to start with foundational classes such as "Bank" before detailing other components like accounts or transactions.

Modeling Systems and Business Logic

Understanding Object Modeling in System Design

• The discussion emphasizes the importance of modeling objects that represent the system being developed, defining its boundaries and where to place business logic.

• An example is provided regarding a bank's business logic, highlighting that it’s inefficient to check for duplicate clients based on their ID within the client object itself.

• It suggests that the bank should manage collections of users, allowing it to efficiently verify if a client with a specific ID already exists.

Relational vs. Object-Oriented Design

• The speaker contrasts object-oriented design with relational design, arguing against creating a single entity or table for "bank" in a relational model.

• In relational models, all tables and their relationships collectively represent the bank rather than having an isolated "bank" entity.

• Mixing paradigms (object-oriented and relational) can lead to confusion; each paradigm has its own best practices for modeling entities.

Challenges in Modeling Complex Concepts

• The speaker raises questions about how to model concepts like paychecks using normalized data formats such as JSON or XML.

• A practical exercise is suggested: participants should consider how they would model something as fundamental as a paycheck within an entity-relational framework.

Identifying Entities in Paycheck Models

• A real-world example of a paycheck receipt is introduced, prompting participants to identify potential entities involved in this model.

• Participants are encouraged to think critically about domain tables needed for various components of the paycheck, such as addresses and categories related to employment status.

Detailed Breakdown of Paycheck Components

• Discussion includes identifying domains or tables necessary for modeling aspects like seniority, tax identification numbers (TIN), and employee names.

• Categories related to payroll types must be modeled separately; examples include different types of payments like bonuses or retroactive payments.

• Each component of the paycheck requires careful consideration regarding how it will be represented in database tables, ensuring efficient data retrieval.

SQL Query Demonstration

• The session concludes with an intention to demonstrate the SQL query required to extract data associated with generating the PDF version of the paycheck.

Understanding Complex Queries in Database Design

The Challenge of Query Complexity

• The speaker discusses the inefficiency and complexity of a lengthy query, emphasizing that it is difficult to understand due to its size and structure.

• To improve readability, the speaker used an online code formatter to organize the query, resulting in a clearer presentation of its components.

• The formatted query consists of 142 lines, highlighting the extensive use of multiple tables and complex elements within the SQL statement.

• The speaker points out that this query involves nested selects and projections across various tables, indicating a high level of complexity required for data retrieval.

• Mentioning large organizations with thousands of employees, the speaker illustrates how such queries can become burdensome when executed frequently.

Rethinking Data Storage Approaches

• The discussion shifts towards eliminating normalization burdens by storing pre-calculated data directly as needed for PDF generation through RESTful APIs.

• By providing metadata alongside PDFs in JSON format, efficiency in data retrieval is significantly improved compared to traditional relational models.

• The speaker contrasts querying methods between relational databases and more flexible storage solutions that avoid costly joins or subqueries.

• Emphasizing ease of access, they argue for a design where all necessary information is stored together without needing complex relationships between tables.

• This approach allows for straightforward queries based on specific attributes without incurring additional computational costs.

Implications for Agile Development

• A new strategy emerges where receipts are stored efficiently while still accommodating existing systems; this duality enhances overall performance.

• The focus shifts from identifying IDs to simply retrieving relevant titles or concepts based on user requests, streamlining processes further.

• Questions arise about whether agile methodologies inherently lead to better code quality or if it's the underlying design choices that facilitate adaptability to change.

• The importance of being able to adapt quickly is highlighted; however, reliance on tightly coupled database engines can hinder agility during significant changes like switching database types.

• Ultimately, having a transparent persistence layer allows developers greater flexibility in managing changes without being locked into specific technologies.

Choosing the Right Database: Insights and Considerations

The Importance of Database Independence

• The speaker discusses the selection of various databases (Oracle, SQL Server, non-relational) and emphasizes a trend in software architecture advocating for database independence.

• One of the twelve factors proposed is that applications should maintain independence from their databases; changes to the database should only require configuration adjustments.

Challenges with Embedded SQL

• The speaker raises concerns about embedding SQL within code, highlighting potential issues such as syntax errors that may not be caught until execution.

• Specific examples include problems with SQL standards across different engines, where certain keywords or table names may conflict due to reserved words in specific databases.

Real-world Implications of Code Dependency

• A personal anecdote illustrates challenges faced when maintaining an application without access to its source code, emphasizing risks associated with tightly coupled code and database structures.

• The discussion includes considerations on whether it is common for databases to change in practice versus theory, questioning how often developers face this scenario.

Impact of Changing Databases

• The speaker prompts reflection on the implications of changing a database system and what adjustments would be necessary within an application’s codebase.

• It is noted that switching between similar types of databases (e.g., Oracle to MySQL) might require minimal changes compared to switching between entirely different persistence solutions.

Cloud Solutions and Application Adaptability

• As cloud solutions become more prevalent, questions arise regarding how much an application should change when transitioning from local installations to cloud services.

• Ideally, business logic remains unchanged regardless of whether data is stored locally or in the cloud; only persistence mechanisms need adjustment.

Critical Operations and Their Dependencies

• The final point addresses how executing insert operations can create dependencies on specific database technologies or ORM frameworks like Hibernate.

• This dependency can lead to complications if future changes are needed in data handling strategies or if a switch away from these technologies becomes necessary.

Understanding Persistence in Code

The Importance of Minimizing Dependencies

• The speaker emphasizes the need to minimize dependencies on persistence solutions, questioning how often one must write a save command in their code to facilitate future changes in persistence solutions without needing to modify existing code.

Demonstrating Object Storage Without Explicit Save Commands

• The speaker claims that it is possible to store objects without using explicit insert or save statements, suggesting that the number of required saves can be zero.

Code Example Overview

• A demonstration begins with a code snippet where a main function creates a phone collection and associates it with a person named Elton, highlighting that no persistence-related lines are present initially.

Identifying Persistence Code Elements

• As the discussion progresses, elements like configuration, session factory, and transaction management appear in the code, indicating reliance on Hibernate for database interactions.

Issues with Current Implementation

• The speaker expresses dissatisfaction with the current implementation due to its tight coupling with Hibernate and transactional operations such as opening and closing sessions.

Transaction Management Challenges

Transaction Operations Explained

• The speaker explains how they open a session, begin a transaction, save an object (a person), commit the transaction, and then query for stored data using SQL commands.

Expected Outcomes from Database Queries

• Upon executing queries after committing transactions, one should expect all saved persons to be listed; however, issues arise when attempting to print associated phone numbers.

Error Encountered During Execution

• An error occurs during execution when trying to print phone numbers associated with Elton after successfully printing his name. This indicates potential issues related to object state management post-commit.

Understanding Object Validity Post-Persistence

Validity of Objects After Commit

• Once information is committed to the database, any further operations on those objects must occur within an active transaction context; otherwise, they become invalid for memory operations.

Strategies for Data Retrieval Post-Persistence

• The speaker hints at employing unconventional methods ("dirty tricks") for retrieving information stored in the database while navigating through these challenges.

Transaction Management and Persistence in Programming

Overview of Transaction Handling

• The speaker discusses transitioning to a different machine for faster processing, emphasizing the importance of controlling and saving information before closing transactions.

• After executing a transaction, the results show that data is not duplicated (e.g., "Elton" appears twice), indicating successful management of transaction states.

Code Quality and Best Practices

• The speaker critiques the current code as poorly structured, highlighting the need for better practices in handling data retrieval and printing before committing transactions.

• A more elegant solution called "persistence by scope" is introduced, which aims to improve how objects are managed within transactions.

Understanding Persistence by Scope

• Persistence by scope ensures that if an object (A) is linked with another object (B), both must be saved together to avoid errors when transactions close.

• The speaker explains that reducing unnecessary inserts can be achieved by linking already persistent objects with new volatile ones.

Practical Application of Concepts

• An example illustrates how class A can have a variable B set through proper coding practices, ensuring that changes reflect correctly in the application.

• The discussion includes testing persistence features using a mapping tool (like Hibernate), demonstrating its effectiveness in managing related data entities.

Implementation via REST API

• Transitioning to a REST API context, the speaker outlines endpoints for saving users and phones while applying persistence by scope principles effectively.

• When adding a phone number, the process involves retrieving an existing user from the database and linking it with new data seamlessly.

Live Demonstration of Functionality

• A live demonstration shows running an application where users can be added successfully without issues indicated by status codes.

• The final steps involve verifying that newly added phone numbers are correctly associated with their respective users in the database.

Persistence in Application Development

Importance of Database Independence

• The speaker emphasizes the significance of database independence, stating that changes to the database type (e.g., SQL Server to PostgreSQL) should not require modifications to the application code.

• Acknowledges the importance of documentation as a best practice in software development, hinting at its role in maintaining clarity and understanding.

Identifiers and Object Persistence

• Discusses the use of unique identifiers (UUIDs), which are large random numbers that minimize repetition, highlighting their effectiveness for object persistence.

• Warns against tying objects to specific classes for persistence, as this can lead to issues when changing mappers or database types.

Testing Strategies

• Stresses that business logic tests should remain unaffected by changes in database technology; unit tests should focus on business logic rather than integration with databases.

• Advocates for testing application logic independently from the underlying database, ensuring that business rules are validated regardless of data storage methods.

SOLID Principles Overview

• Introduces SOLID principles as essential guidelines for object-oriented design, encouraging developers to revisit these concepts for better coding practices.

• Highlights the Single Responsibility Principle (SRP), which states that a class should have one responsibility. For example, a bank class shouldn't manage both users and accounts simultaneously.

Liskov Substitution Principle

• Explains the Liskov Substitution Principle (LSP), which asserts that objects of a superclass should be replaceable with objects of a subclass without affecting functionality.

• Encourages developers to test their code by substituting specific types with more abstract superclasses (e.g., using Collection instead of ArrayList) to promote flexibility and reduce dependency on concrete implementations.

Practical Application and Design Patterns

• Suggests adopting generic programming practices by using abstract types in collections, allowing for greater adaptability within codebases when dealing with various collection types.

• Mentions the Repository Pattern as a design approach that abstracts data access methods, enabling seamless interaction with different database technologies while keeping application code clean and maintainable.

Introduction to Coding and Tools

Overview of the Course Content

• The session will focus on practical coding examples rather than pseudocode, emphasizing functional code that will be consistently operational.

• Initial discussions will cover basic mapping concepts before delving into entity relationships using Hibernate and JPA standards.

Virtual Environment Setup

• A virtual machine with all necessary installations (Java, Eclipse) will be provided to avoid setup issues for students. This aims to streamline the learning process.

• The virtual machine is compatible with various operating systems (Ubuntu, Debian, OSX, Windows) and is designed for use with VirtualBox without licensing concerns.

• Students are encouraged to run the virtual environment for practical exercises; however, local installation is also an option if preferred for performance reasons.

Clarifications and API Discussions

Addressing Student Queries

• The instructor invites questions regarding course content or any unclear aspects related to final project mechanisms before concluding the session.

Concept of APIs in Database Management

• The goal is to utilize standards over specific products when working with APIs while ensuring design criteria minimize future impacts from database changes.

• Emphasis on balancing abstraction in programming with performance needs; solutions should not compromise efficiency despite being abstracted away from direct database interactions.

Practical Considerations in Object-Oriented Paradigms

Real-world Application Scenarios

• The instructor shares a hypothetical scenario where regulatory changes necessitate quick database updates, highlighting the importance of flexibility in coding practices over rigid object-oriented designs.

• It’s crucial to think logically about application design so that changes in database engines do not disrupt overall functionality or require extensive rewrites of code structures.

SQL as a Fast Solution

• While object-oriented approaches are valuable, sometimes direct SQL commands provide quicker resolutions for immediate problems within relational databases. Understanding when to apply each method is key for developers.

Framework Utilization and Knowledge Requirements

Tools and Framework Awareness

• Current frameworks like Spring and Quarkus offer layers of transparency but require knowledge of dependency injection and control inversion among other advanced concepts for effective use in projects.

Conclusion on Learning Approach

• The proposed approach combines theoretical understanding with practical application, preparing students for real-world scenarios they may encounter during their careers as developers.

Understanding Dependency in Persistence Solutions

The Nature of Dependencies in Code

• The speaker discusses the concept of dependencies within code, emphasizing that while there may not be an explicit dependency in the code itself, there is a clear need for any persistence solution to implement "persistence by reachability."

• It is noted that most persistence solutions inherently possess this feature but often fail to advertise it effectively. This lack of visibility can lead to misunderstandings about their capabilities.

Marketing and Adoption Challenges

• The speaker raises concerns about how companies like Hibernate might not promote their features widely. If users were aware of the flexibility offered by "persistence by reachability," they might choose to adopt it over more rigid solutions.

• There is speculation that Hibernate's marketing strategy aims to keep users tied to their platform, making migration to other solutions less appealing. This could hinder broader adoption of potentially simpler alternatives.

Conclusion and Next Steps

• The discussion wraps up with an invitation for further questions or clarifications, indicating that there will be additional sessions for deeper exploration of these topics.

• The speaker mentions plans to share recorded content through forums and groups, ensuring participants have access to documentation and contact information for follow-up inquiries.