CRUD Object Oriented Programming

Question

I’m a little confused about how we persist in an object-oriented programming structure, I’m not sure how to explain it, let’s imagine the object Person and for example through Heritage create the object Professor who inherits the basis of the Person.

In this case I create two tables one for person and one for teacher?

Answer 1

What I’m understanding you’re saying is about "Inheritance" or is it about "Composition" in OO.

It’s easier for you to read the article below, but basically it’s as follows:

You have a "main" object called "Person" which contains various features (properties) such as, for example, "Name", Address", "Phone" ... well that everyone has. This "Person" object will be inherited by an object called "Teacher", because the teacher HAS all these properties above. BUT the teacher has some other properties that the "Person" DOES NOT have... example: Matter (who teaches)...

But please see the link:

======================================

OOP - Heritage x Composition

The Object Orientation paradigm - OO - brings many new concepts and, for those who come from the procedural paradigm using structured languages and database-oriented development, sometimes many of these concepts may not be well understood.

namespace Herança
{
        public class Pessoa 
        { 
            private String nome;
            private String Endereco;
            private String Telefone;
        }

        public class PessoaProfessor : Pessoa 
        { 
            private String CPF; 
            private String Materia;
            public PessoaProfessor() 
            {} 
        }

        public class PessoaAluno : Pessoa
        {
            private String Notas;
            public PessoaAluno()
            {}
        }
}

http://www.macoratti.net/11/05/oop_cph1.htm

Answer 2

Hello, the inheritance and most used as inheritance even kkkk.

Type: teacher, student, parents, etc. All have: name, age, sex, address.

In this case you can use inheritance to avoid duplicate code. In the class person Voce places all these properties, and in the child classes are inherited these generic properties.

In the database is (relational) usually do the following example:

In the table person have: id, name, address, id_tipo_de_usuario.

In this table in the id_tipo_de_usuario field is inserted a reference from another table, which contains the types of users.

In the table type_de_usuarioI have the fields: id and type. In the input field: teacher, student, responsible ...

So when I consult person and returned: id=0, name=Gabriel, address=street c n 95, id_type_de_usuario = 0.

id_type_de_user which is 0, is a reference of the type_de_user table where id = 0;

I hope I’ve helped you understand!

Answer 3

Gabriel, I believe this is what you seek:

There are several ways to map the inheritance relationship in the bank. The best strategy will depend on the situation (types of queries that will be performed against the data, amount of common fields vs specific fields, hierarchy size, amount of data, etc).

1. Table by entity

Each table will contain not only the data of the daughter class but also the data of the parent class. This allows "independent" queries between car and motorbikes to be simpler and faster. However queries seeking data from more than one entity require the use of Union all queries (which is problematic for a number of reasons).

2. Single table + breakdown column

A single table will contain all data of all entities. To differentiate between cars and motorcycles we use a discriminating column. This allows "generic" queries (i.e., on all vehicles) to be faster. It is especially appropriate when there are few specific car and bike attributes (thus avoiding a lot of null values).

3. Main table + daughter table with FK for main table This model is appropriate when normalization is essential and the daughter tables have many columns. Also this strategy is especially interesting to work with multiple inheritance (an entity can be of various types in the hierarchy simultaneously). The weakness of this modeling is that queries require Join, which makes code complex and brings performance problems as the amount of data and the depth of the hierarchy grows.

4. Joint strategies

Nothing prevents you from modelling part of your hierarchy according to one strategy and part according to another. For example, you can have a main vehicle table with the data common to all vehicles (speed, size, weight, etc.), but have unique tables for each type of vehicle (land vehicles, water vehicles, flying vehicles, etc.).

All strategies have their advantages and disadvantages; OO and relational representations are sufficiently different for several mapping problems to exist (see Object-Lational impedance Ismatch ). If your problem cannot be adequately handled by any of the strategies, there are also solutions with Object oriented database, (see Martin Fowler’s Schemaless Data Structures), indices, etc. Each with its respective strengths and weaknesses.

*** See more in:

Inheritance in relational database